Couches de service et référentiels

Question

J'ai été en utilisant MVC cadres pendant un court instant et j'aime vraiment la façon dont les préoccupations sont séparés. J'ai eu une mauvaise habitude de laisser les contrôleurs de faire un peu de travail. Donc, je suis vraiment à la recherche de quelques conseils.

Quand j'ai commencé à utiliser MVC, j'ai très souvent eu le contrôleur de faire la manipulation sur les modèles d'après la base de données de travail a été accompli. Je savais que c'était une mauvaise chose tellement ému que le travail dans les modèles. Cependant, je ne suis pas heureux avec ce que je veux de mes modèles très apprendre.

J'ai fait un peu de lecture et je vois que les gens gardent leurs contrôleurs et des modèles maigre par avoir une couche de service, dont j'aime bien le look de.

J'essaie juste de comprendre comment une couche de service et de dépôt devrait tous travailler 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 le référentiel directement si aucune manipulation doit être effectuée sur les données et en tant que telle une couche de service n'a pas besoin de s'impliquer
2. Une fois que tout le travail qui doit être fait pour les données (logique), alors cela devrait être fait dans la couche de service et le contrôleur va faire un simple appel à la couche de service en tant que de besoin
3. Une fois le service terminé, il est logique d'entreprise, il sera alors utiliser le référentiel nécessaire (si les données doivent être conservées).
4. Les modèles devraient idéalement être conservés maigre, idéalement agissements comme rien de plus que des Otd
5. La Validation des données se fera dans les modèles (à l'aide de MonoRail attributs de validation). J'apprécie même pas aime polluer leurs modèles avec beaucoup d'attributs, mais c'est une autre discussion. J'aime le bénéfice de MonoRail de validation des attributs pour le système automatique de jQuery de validation dans l'INTERFACE utilisateur.

Je suis en train de tourner tout mon code autour du principe de responsabilité unique, donc en essayant de trier mes pratiques de codage.

Merci

Answer 1

Tout d'abord, il n'y a pas un ensemble de règles qui va fonctionner dans toutes les situations. Comment le modèle de votre application dépend beaucoup 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. Juste assurez-vous que le contrôleur ne contient pas de logique métier.
2. Le service prend soin de (certains) logique d'entreprise et utilise d'autres services à le faire. Le référentiel est un type de service, il n'y a rien de mal à l'appeler à partir d'un service.
3. Le modèle doit contenir une logique d'entreprise, en fait, vous devriez toujours essayer de le mettre dans le premier modèle. Si vous avez besoin de données externes pour effectuer une logique d'entreprise (à partir d'un autre modèle ou à partir du référentiel de), vous devez alors créer un service.
4. Rien de mal avec la validation des modèles. À l'aide d'attributs ou pas est une question de goût (si vous l'aimez alors c'est bon). Déplacer la validation à l'extérieur du modèle, si elle devient trop complexe (créer un ensemble externes de règles).

Le plus important, de faire ce qui se sent le droit (c'est généralement la bonne réponse).

Answer 2

Cette vidéo explique comment organiser votre solution asp.net MVC et comment séparer les problèmes, tout en améliorant la testabilité. 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 son blog, The Fat Controller, sur ce sujet.