6

我一直在用头撞墙，试图绕过这个，所以任何指导都将不胜感激......

我想要一个用户系统设置来反映以下层次结构：

User
|- email address
|- password
|- billing information
|- contact information
|- account preferences
|
|=> Agent
|=> - agent-specific information
|=> - has_many Users
|=> - belongs_to Manager
|
|=> Manager
|=> - manager-specific information
|=> - has_many Agents, Users
|
|=> Administrator
|=> - can manage everything

我已经有一个User带有Devise和CanCan设置的模型来处理身份验证和授权，所以我知道如何使用角色将用户类型限制为特定操作，等等。

我迷失的是如何在我的 Rails 代码和数据库中组织这些子类关系。正如您从上面看到的Agent，Manager、 和Administrator都共享包含在 中的信息User，但每个都有附加的功能和与之相关的信息。

我读过一些关于STI、多态关联和自引用关联的内容。

如果我使用 STI，该User表必须包含我的所有 [ Agent/ Manager/ Administrator] 特定信息的字段，对吗？那会使我的User桌子很大，这是我想避免的。相反，如果我使用多态，那么我是否不必User在所有其他类型的User子类表中复制所有公共信息？

为了增加我的困惑，我无法理解上述问题的答案如何与子类之间的关系一起工作（例如，Managerhas_many Agents，但两者都是User...的子类？？）。

我真的很感谢有人通过详细的回答让我明白这一点，该回答适当考虑了代码的可读性和数据完整性，它简单地解释了（就像对 Rails 新手一样）为什么 A 是最好的方法以及为什么 B 或n是——通过比较——对于这种情况不是一个好方法，并且给出了实现上述关系的示例代码。我想解决这个问题，但更重要的是，我想了解这个解决方案为什么有效！

4

2 回答 2

8

我认为没有一个简单的解释为什么任何方法在任何情况下都是最好的。Stack Overflow 上的大量问题是关于如何设计模型之间的关系的问题。这是一个复杂的话题，正确的解决方案需要对您正在解决的问题有深入的了解。即便如此，前几次你也可能不会做对。

到目前为止，最好的方法是在这个问题上完全使用 TDD/BDD，并让测试/规范驱动你的设计。不要害怕重构，你会找到更好的方法。大多数时候，只有在尝试了几个错误的解决方案之后，您才会看到正确的解决方案。您将了解边缘情况。正如 Ward Cunningham 在他的“技术债务”类比中所说：“事后重构，就好像你从一开始就知道自己在做什么一样”。不过，请务必进行验收测试以验证其行为。

更具体地解决您的问题。还有第三种选择，那就是完全拆分班级，每个班级都有自己的表格。我已经在我当前的项目中尝试过，我喜欢它。如果在您的业务领域没有意义，您不需要定义类似user的东西。如果他们有共同的行为，请使用 mixins。最重要的警告是，让他们不再通过相同的表单登录并不简单。

我有管理员、招聘人员、供应商和访客模型。它们都是独立的模型，与 mixins 共享一些行为。他们都有自己的命名空间控制器来操作。例如，管理员的所有操作都在后端命名空间中。也有一个命名空间的 ApplicationController。Backend::ApplicationController 简单地指定before_filter :authorize_admin!. 没有切换，没有复杂的案例陈述，什么都没有。

您需要特别注意约定。如果你在模型中使用相同的名字，你的 mixin 会变得超级简单。阅读 ActiveSupport::Concern 以使 mixin 更易于使用。我有一个这样的混合：

module Account
  extend ActiveSupport::Concern
  included do
    devise :database_authenticatable, :trackable, :recoverable, :rememberable
  end
end

在我的路线中：

devise_for :recruiters
devise_for :suppliers
# etc...

app/controllers/backend/application_controller.rb看起来像这样：

class Backend::ApplicationController < ::ApplicationController
  layout "backend"
  before_filter :authenticate_admin!
  def current_ability
    @current_ability ||= AdminAbility.new(current_admin)
  end
end

所以，总结一下。任何架构都可以工作。STI 和多态性各有千秋，但请务必根据您的领域对架构进行建模。Ruby 是一种非常灵活的语言，您可以利用它来发挥自己的优势。Devise 和 CanCan 是优秀的宝石，可以轻松处理这些情况。我向您展示了我目前正在从事的项目的解决方案。它对我很有效，但我不能说它是否适合你。当你觉得自己做出了错误的决定时，不要害怕尝试和重构，而不是不断修补你最初的想法。

PS。说到 STI 和关系：它们也可以很好地协同工作。您可以定义从一个子类到另一个子类的关系。这一切都会按预期工作。

于 2010-12-11T17:25:55.250 回答
0

过度思考这一点可能很诱人，但我不相信你想做的事情非常复杂。

STI 在这里可能不是最好的主意，因为您将用户限制为不超过这些关键角色之一。

至于存储会员特定信息，我不确定当您为 STI 添加列时您的表是否会“巨大”。如果它们为空，则它们并没有真正消耗任何资源。如果您不需要对该数据进行选择，则可以考虑使用单个列role_information，然后使用serialize :role_information，以便您可以定义哈希并将其存储在列中。

另一种选择是覆盖方法，以便它们在响应时检查角色成员资格，即：

has_many :agents
def agents
  return nil unless self.has_role(:manager) 
  return self[:agents]
end

将“has_role”替换为检查角色成员资格所需的任何内容。

您也可以在设置方面执行此操作。

特定功能的授权应该在您的控制器中完成，因此您应该在此时检查角色成员资格。

于 2010-12-11T17:31:05.913 回答