针对表单对象的案例_Ruby

针对表单对象的案例

本文基于 ruby on rails 示例，但核心概念适用于其他语言和框架。

一、表单对象：定义与目的

表单对象究竟是什么？其设计初衷是什么？根据参考文章及实践经验，表单对象的定义和用途多种多样，概括如下：

是什么？做什么？ 一个普通的 ruby 对象，负责数据输入验证；代表多个模型对象的虚拟模型；替代强参数（白名单）；重构模型生命周期回调的一种方式；专门用于 form_for 的对象，简化控制器参数处理，进行类型强制和验证；封装多个 activerecord 模型，实现单个表单提交更新；具备 activerecord 的特性，便于控制器操作；管理复杂业务逻辑的对象。
为什么要用？主要目的？ 从控制器和/或模型中抽离业务逻辑；提供视图辅助方法（例如：复杂选项选择）；简化复杂表单（不直接映射到单个 ar 模型）的 rails 约定实现；降低控制器、模型（包括多个模型）和视图之间的耦合度。

然而，表单对象的概念存在模糊性。在使用表单对象时，其背后的设计理念和组合方式并不统一，缺乏明确的共识。总的来说，表单对象旨在重构代码复杂性，集中处理特定模块的职责（通常是模型和/或控制器）。

二、表单对象的反面案例分析

许多表单对象的使用方式如下：

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

登录后复制

这种写法看似符合 rails 约定，简洁明了。然而，通过分析其公共 api，可以发现：

new(params)：处理请求参数，进行数据转换，使其成为处理输入数据的好地方。
valid?：执行验证，了解参数、类型和验证规则，包含业务逻辑和领域规则。
save!：对象持久化，了解参数创建和持久层机制。
@form：传递到视图层，可能包含视图辅助逻辑（例如：form_for 的选项、条件渲染等）。

这种设计违反了单一职责原则，导致表单对象承担过多职责，成为新的“胖控制器/模型”，吸引了本应分散的代码，造成代码耦合。任何新增的视图辅助方法、验证规则或参数映射都可能被添加到表单对象中，使其越来越臃肿。

三、更优方案：职责分离

我们可能已经拥有负责这些职责的对象。与其使用表单对象，不如：

持久化： 模型的职责。
业务逻辑： 服务对象。
输入验证： 验证对象（例如：activerecord::model、scrivener、dry-schema）。
视图辅助方法： 视图模型/演示者对象。

在中等规模的应用中，这些组件可能已经存在。盲目使用表单对象反而会增加不必要的复杂性和模糊性。复杂的用例必然导致复杂的代码，掩盖复杂性并不能解决问题。

四、改进方案

基于以上分析，控制器代码可以重构为：

def new
  @form = someformviewmodel.new(default_values)
end

def create
  validation = somevalidation.new(action_params)
  if validation.valid?
    result = someservice.new(validation.params).call
    if result.success?
      redirect_to "somewhere", notice: "all good."
    else
      redirect_to "somewhere", alert: "uh oh... something went missing oops: #{result.errors}"
    end
  else
    @form = someformviewmodel.new
    render :new
  end
end

登录后复制

优点：