Modèles de graisse, contrôleurs maigres et le modèle de conception MVC

Question

Je viens de lire un blog post qui explique MVC avec une analogie bancaire. J'ai quelques mois d'expérience avec le développement d'applications web avec un framework MVC (CakePHP), donc j'ai les bases, mais j'ai commencé à voir un thème qui m'a fait penser que je suis en train d'utiliser ma logique:

• modèles Fat, contrôleurs maigres
• Gardez autant 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 d'autre que des associations et des règles de validation dans les modèles.

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

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

maintenant à mes questions:

1. Avec les exemples que j'ai ci-dessus, je suis sur la bonne voie en pensant que ce sont des cas de logique actuellement dans un contrôleur qui appartient à un modèle?
2. Quels sont les autres domaines de la logique, communs aux applications web, qui devraient aller dans les modèles?
3. Je suis sûr que l'identification de ce problème et la modification de mon modèle de conception est la moitié de la bataille, mais même si je décide de prendre ces exemples ci-dessus et d'essayer de déplacer cette logique, je ne saurais pas par où commencer. . Quelqu'un peut-il me diriger dans la bonne direction en publiant du code ici, ou en liant à de bonnes ressources d'apprentissage? L'aide spécifique de CakePHP serait formidable, mais je suis sûr que tout ce que MVC suffira.

Answer 1

Il est un peu difficile de vous donner les réponses « droit », puisque certains d'entre eux traitent avec les spécificités du cadre (quel que ceux que vous travaillez).

au moins en termes de CakePHP:

1. Oui

2. Tout ce qui traite des données ou la manipulation de données devrait être un modèle. En termes de CakePHP, qu'en est-il de la méthode simple find()? ... S'il y a une chance qu'il fasse quelque chose de "spécial" (c'est-à-dire rappeler un ensemble spécifique de 'condition'), dont vous pourriez avoir besoin ailleurs, c'est une bonne excuse pour envelopper la méthode d'un modèle.

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

Answer 2

J'utilise au moins ces deux « tests » pour vérifier si ma logique est au bon endroit:

1) Si j'écris un unittest, est est facile de créer seulement un « réel 'objet de faire le test sur (= l'objet que vous utilisez en production) et ne pas en inclure beaucoup d'autres, sauf peut-être certains objets de valeur. Si vous avez besoin à la fois d'un objet de modèle réel et d'un objet de contrôleur réel pour effectuer un test, cela peut être un signal dont vous devez déplacer la fonctionnalité.

2) Posez-moi la question: que se passe-t-il si j'ajoute une autre façon d'utiliser ces classes, aurais-je besoin de dupliquer la fonctionnalité d'une manière qui est presque copier-coller? ... C'est aussi probablement une bonne raison de déplacer cette fonctionnalité.

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