每个用户强参数的最佳实践？

Question

我有一个带有Order 模型的应用程序，连接到Purchaser 和Supplier。该应用程序旨在限制谁可以创建/更新/销毁订单，具体取决于他们与这些公司的隶属关系。 （例如，采购员的成员可以创建订单，但供应商的成员不能。）

我正在通过强参数在控制器级别执行这些授权规则。我的理由是双重的：

1. 将它们推迟到before_save 回调（或其他模型逻辑）会从控制器（它所属的位置）移除参数筛选；和
2. 即便如此，我也必须将额外的信息（即用户身份）从控制器传递给模型才能完成，这将导致更紧密耦合的类。

目前，我的强参数逻辑如下所示：

def create_order_params
  params.require(:order).permit(:supplier_id, :purchaser_id, :notes)
    .merge({ placed_by: current_user })
end

def update_order_params
  params.require(:order).permit().tap do |p|
    p.merge!({ accepted_by: current_user }) if params.dig(:order, :accepted)
    if current_user.belongs_to?(@order.supplier)
      p.merge!(params[:order].permit(:discount, :discount_type))
    end
    if current_user.belongs_to?(@order.purchaser) && !@order.confirmed?
      p.merge!(params[:order].permit(:notes))
    end
  end
end

我认为它非常难以阅读。是否有更简洁（或被广泛接受）的模式将一些授权逻辑应用于强参数？或者，这是错误的抽象吗？毕竟我应该将此授权推迟到模型吗？

Answer 1

由于每种类型 [Purchasers 或 Suppliers] 都有一些权限 [或功能要做]，并且是唯一有权执行此类操作的人，因此我建议您将每种类型的任务作为方法放在 [Purchasers或 Suppliers] 类，具体取决于哪个必须执行此方法或任务。

例如：

由于采购者只是创建订单的人，所以在采购者类中放置一个创建订单方法是合理的，这样每个对象都有它需要承载的职责，而这些方法不能承载或任何其他实体都可以访问，因为它们没有封装这些方法。

以面向对象的方式思考，并考虑“单一责任原则”，将引导您更好地组织和使代码更干净。