針對表單物件的案例-js教程-PHP中文網

針對表單物件的案例

DDD

發布： 2025-01-17 00:31:13

原創

122 人瀏覽過

A case against form objects

注意：雖然本討論使用 Ruby on Rails 範例，但核心概念廣泛適用於其他語言和框架。

表單物件的問題：批判性檢查

讓我們澄清一下 Web 應用程式開發中經常模糊的「表單物件」概念。根據各種文章（下面連結）和實務經驗，表單物件缺乏普遍認可的定義和目的。他們的角色常被描述為：

資料驗證： 驗證使用者輸入的簡單 Ruby 物件。
模型聚合：代表來自多個模型的資料的虛擬模型。
強參數替換：用於輸入清理的強參數的替代方案。
回呼重建：一種重新組織模型生命週期回呼的方法。
form_for 助理： 專門設計用於 Rails 的 form_for 助理的物件。

主要目標通常被認為是透過處理參數處理、類型強制和基本驗證來簡化控制器。它們也用於封裝來自單一表單提交的多個 ActiveRecord 模型的更新，模仿 ActiveRecord 行為以提高控制器的熟悉度。它們被視為管理複雜行為的一種方式。

為什麼要使用表單物件？預期好處：

據稱的優點包括：

解耦：將業務邏輯與控制器和模型分開。
檢視幫助器：為複雜表單元素提供幫助器方法（例如，選擇欄位的選項）。
Rails 約定遵守： 簡化複雜表單，不直接對應到單一 ActiveRecord 模型。

然而，缺乏明確的定義導致了第一個主要問題：溝通不良。當在程式碼庫中遇到表單物件時，不清楚它們履行哪些角色（或其組合）。

本質上，表單物件旨在透過集中職責（通常在模型和/或控制器層內）來重構程式碼複雜性。但這導致了第二個問題：意外的膨脹。

缺點：「胖形式物件」反模式

考慮一個常見的實作：

<code class="language-ruby">class SomethingController
  def create
    @form = MyForm.new(action_params)
    if @form.valid?
      @form.save!
      redirect_to "somewhere"
    else
      render :new
    end
  end
  def new
    @form = MyForm.new
  end
end</code>

登入後複製

這種看似簡單的方法掩蓋了一個重大問題。表單物件的公共 API（new、valid?、save! 及其在視圖中的存在）顯示它處理：

參數解析：理解並轉換請求參數。
驗證：了解參數類型和驗證規則（業務邏輯）。
持久化：了解如何建立和持久化資料（與資料庫互動）。
視圖邏輯： 可能包含與視圖相關的邏輯（表單元素的輔助方法）。

這違反了單一責任原則。表單物件成為各種關注點的儲存庫，隨著時間的推移吸引更多的責任（額外的視圖助理、驗證規則等）。它演變成一個“胖形式的對象”，反映了它想要解決的問題。

第三個問題：冗餘

更重要的問題是這些職責通常已經由其他組件處理：

堅持：這是模特兒的責任。委託給模型而不是複製其功能。
業務邏輯：使用服務物件來實現複雜的業務邏輯。
輸入驗證： 使用驗證庫（ActiveRecord::Model、Scrivener、dry-schema）。
視圖助理：使用視圖模型或示範者。

在中型到大型應用程式中，這些元件可能已經存在。引入具有重疊職責的表單物件會增加不必要的複雜性和架構模糊性。複雜性應該直接解決，而不是被掩蓋。

提議的替代方案：更模組化的方法

更結構化的方法為每個職責使用專用物件：

<code class="language-ruby">class SomethingController
  def create
    @form = MyForm.new(action_params)
    if @form.valid?
      @form.save!
      redirect_to "somewhere"
    else
      render :new
    end
  end
  def new
    @form = MyForm.new
  end
end</code>

登入後複製

這種方法的優點：