3

我正在开发我的第一个真正的 Rails 应用程序,用于在公司进行时间跟踪,并且遇到了数据库/模型设计问题。我的应用程序有一个用户模型和一个角色模型,它们通过 has_and_belongs_to_many 关联链接在一起。

角色之一是经理。一个经理可以有很多助理,助理可以有很多经理(尽管通常只有一个)。这种关系通过在 User 模型中表示为 manager_assistant_relationship 表示:

has_many :assistants, :through => :manager_assistant_relationships
has_many :managers, :through => :manager_assistant_relationships

助理可以有很多班次(代表工作班次的不同模型),经理可以有很多客户(另一种为助理工作计费的模型)。更多的协会即将到来。

据我所知,唯一的解决方案是将所有这些关系放在 User 模型中,但是对此感觉有些不对劲,并且随着角色的增加和关联的增加,User 模型可能会变得臃肿,而且看起来也不直观,因为 User 只有如果他是经理,很多助手。我想要一些关于这种方法的潜在陷阱以及我应该考虑哪些替代方案的建议。

将 User 模型子类化为角色会是一个好主意吗?

4

1 回答 1

1

好消息,您在角色方面做得正确。

要回答您的问题,,根据您的描述对 User 模型进行子类化不是一个好主意。如果你这样做了,它往往会导致棘手的关联自连接、STI(单表继承)、继承或类而不是模块的组合。使用角色要好得多。

它可以帮助您将用户视为一个人,而不是一个角色。所以 User 类只包含个人信息,例如姓名、生日、身高,可能还有电子邮件地址、登录密码等。将个人信息与时间跟踪角色分开。

要使用您的角色,您可以像以下伪代码那样建立模型关系:

 class Manager
   has_many :clients
 end

 manager = Manager.find(id)
 client = manager.clients.first

或者像这个伪代码:

 class Assistant
   has_many :workshifts
 end

 assistant = Assistant.find(id)
 workshift = assistant.workshifts

喜欢使用角色的其他充分理由是基于角色的访问控制 (RBAC)数据上下文交互 (DCI) ,如果您想了解这些。

于 2012-11-23T03:13:47.703 回答