前端和后端应该由不同的控制器处理吗? [英] Should frontend and backend be handled by different controllers?

查看:33
本文介绍了前端和后端应该由不同的控制器处理吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

In my previous learning projects I always used a single controller, but now I wonder if that is good practice or even always possible.

在所有 RESTful Rails 教程中,控制器都有一个 show、一个 edit 和一个 index 视图.如果授权用户登录,edit 视图变为可用,index 视图显示额外的数据操作控件,如删除按钮或 edit 的链接 查看.

In all RESTful Rails tutorials the controllers have a show, an edit and an index view. If an authorized user is logged on, the edit view becomes available and the index view shows additional data manipulation controls, like a delete button or a link to the edit view.

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

Now I have a Rails application which falls exactly into this pattern, but the index view is not reusable:

  1. 普通用户看到的是一个华丽的索引页,里面有很多图片、复杂的布局、没有Javascript要求……
  2. Admin 用户索引具有完全不同的简约设计、jQuery 表和大量附加数据,...

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

Now I'm not sure how to handle this case. I can think of the following:

  1. 单个控制器,单个视图:使用 if 语句将视图分成两个大块/部分.
  2. 单个控制器,两个视图:indexindex_admin.
  3. 两个不同的控制器:BookControllerBookAdminController
  1. Single controller, single view: The view is split into two large blocks/partials using an if statement.
  2. Single controller, two views: index and index_admin.
  3. Two different controllers: BookController and BookAdminController

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

None of these solutions seems perfect, but for now I'm inclined to use the 3rd option.

执行此操作的首选方法是什么?

What's the preferred way to do this?

推荐答案

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

I asked myself this question almost every time when I get a new project. I usually choose one of the two solutions:

1).单控制器,单视图

1). Single Controller, Single View

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

I almost never choose this solution now a days unless the project is really simple, and only one or two types of users. If you get multiple user types it is better to use solution # 2. Although this solution may be appealing because you think you save yourself some time by writing less code, but in the end, your controller and view will grow in complexity. Not to mention all the edge cases you have to consider. This usually means bugs.

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

My company once had to rescue a failed project, it had 3 user types. (admin, business, and member). They used solution #1. The code was in a horrible condition, ( and that's why we were asked to rescue this project) We were jokingly saying it is not MVC, it was MMM. (Model-Model-Model) This is because business logic was not properly extracted and put into models, but spread in controllers and views as well.

2).多控制器,多视图

2). Multiple Controller, Multiple Views

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

I use this solution more and more these days. I usually namespace the controllers with user types. For example:

在应用程序/控制器"中

In "app/controllers"

class BookController < ApplicationController
end

在app/controllers/admin"中

and in "app/controllers/admin"

class Admin::BookController < Admin::BaseController
end

我填写BookController时只需要考虑普通用户,填写Admin::BookController时只需要考虑admin用户

I only need to consider regular users when I fill in BookController, and only need to consider admin users when I fill in Admin::BookController

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

I'm not sure if there are better ways, but this is what I learned from a dozen projects I've done so far...

这篇关于前端和后端应该由不同的控制器处理吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆