Comment organiser le contrôleur dans une application Rails moyennement grande?

Question

Je travaille sur une application avec un certain nombre de modèles connexes et je voudrais entendre quelques opinions sur la meilleure façon d'organiser les contrôleurs.

Voici quelques options que je suis: envisageais

1) Espace de noms des contrôleurs. Ainsi, par exemple, ayez un répertoire controllers/admin et un répertoire controllers/public. Cela semble attrayant pour l'organisation, mais aussi parce qu'une seule ressource peut souvent avoir des actions qui peuvent raisonnablement appartenir à des répertoires différents (par exemple, l'action show est publique alors que l'action create est admin). Donc, cela signifierait de séparer certaines de mes ressources en deux contrôleurs distincts - un public, un administrateur. Cela semble mauvais.

2) Créer des ressources imbriquées. Je n'ai utilisé que de temps en temps des ressources imbriquées, ce qui n'est pas toujours clair pour moi quand il est préférable d'imbriquer des ressources plutôt que de passer explicitement les données dont vous avez besoin à travers les paramètres. Quelqu'un a-t-il des suggestions/exemples de la meilleure façon d'utiliser des ressources imbriquées? Quand est-ce une bonne idée? Quand est-ce une surpêche?

3) Laissez simplement les contrôleurs d'échafaudage par défaut seuls. Créez de nouvelles actions de collection/membre si nécessaire et utilisez avant les filtres pour définir les autorisations dans chaque contrôleur. Cela semble plus attrayant car cela permet de garder les choses simples d'avance. Mais je suis un peu nerveux à propos des choses qui deviennent désordonnées car certains des contrôleurs pourraient commencer à gonfler avec plusieurs nouvelles actions.

Si quelqu'un ayant de l'expérience dans la conception de grandes applications pouvait vous donner quelques conseils, cela aurait été grandement apprécié.

Answer 1

Pour organiser au sein de nos applications, j'ai fait un peu de tout en fonction de la situation. Tout d'abord, en ce qui concerne les contrôleurs séparés pour les fonctions admin/user, je dirai que vous ne voulez probablement pas suivre cette voie. Nous avons utilisé l'autorisation et before_filter pour gérer les droits dans l'application. Nous avons roulé le nôtre, mais 20/20 hind-sight, nous devrions avoir utilisé CanCan. De là, vous pouvez configurer quelque chose comme ça (ce qui est pseudo-code, la langue réelle dépendrait de la façon dont vous mis en œuvre l'autorisation):

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 

Ou à un niveau supérieur

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

et dans votre contrôleur d'application Cela dépendrait de l'itinéraire, mais je l'utiliserais pour l'autorisation au lieu de séparer les contrôleurs.

En ce qui concerne les espaces de noms et les ressources imbriquées, cela dépend de la situation. Dans plusieurs de nos applications, nous avons les deux. Nous utilisons des espaces de noms lorsqu'il existe une cause de séparation logique ou qu'il y a des fonctions partagées entre un groupe de contrôleurs. Le cas et le point pour nous est que nous mettons des fonctions administratives dans un espace de noms, et au sein de nous avons des utilisateurs, des rôles et d'autres fonctions d'administration propriétaires.

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

puis dans ces contrôleurs, nous avons un contrôleur de base, qui stocke nos fonctions partagées.

class Admin::Base < ApplicationController 
    before_filter :require_admin 
end 

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

Cela nous permet une séparation logique des données et la capacité à tarir notre code un peu en partageant des choses comme le before_filter.

Nous utilisons des contrôleurs imbriqués s'il doit y avoir une section de code où vous voulez que certaines choses persistent entre les contrôleurs. Le cas de notre application est nos clients. Nous recherchons et chargeons un client, puis au sein de ce client, ils ont des commandes, des tickets, des emplacements. Dans cette zone, le client est chargé pendant que nous regardons les différents onglets.

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

et qui nous donne urls:

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

D'autres avantages que nous avons connus de c'est la facilité de mise en place de systèmes de menus et les onglets. Ces structures se prêtent bien à un site organisé.

J'espère que cela aide!

Answer 2

En outre, ressemble à des ressources de nidification plus d'un niveau profond est certainement une mauvaise idée:

http://weblog.jamisbuck.org/2007/2/5/nesting-resources

Ouais, c'est un ancien article, mais il fait beaucoup de sens pour moi.

Si quelqu'un n'est pas d'accord, j'aimerais savoir pourquoi.