如果前端和后端不同的控制器来处理? [英] Should frontend and backend be handled by different controllers?

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

问题描述

在我的previous学习项目,我总是用一个控制器,但现在我不知道这是很好的做法,甚至总是可能的。

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的教程控制器有一个显示,一个修改首页视图。如果一个授权用户登录时,修改查看可用和首页视图显示额外的数据操作控件,比如一个删除按钮或在编辑链接视图。

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应用程序,它正好落在这个格局,但首页视图是不可重用的:

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


  1. 普通用户看到一个华而不实的索引页有很多的图片,复杂的布局,没有使用Javascript的要求,...

  2. 管理员用户指数有完全地不同简约设计,jQuery的表格和大量的附加数据,...

现在我不知道如何处理这种情况。我能想到如下:

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


  1. 单控制器,单一视图:该视图分为使用如果语句两大块/谐音

  2. 单控制器,两种观点:首页 index_admin

  3. 两种不同的控制器: BookController的 BookAdminController

  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.

什么是preferred方式做到这一点?

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,虽然,因为你觉得你少写code保存自己一些时间这种解决方案可能是有吸引力的,但最终,你的控制器和视图将越来越复杂。更何况,你必须考虑所有的边缘情况。这通常意味着错误。

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。在code是一个可怕的情况,(这就是为什么我们被要求拯救这个项目)我们开玩笑说这是不是MVC,这是MMM。 (模型模型模型)这是因为业务逻辑没有被正确提取,投入车型,但在控制器和视图小号$ P $垫为好。

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:

在应用程序/控制器

class BookController < ApplicationController
end

在应用程序/控制器/管理

and in "app/controllers/admin"

class Admin::BookController < Admin::BaseController
end

我只需要考虑普通用户,当我填写BookController的,只需要考虑管理员用户,当我填写联系:: 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天全站免登陆