问基于Design和STI的多用户Rails应用程序设计

EN

到目前为止，我只编写了一个应用程序，所以我对Rails还比较陌生。我在那个应用程序中使用了用于认证的设计。现在我开始我的第二个，我必须更多地考虑身份验证，因为我有很多用户类型，而不是我的第一个应用程序中的单一用户类型。

我一直在研究这些问题，所以当我将代码放到金属(或云)中时，我可以在考虑到清晰的设计的情况下这样做。

到目前为止，我发现这篇文章最有用：

• devise and multiple "user" models

背景

我正在创建一个在线市场，在这个市场中，客户可以从供应商那里订购商品。

我计划创建以下用户类型：

• 客户:进入市场并订购商品。
• 供应商:在市场上创建产品并处理订单。
• 雇员:为提供者工作
• 超级管理员:管理网站
• Admin:管理由Super委托的部分站点

下面的字段是我在上述三种用户类型之间共享的：

• 电子邮件地址(用作登录ID)
• 移动号码

然后，每个用户类型都有不同的字段(每个字段添加4-6个字段)。

客户和供应商将自动注册.员工和管理员将分别由供应商和超级管理员注册。

员工将与提供程序关联。我没有预见到一个员工与不止一个提供者有关联。

我也没有预见到用户需要有多个角色。

我的计划

在对备选方案进行了一些研究之后，我决定如下：

我将创建三个不同的用户模型：

• 客户
• 提供程序
• 超级行政

在我看来，这些都是真正不同的用户，他们将与应用程序的不同部分交互，因此感觉很干净。根据我的研究，这种方法也允许我完全定制每个用户类别的注册程序。例如，我可以允许客户在他们的Facebook帐户注册(使用OmniAuth)，但不将此选项扩展到我的提供商。当然，超级管理员不会:可注册的。我知道每个用户都会有单独的登录页面，这对我来说不是一个问题(事实上，这是可取的)。

拥有不同的模型，特别是对于Admin，也允许我稍后轻松地重构，以防我确实需要实现其他角色。

问题

上面的设计是我所能做的最简单的吗？任何作战计划都不会在与敌人的接触中幸存。但我希望Rails是我的朋友:)所以纸上谈兵，我的计划对我来说很简单。有什么我遗漏的东西会使它的实现比纸上显示的更复杂吗？

此外，即使我设计了上述计划(双关意)，我愿意接受其他建议。例如，我是否有任何理由要对所有模型进行STI (有一个用户模型，所有其他模型都是从这个模型继承的)？

感谢您的阅读！