在大型Rails应用程序中如何组织控制器? [英] How to organize controller in moderately large Rails application?

问题描述

我正在开发具有许多相关模型的应用程序，并且希望听到一些有关如何最好地组织控制器的意见.

I'm working on an application with quite a few related models and would like to hear some opinions on how best to organize the controllers.

以下是我一直在考虑的一些选择:

Here are some options I have been considering:

1)给控制器命名空间.因此，例如，具有一个controllers/admin目录和一个controllers/public目录.这对于组织来说似乎很有吸引力，但也有些许误解，因为单个资源通常可能具有明智地属于不同目录的操作(例如，show操作是公共的，而create操作是admin).因此，这意味着将我的一些资源分解为两个单独的控制器-一个公共，一个管理员.似乎很糟糕.

1) Namespace the controllers. So, for example, have a controllers/admin directory and a controllers/public directory. This seems appealing for organization but also sorta contrived since a single resource could often have actions which might sensibly belong in different directories (e.g. the show action is public whereas the create action is admin). So this would mean breaking up some of my resources into two separate controllers - one public, one admin. Seems bad.

2)创建嵌套资源.我只是偶尔使用嵌套的资源，所以相对于仅将所需的数据显式传递给参数而言，何时嵌套最佳资源并不总是使我明白.是否有人对如何最好地使用嵌套资源有一些建议/示例?什么时候是个好主意?什么时候过量?

2) Create nested resources. I've only occasionally used nested resources so it's not always clear to me when it's best to nest resources versus simply passing the data you need through the params explicitly. Does anyone has some suggestions/examples of how best to use nested resources? When is it a good idea? When is it an overkill?

3)仅保留默认的脚手架控制器即可.在需要的地方创建新的集合/成员操作，并在过滤器之前使用它来设置每个控制器内的权限.这似乎最吸引人，因为它使事情变得简单起来.但是我有点担心事情会变得一团糟，因为某些控制器可能会因一些新动作而开始膨胀.

3) Just leave the default scaffolded controllers alone. Create new collection/member actions where needed and use before filters to set permissions within each controller. This seems most appealing since it keeps things simple upfront. But I'm sorta nervous about things getting messy down the line as some of the controllers might start to bloat with several new actions.

如果有设计大型应用程序的经验的人可以在这里提供一些指导，将不胜感激.

If anyone with experience designing large applications could offer some guidance here, it'd greatly appreciated.

推荐答案

要在我们的应用程序中进行组织，我会根据情况做一些事情.

For organizing within our applications, I have done a little bit of everything depending on the situation.

首先，关于用于管理员/用户功能的单独控制器，我会说您可能不想走这条路.我们使用授权和before_filter来管理应用程序内的权限.我们采用了自己的方式，但事后观察20/20，我们应该使用 Can .在这里，您可以设置类似的内容(这是伪代码，实际语言取决于您实施授权的方式):

First, regarding the separate controllers for admin/user functions, I will say that you probably don't want to go that route. We used authorization and before_filter to manage rights within the application. We rolled our own, but 20/20 hind-sight, we should have use CanCan. From there you can setup something like this (this is pseudo-code, actual language would depend on how you implemented authorization):

before_filter :can_edit_user, :only => [:new, :create, :edit, :update] #or :except => [:index, :show]

protected

def can_edit_user
  redirect_to never_never_land_path unless current_user.has_rights?('edit_user')
end

或更高级

before_filter :require_admin, :only [:new, :create]

并在您的应用程序控制器中

and in your application controller

def require_admin
  redirect_to never_never_land_path unless current_user.administrator?
end

这取决于哪条路由，但我将其用于授权而不是拆分控制器.

It would depend which route, but I would use that for authorization instead of splitting up controllers.

就名称空间与嵌套资源而言，取决于情况.在我们的几个应用程序中，我们都有.当逻辑上有分隔的原因或一组控制器之间存在共享功能时，我们将使用名称空间.对我们而言，案例和要点是，我们将管理功能放在一个名称空间中，并且其中包含用户，角色和其他专有管理功能.

As far as name spaces vs. Nested Resources, it depends on the situation. In several of our apps, we have both. We use name spaces when there is a cause for a logical separation or there will be shared functions between a group of controllers. Case and point for us is we put administrative functions within a namespace, and within we have users, roles and other proprietary admin functions.

map.namespace :admin do |admin|
  admin.resources :users
  admin.resources :roles
end

然后在这些控制器中，我们有一个基本控制器，用于存储我们的共享功能.

and then within those controllers we have a base controller, that stores our shared functions.

class Admin::Base < ApplicationController
  before_filter :require_admin
end

class Admin::UsersController < Admin::Base
  def new
   ....
end

这为我们提供了逻辑上的数据分离，并能够通过共享诸如before_filter之类的东西来使代码枯竭.

This provides us logical separation of data and the ability to dry up our code a bit by sharing things like the before_filter.

如果要在一段代码中希望某些东西在控制器之间持久存在，我们将使用嵌套控制器.我们的应用案例就是我们的客户.我们搜索并加载客户，然后在该客户内获得订单，票据，位置.在该区域中，当我们查看不同的选项卡时，我们会吸引客户.

We use nested controllers if there is going to be a section of code where you want some things to persist between controllers. The case from our application is our customers. We search for and load a customer and then within that customer, they have orders, tickets, locations. Within that area we have the customer loaded while we look at the different tabs.

map.resources :customers do |customer|
  customer.resources :tickets
  customer.resources :orders
  customer.resources :locations
end

这会给我们网址:

customers/:id
customers/:customer_id/orders/:id
customers/:customer_id/tickets/:id

我们从中获得的其他优势是易于设置菜单系统和选项卡.这些结构非常适合有组织的站点.

Other advantages we have experienced from this is ease of setting up menu systems and tabs. These structures lend themselves well to an organized site.

我希望这会有所帮助！

这篇关于在大型Rails应用程序中如何组织控制器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！