应该由不同的控制器处理前端和后端吗？

在我之前的学习项目中,我总是使用单个控制器,但现在我想知道这是好的做法还是总是可行的.

在所有RESTful Rails教程中,控制器都有一个show,一个edit和一个index视图.如果授权用户已登录,则edit视图将变为可用,并且index视图将显示其他数据操作控件,如删除按钮或edit视图链接.

现在我有一个Rails应用程序完全属于这种模式,但index视图不可重用:

普通用户看到一个华丽的索引页面,包含大量图片,复杂的布局,没有Javascript要求,......

Admin用户索引具有完全不同的简约设计,jQuery表和许多其他数据,...

现在我不知道如何处理这个案子.我能想到以下几点:

单个控制器,单个视图:使用if语句将视图拆分为两个大块/部分.

单控制器,两个视图:index和index_admin.

两个不同的控制器:BookController和BookAdminController

这些解决方案似乎都不是完美的,但是现在我倾向于使用第三种选择.

这样做的首选方法是什么？

几乎每次我得到一个新项目时,我都会问自己这个问题.我通常会选择以下两种解决方案之一:

1).单控制器,单视图

除非项目非常简单,并且只有一两种类型的用户,否则我现在几乎从不选择此解决方案.如果您获得多种用户类型,最好使用解决方案#2.虽然这种解决方案可能很有吸引力,因为您认为通过编写更少的代码可以节省一些时间,但最终,您的控制器和视图的复杂性会增加.更不用说你必须考虑的所有边缘情况.这通常意味着错误.

我的公司曾经不得不救出一个失败的项目,它有3种用户类型.(管理员,业务和成员).他们使用了解决方案#1.代码处于可怕的状态,(这就是我们被要求拯救这个项目的原因)我们开玩笑地说它不是MVC,而是MMM.(模型 - 模型 - 模型)这是因为业务逻辑没有被正确地提取并放入模型中,而是在控制器和视图中传播.

2).多个控制器,多视图

这些天我越来越多地使用这个解决方案.我通常使用用户类型命名控制器.例如:

在"app/controllers"中

class BookController < ApplicationController
end

在"app/controllers/admin"中

class Admin::BookController < Admin::BaseController
end

我只需要在填写BookController时考虑普通用户,并且在填写时只需要考虑管理员用户 Admin::BookController

我不确定是否有更好的方法,但这是我从目前为止所完成的十几个项目中学到的...