ruby-on-rails – 前端和后端是否由不同的控制器处理?

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – 前端和后端是否由不同的控制器处理?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我以前的学习项目中,我总是使用一个控制器,但现在我想知道这是否是良好的做法,甚至总是可能的.

在所有RESTful Rails教程中,控制器具有显示,编辑和索引视图.如果授权用户登录,则编辑视图可用,并且索引视图显示其他数据操纵控件,例如删除按钮或指向编辑视图的链接.

现在我有一个完全符合这种模式的Rails应用程序,但索引视图不可重用:

>普通用户看到一个闪光的索引页面,有很多图片,复杂的布局,没有Javascript的要求,…
>管理员用户索引具有完全不同的简约设计,jQuery表和大量附加数据,…

现在我不知道如何处理这种情况.我可以想到以下几点:

>单控制器,单视图:使用if语句将视图分割为两个大块/部分.
>单控制器,两个视图:index和index_admin.
>两个不同的控制器:BookController和BookAdminController

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

做这个的首选方法是什么?

解决方法

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

1).单控制器,单视图

我几乎从不选择这个解决方案,除非项目真的很简单,只有一两种用户.如果您获得多种用户类型,则最好使用解决方案#2.虽然此解决方案可能会吸引人,因为您认为通过编写较少的代码来节省自己一段时间,但最终,您的控制器和视图将会复杂化.更不用说你必须考虑的所有边缘案例.这通常是指错误.

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

2).多控制器,多视图

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

在“app / controllers”

class BookController < ApplicationController
end

并在“app / controllers / admin”

class Admin::BookController < Admin::BaseController
end

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

我不知道有没有更好的方法,但这是我从迄今为止所做的十几个项目中学到的…

猜你在找的Ruby相关文章