【发布时间】：2016-04-06 09:54:32
【问题描述】：
我刚刚挑选的应用中有两种类型的用户需要增强。
Admins，谁都能做到
RoomAdmins, 谁只能管理与他们的房间有关的任何事情 - 比如添加
属于房间的父母。
例如，RoomAdmins 在他们注册时，可以为他们的房间 CRUD Parents（已经有一个RoomAdmin/ParentsController）。
现在我需要让Admins 能够管理Parents。那么我应该创建一个Admin/ParentsController 并创建一组特定于这些用例的视图吗？
或者是'Rails'约定将RoomAdmin/ParentsController移动到app/controllers并让RoomAdmins和Admins共享该控制器？这将使控制器更加复杂（以及视图）。
请记住，每种 Admin 类型的视图会略有不同，并且每个操作中的逻辑会略有不同，具体取决于我们在每个操作之后路由到的位置，具体取决于它是 Admin 还是 RoomAdmin 在执行该操作父母。
那么 Rails 约定是哪个选项？
A - 单独的控制器，单独的视图
B - 一个控制器，一组视图，更复杂的逻辑来处理差异？
编辑
这里我忘记了额外的复杂性，即控制器继承链，因为两种类型的用户都有不同的主要布局和登录过程：
目前处理房间的所有控制器都继承自RoomAdminsController。
所有处理管理功能的控制器都继承自AdminController。
所以RoomAdmin/ParentsController 当前继承自RoomAdminsController。
如果我移动它，它会继承哪一个？啊！
【问题讨论】：
-
你自己为用户实现逻辑吗？还是使用 Devise 之类的东西？
-
将 ParentsController 移动到应用程序/控制器并根据要求创建不同的操作。根据 DRY 主体避免重复代码。
-
我认为这没有约定。我将有一个管理区域并使用cancancan 来处理逻辑，为用户指定不同的角色并授予他们访问不同操作的权限。
-
@JamesWatling Devise 正在创建管理员和 PodAdmins
-
@j-dexx 这将需要重写大约 50% 的应用程序。请参阅我的编辑 - 整个应用程序已经为两种类型的用户编写了一个完全独立的结构:(
标签： ruby-on-rails