Les modèles Fat, contrôleurs de maigres et le modèle de conception MVC

Question

Je viens de lire un post de blog qui explique MVC bancaire analogie. J'ai quelques mois d'expérience en développement d'applications web avec un framework MVC (CakePHP), j'ai donc commencer par les bases, mais j'ai commencé à voir un thème qui m'a fait penser que je vais prendre une approche erronée à l'endroit où j'ai mis ma logique:

• Modèles de matières grasses, skinny contrôleurs
• Garder autant de la logique métier dans les modèles que possible

Dans mon application, les modèles sont anorexiques et les contrôleurs sont obèses. J'ai toute la logique métier dans les contrôleurs et rien en dehors des associations et des règles de validation dans les modèles.

Numérisation par le biais de mes contrôleurs, je peut maintenant identifier beaucoup de logique qui devrait probablement aller dans un modèle:

• L'application présente des listes, qui contiennent des éléments, et les éléments peuvent être classés. La logique de tri qui met la liste dans l'ordre de classement est dans un contrôleur.
• De même, des éléments (Élément de modèle) ont également des images (le modèle de l'Image). Chaque élément peut avoir une image par défaut (désigné par image_id dans la table des articles). Lorsqu'un élément est affiché avec ses images, l'image par défaut apparaît en premier. J'ai la logique qui fait cela dans un contrôleur.
• Lorsqu'une liste est affichée, les listes sont affichées dans la barre latérale. La logique permettant de déterminer quelles sont les listes connexes est dans un contrôleur.

Maintenant mes questions:

1. Avec les exemples que j'ai donnés ci-dessus, suis-je sur la bonne voie, de penser que ceux sont des instances de la logique actuellement un contrôleur de ce qui appartient à un modèle?
2. Quels sont les autres domaines de la logique, web apps, qui devrait aller dans les modèles?
3. Je suis sûr que l'identification de ce problème et de changer mon modèle de conception est la moitié de la bataille, mais même si je décide de prendre ces exemples que j'ai donnés ci-dessus et essayez de déplacer cette logique pour un modèle, je ne sais pas par où commencer. Quelqu'un peut me pointer dans la bonne direction par l'affichage du code ici, ou un lien vers quelques bonnes ressources d'apprentissage? CakePHP spécifiques aider ce serait génial, mais je suis sûr que rien MVC suffira.

Answer 1

C'est un peu difficile de vous donner les "bonnes" réponses, puisque certains d'entre eux face aux spécificités du cadre (indépendamment de ceux que vous travaillez avec).

Au moins en termes de CakePHP:

1. Oui

2. Tout ce qui traite des données ou de manipulation de données doit être dans un modèle. En termes de CakePHP, à propos d'une simple méthode find ()? ... Si il y a une chance qu'il va faire quelque chose de "spécial" (c'est à dire le rappel d'un ensemble spécifique de "condition"), vous devrez peut-être ailleurs, c'est une bonne excuse pour envelopper à l'intérieur d'un modèle de méthode.

3. Malheureusement, il n'y a jamais une réponse facile, et refactoring du code, c'est un processus naturel. Parfois, tu viens de te réveiller un aller: "saint-macaroni... qui devrait être dans les le modèle!" (eh bien, peut-être que vous ne le faites pas, mais je l'ai :))

Answer 2

Je suis en utilisant au moins ces deux "tests" pour vérifier si ma logique est à la bonne place:

1) Si j'écris un unittest, est est facile de n'en créer qu'un 'vrai' objet de faire le test (= l'objet que vous utilisez dans la production) et de ne pas inclure beaucoup d'autres, sauf peut-être quelques objets de valeur. Qui ont besoin d'un modèle réel de l'objet et un objet de contrôleur de faire un test pourrait être un signal que vous devez déplacer la fonctionnalité.

2) de me Poser la question: que faire si j'ai ajouté une autre façon d'utiliser ces classes, j'ai besoin de dupliquer les fonctionnalités d'une manière qui est presque copier-coller? ... C'est aussi probablement une bonne raison de se déplacer que de la fonctionnalité.

intéressant aussi: http://www.martinfowler.com/bliki/AnemicDomainModel.html

Answer 3

Voir aussi contrôleurs obèses, qui est plus au point.

Answer 4

Les Rails envie les gars ont une variation intéressante sur ce.