Rails 多态关联 - 控制器和视图？答案

【问题标题】：Rails polymorphic association - controllers and views?Rails 多态关联 - 控制器和视图？
【发布时间】：2014-02-13 01:48:01
【问题描述】：

我有一个模型User（用于身份验证），它通过Rails 中的多态关联连接到另外两个模型Customer 和Seller。客户和卖家必须有不同的注册表单，因为他们的数据不同，但可以使用一个登录表单，因为他们都是Users。为了分别管理客户和卖家资源，为他们创建各自的控制器和视图是一个好主意，还是应该在UsersController中完成所有用户的管理？

【问题讨论】：

我认为你应该使用单表继承（STI）而不是多态关联。客户和卖方是用户类型。然后您可以使用单一表单来管理这两种类型的用户的登录。
@madyrockss 我研究了单表继承但决定反对它，因为它涉及将客户数据与卖方数据放在同一个表中。这没有意义，因为我有很多不同的领域。我认为表格会变得混乱，我更愿意将它们放在单独的模型中，所以我选择了多态关联。

标签： ruby-on-rails model-view-controller ruby-on-rails-4 polymorphism polymorphic-associations

【解决方案1】：

这取决于客户和卖家两种观点的设计。如果两个视图的设计不同，那么我会鼓励您创建两个控制器 customers_controller 和 sellers_controller，并且您可能希望有一个用于常见操作的模块，例如 lib/authentication.rb.So

# customers_controller.rb
include Authentication
def some_action 
end

和

 # sellers_controller.rb
include Authentication
def other_action 
end

认证文件如

# lib/authentication.rb
module Authentication
  def common_method
  end
end

你可以有两个控制器和一个模块，你可以编写常用的方法/动作

【讨论】：

【解决方案2】：

正如@madyrockss 指出的那样，STI 可能是这里的方法，因为 User.find(params[:login]) 将自动返回 Customer 或 Seller 的实例。

我会鼓励忘记 UsersController 和视图，并鼓励从卖方和客户控制器/视图的角度进行思考（也就是说，不要共享单个控制器和视图，每个操作可以处理客户或卖方并在其中包含条件查看确定要显示的内容）。如果两个用户有不同的业务规则，那么随着业务规则的变化，整个事情很快就会变得一团糟，并且变得难以管理。

对于登录/注销，如果两者的表单相同，那么单个控制器就足够了，我会考虑与 UsersController 不同的名称，例如 SessionsController 在语义上更符合控制器的目的是。您不局限于一对一的模型控制器视图，许多刚开始 Rails 的开发人员会陷入陷阱。

【讨论】：

是的，我有一个 SessionsController 来管理登录。但我使用 UsersController 来 CRUD 用户。