使用Devise和STI设计具有多种用户类型的Rails应用程序

时间:2014-01-01 18:49:07

标签: ruby-on-rails devise single-table-inheritance sti

我对Rails相对较新,到目前为止只编写了一个应用程序。我在该应用程序中使用Devise进行身份验证。现在我要进入第二个,因为我有很多用户类型,而不是我的第一个应用程序中的单个用户类型,所以我需要更多地考虑身份验证。

我一直在研究这些问题,这样当我将代码放到金属(或云端)时,我可以考虑清晰的设计。

到目前为止,我发现这篇文章最有用:

背景

我正在创建一个在线市场,客户可以在其中订购供应商的产品。

我打算创建以下用户类型:

  • 客户:访问市场并订购内容
  • 提供商:在市场中创建并处理订单
  • 员工:适用于提供商
  • 超级管理员:管理网站
  • 管理员:管理由超级管理员委派的部分网站

以下字段是我在上述三种用户类型之间共享的内容:

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

每个用户类型都有不同的字段(每个字段有4到6个字段)。

客户和提供商将自行注册。员工和管理员将分别由提供商和超级管理员注册。

员工将与提供商相关联。我不认为员工与多个提供商有关联。

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

我的计划

在对选项进行一些研究后,我决定了以下内容:

我将创建三种不同的用户模型:

  • 客户
  • 提供商
  • 超级管理员

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

拥有不同的模型,特别是对于Admin,我也可以在以后轻松重构,以防我需要实现其他角色。

问题

上面的设计是否像我能做到的那么简单?没有任何战斗计划能够与敌人保持联系。但我希望Rails是我的朋友:)所以在纸面上,我的计划对我来说似乎很简单。有什么我想念的东西会使它的实现比纸上的更复杂吗?

此外,即使我已经设计了上述计划(双关语),我也愿意接受其他建议。例如,有什么理由我想为所有模型做STI(有一个用户模型,我的所有其他模型都继承了这个模型)?

感谢阅读!

1 个答案:

答案 0 :(得分:1)

Rails Cast有一个非常可靠的解决方案来处理您的解决方案引入的至少一些复杂性。 Bates向User模型引入了一个roles属性,该属性封装了用户拥有的角色。他将这与宝石CanCan结合起来决定哪个角色可以执行哪些动作。

查看http://railscasts.com/episodes/192-authorization-with-cancan?view=asciicast

首先看看他如何设置和获取角色属性,然后看看他是如何与CanCan结合的。