Couches de service et référentiels

Question

J'utilise les frameworks MVC depuis peu de temps et j'aime beaucoup la façon dont les problèmes sont séparés. J'ai la mauvaise habitude de laisser les contrôleurs faire beaucoup de travail. Donc, je cherche vraiment des conseils.

Lorsque j'ai commencé à utiliser MVC, le contrôleur manipulait souvent les modèles une fois le travail effectué sur la base de données. Je savais que c'était mauvais, donc déplacé dans les modèles. Cependant, je ne suis pas content de cela car je veux que mes modèles soient très instructifs.

J'ai lu un peu et je constate que les gens gardent leurs contrôleurs et leurs modèles allégés en disposant d'une couche de service, ce que j'aime bien.

J'essaie simplement de comprendre comment une couche de service et un référentiel devraient tous fonctionner ensemble. Voici mes hypothèses, pouvez-vous s'il vous plaît laissez-moi savoir si c'est une bonne façon de travailler?

1. Le contrôleur peut appeler directement le référentiel s'il n'est pas nécessaire de manipuler les données. Par conséquent, une couche de service n'a pas besoin d'être impliquée
2. Une fois que tout travail doit être effectué sur les données (logique métier), vous devez le faire dans la couche service et le contrôleur effectuera un appel simple à la couche service à la demande
.
3. Une fois qu'un service a défini sa logique métier, il utilisera le référentiel si nécessaire (si les données doivent être conservées).
4. Idéalement, les modèles doivent rester maigres et idéalement, ils ne sont rien d’autre que des DTO
5. La validation des données sera effectuée dans les modèles (en utilisant les attributs de validation MonoRail). J'apprécie que personne n'aime polluer leurs modèles avec beaucoup d'attributs, mais c'est une discussion différente. J'aime les avantages des attributs de validation de MonoRail pour la validation automatique de jQuery dans l'interface utilisateur.

J'essaie de transformer tout mon code en principe de responsabilité unique, et donc de mettre de l'ordre dans mes pratiques de codage.

Merci

Answer 1

Premièrement, aucun ensemble de règles ne peut fonctionner dans toutes les situations. La manière dont vous modélisez votre application dépend du type et de la complexité du projet. Cela dit, voici quelques idées:

1. Rien de mal à appeler le référentiel à partir d'un contrôleur. Assurez-vous simplement que le contrôleur ne contient pas de logique métier.
2. Le service s’occupe de (certaines) logiques d’entreprise et utilise d’autres services pour le faire. Le référentiel est un type de service, il n’ya rien de mal à l’appeler depuis un service.
3. Le modèle devrait contenir une logique métier. En fait, vous devez toujours essayer de l'insérer d'abord dans le modèle. Si vous avez besoin de données externes pour exécuter cette logique métier (à partir d'un autre modèle ou du référentiel), vous devez créer un service.
4. Rien de mal à la validation dans les modèles. Utiliser ou non des attributs est une question de goût (si vous l’aimez, c’est bon). Déplacez la validation en dehors du modèle si elle devient trop complexe (créez un ensemble de règles externe).

Plus important encore, faites ce qui vous semble bien (c'est généralement la bonne réponse).

Answer 2

Cette vidéo donne d'excellents résultats comprendre comment organiser votre solution asp.net MVC et résoudre le problème de la séparation des problèmes, ainsi que de meilleures capacités de test. Espérons que cela aidera également quelqu'un d'autre. J'ai appris de bonnes choses à partir de ça.

Answer 3

Ian Cooper vient d'écrire un article sur un blog intitulé Le contrôleur de graisse sur ce sujet seulement.