Rails de modèle, vue, contrôleur et Helper : ce qui va où ?

Question

En Ruby on Rails de développement (ou MVC en général), quelle règle rapide dois-je suivre pour savoir où mettre la logique.

Veuillez répondre par l’affirmative - mettre ceci ici, plutôt que de n’y mettre que.

Answer 1

MVC

Contrôleur: Mettre le code ici qui a à voir avec ce que l'utilisateur veut, et de décider ce que pour leur donner du travail, s'ils sont connectés, qu'ils devraient voir certaines données, etc. En fin de compte, le contrôleur examine les demandes et travaille en ce que les données (Modèles) pour afficher et les points de Vue pour le rendu. Si vous êtes dans le doute quant à savoir si le code doit aller dans le contrôleur, alors il ne devrait probablement pas. Gardez vos contrôleurs maigre.

La vue: La vue ne doit contenir que le minimum de code pour l'affichage des données (Modèle), il ne devrait pas faire beaucoup de traitement ou de calcul, il convient de l'affichage des données calculées (ou résumé) par le Modèle, ou généré à partir du Contrôleur. Si votre Vue a vraiment besoin de faire un traitement qui ne peut être fait par le Modèle ou le Contrôleur, mettre le code dans un Helper. Beaucoup de code Ruby dans une Vue de la page de balisage difficile à lire.

Modèle: Votre modèle doit être là où tous votre code qui se rapporte à vos données (les entités qui composent votre site par exemple, les Utilisateurs, les Postes, les Comptes, les Amis etc.) vie. Si le code doit enregistrer, mettre à jour ou de résumer les données liées à vos entités, de le mettre ici. Il sera ré-utilisable à travers vos Vues et les Contrôleurs.

Answer 2

Ce que pauliephoic dit, mais n’oubliez pas ceci :

Answer 3

Pour ajouter au commentaire de pauliephonic :

Helper: fonctions pour rendre plus facile la création de la vue. Par exemple, si vous êtes toujours itération sur une liste de widgets pour afficher leur prix, mettez-la dans un programme d’assistance (avec une partielle pour l’affichage réel). Ou si vous avez un morceau de rjs que vous ne voulez pas encombrer la vue, mettez-la dans un programme d’assistance.

Answer 4

Le modèle MVC est vraiment le seul souci de l'INTERFACE utilisateur et rien d'autre. Il ne faut pas mettre toute logique complexe dans le contrôleur contrôle de la vue, mais pas la logique. Le Contrôleur devrait se préoccuper avec la sélection de la bonne vue et délégué des trucs plus complexe pour le modèle de domaine (Modèle) ou de la couche de gestion.

Domain Driven Design a une notion de Services qui est un lieu de vous en tenir à la logique doit orchestrer un certain nombre de différents types d'objets, ce qui signifie généralement une logique qui n'est pas naturellement appartiennent à une classe de Modèle.

En général, je pense que de la couche de Service que l'API de mes applications. Mes Services couches habituellement carte d'assez près aux exigences de l'application que je suis en créant ainsi la couche de Service agit comme une simplification de la complexité des interactions trouvé dans les niveaux inférieurs de mon application, c'est à dire que vous pourriez accomplir le même objectif en contournant les couches de Service, mais vous auriez à tirer beaucoup plus de leviers pour le faire fonctionner.

Notez que je ne parle pas des Rails ici je parle d'un général du style architectural de votre problème particulier.

Answer 5

Parfait explications ici déjà, une simple phrase comme conclusion et facile à retenir :

Nous avons besoin de modèles intelligents, les contrôleurs minces et vues muets.

http://C2.com/cgi/wiki?ModelViewController