为了在我们的应用程序中进行组织,我根据情况做了一些事情。
首先,关于管理/用户功能的单独控制器,我会说您可能不想走那条路。我们使用了授权和before_filter
管理应用程序内的权限。我们自己推出了,但事后看来,我们应该有用CanCan http://github.com/ryanb/cancan。从那里您可以设置类似的内容(这是伪代码,实际语言取决于您如何实现授权):
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]
并在您的应用程序控制器中
def require_admin
redirect_to never_never_land_path unless current_user.administrator?
end
这取决于哪条路线,但我会使用它来进行授权,而不是拆分控制器。
至于名称空间与嵌套资源,这取决于具体情况。在我们的几个应用程序中,我们两者兼而有之。当存在逻辑分离或一组控制器之间存在共享功能时,我们使用名称空间。我们的案例和要点是,我们将管理功能放在命名空间中,并且在其中我们有用户、角色和其他专有管理功能。
map.namespace :admin do |admin|
admin.resources :users
admin.resources :roles
end
然后在这些控制器中,我们有一个基本控制器,用于存储我们的共享函数。
class Admin::Base < ApplicationController
before_filter :require_admin
end
class Admin::UsersController < Admin::Base
def new
....
end
这为我们提供了数据的逻辑分离以及通过共享诸如before_filter
.
如果您希望在一段代码中某些内容在控制器之间保留,我们会使用嵌套控制器。我们的应用案例是我们的客户。我们搜索并加载客户,然后在该客户中,他们有订单、票据和位置。在该区域内,我们在查看不同的选项卡时加载了客户。
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
我们从中体验到的其他优点是易于设置菜单系统和选项卡。这些结构非常适合组织有序的场地。
我希望这有帮助!