【发布时间】：2014-01-19 06:07:24
【问题描述】：
我对 Rails 比较陌生，到目前为止只编写了一个应用程序。我在该应用程序中使用了 Devise 进行身份验证。现在我开始第二个了，我必须更多地考虑身份验证，因为我有很多用户类型，而不是我的第一个应用程序中的单一用户类型。
我一直在研究这些问题，以便当我将代码放到金属（或云）上时，我可以考虑到清晰的设计。
到目前为止，我发现这篇文章最有用：
背景
我正在创建一个在线市场，客户可以在其中从供应商处订购商品。
我打算创建以下用户类型：
- 客户：访问市场并订购商品
- 供应商：在市场上创造东西并处理订单
- 员工：为供应商工作
- 超级管理员：管理网站
- 管理员：管理由超级管理员委派的网站部分
以下字段是我确定的在上述三种用户类型之间共享的字段：
- 电子邮件地址（用作登录 ID）
- 手机号码
每个用户类型都有不同的字段（每个 4 - 6 个附加字段）。
客户和供应商将自行注册。员工和管理员将分别由提供商和超级管理员注册。
员工将与提供者相关联。我预计一名员工不会与多个提供商相关联。
我也不预见用户需要拥有多个角色。
我的计划
在对选项进行一些研究后，我决定如下：
我将创建三种不同的用户模型：
- 客户
- 提供者
- 超级管理员
在我看来，这些都是真正不同的用户，他们将与应用程序的不同部分进行交互，所以感觉很干净。根据我的研究，这种方法还允许我为每个用户类别完全定制注册程序。例如，我可以允许客户使用他们的 Facebook 帐户注册（使用 OmniAuth），但不能将此选项扩展到我的提供商。当然，超级管理员根本不会 :registerable。我知道每个用户都有单独的登录页面，这对我来说不是问题（实际上是可取的）。
拥有不同的模型，尤其是对于 Admin 也可以让我在以后轻松重构，以防我确实需要实现其他角色。
问题
上面的设计是否尽可能简单？没有任何作战计划能在与敌人的接触中幸存下来。但我希望 Rails 是我的朋友 :) 所以在纸面上，我的计划对我来说似乎很简单。有什么我遗漏的东西会使它的实现比纸上显示的更复杂吗？
此外，即使我已经制定了上述计划（双关语），我也愿意接受其他建议。例如，我是否有任何理由要对所有模型进行 STI（有一个用户模型，我的所有其他模型都从该模型继承）？
感谢阅读！
【问题讨论】：
-
您找到解决方案了吗？如果是，你能解释一下你做了什么吗？
-
@andreobrown 我遇到了同样的问题。你有它的解决方案吗？如果是，请解释一下。谢谢。
标签： ruby-on-rails devise single-table-inheritance sti