Modèle Fat / contrôleur mince vs couche de service

Question

J'ai été le développement d'applications d'entreprise pour de nombreuses années à l'aide .Net Mes applications ont généralement un modèle de domaine contenant des entités de la cartographie pour SQL DB tables. J'utilise un modèle de Référentiel, de l'injection de Dépendances et d'une couche de service.

Récemment, nous avons commencé à travailler sur MVC 3 projets et nous avons eu un débat où mettre ce qui logique. Je suis venu à travers de minces Contrôleur / Modèle de GRAISSE architecture et je me demandais comment la couche de service rentre dans

Option 1 - Modèle des conférences à des services de

Le contrôleur est mince, les appels de méthodes sur les modèles. Les modèles de "savoir" comment charger vis à vis de la DB et de parler à des référentiels ou des services. E. g. customerModel a une Charge(id) de la méthode et des charges du client et de certains objets enfants comme GetContracts().

Option 2 - Contrôleur de pourparlers de services

Contrôleur de demande de Services pour récupérer les objets de modèle. La logique de chargement / rangement etc. Est dans la couche de service. Le modèle est une pure entité du modèle avec les données.

Pourquoi serait-option 1-être un meilleur choix, surtout quand nous parlons de l'entreprise applictions mon expérience me dit de préoccupations distinctes, garder les modèles ET les Contrôleurs aussi mince que possible et de services spécialisés, de faire de la logique Métier (imcl. La DB interaction)

Merci pour tous les conseils et les références à de bonnes ressources.

Answer 1

Tout cela dépend de l'intention et des exigences de votre application.

Cela dit, voici ma suggestion pour le "milieu de l'échelle" (pas un restaurant local, et non à Twitter/Facebook) des applications web.

1. Lean Domaine De La Modélisation

   Sec POCO style objets, de préférence ignorants de l'architecture MVC web de votre demande de séjour que faiblement couplé à partir de votre mise en œuvre possible.peut-être même la bibliothèque de la classe repack-mesure pour une utilisation dans une application externe, dire une API REST via un Service Web WCF).

   "Modèle" dans MVC avec le plus de précision signifie que le modèle le Contrôleur est conscient et donc le modèle prévu pour la Vue.

   Dans les plus petites (souvent Tutoriel) applications de l'entité modèles de votre "Application/Modèle de Domaine Calque" sont souvent les mêmes objets instanciés le contrôleur des navires hors de Vue.

   Dans les plus grands développeurs d'applications utilisent souvent les principes de l'architecture MVVM et commencer à utiliser la Vue des objets de Modèle. Les contrôleurs souvent appel intermédiaire des services qui travaillent avec les entités invisibles ci-dessous. Dans ce scénario, le M de MVC avec le plus de précision signifie que le Modèle de Vue.

2. Robuste Couche De Service

   Cela ne veut pas dire obèse logique, mais bien écrit seul but des services. Lors de l'encodage de votre logique métier dans les services à l'extérieur du modèle est un peu plus "de procédure" que c'est de la pure "programmation orientée objet", il aide beaucoup à couplage lâche, de test et de déploiement flexibles (ex. n-tier de déploiement).

   Dans ma pratique personnelle, je code les services les deux vers le bas sur la couche de données, que je considère comme mon modélisation du comportement des objets POCO (persistance de la mécanique, à faible niveau de validation, etc.), et de plus haut niveau de services (entreprise/fonction de flux de travail) plus près de la MVC de la mécanique.

3. Lean Contrôleurs

   - Je m'assurer que mon contrôleur est simplement l'entraîneur, qu'il n'est ni le jeu (services) ou les joueur (modèle d'entité ou de la vue modèle), mais simplement décide qui joue à ce poste et ce qu'est le jeu à faire. Mon contrôleurs de faire deux choses:

   1. Les services d'appel qui interagissent avec l'entité/les Modèles de domaine

   2. Préparer un Modèle d'Affichage pour l'Affichage approprié.

   Même authentifié/autorisé contrôleur actions sont réalisées à l'aide injecté services/attributs.

---

EDIT 1:

Gardez à l'esprit que cela ne signifie pas que votre Entité/Modèle de Domaine est ou doit être anémique. Orm, des référentiels et des usines, de la validation ou de l'état de la mécanique sont les bienvenus. Cela signifie seulement pour les applications d'ampleur modérée, le Modèle MVC représente le modèle conçu pour le contrôleur, à la main hors de votre Vue.

J'espère que ce point sera calme Fowler apôtres qui croient que l' anémique modèle de données pour être un anti-modèle. Dans le même temps, il ne refléter un peu plus de procédure de l'angle de la programmation orientée objet où il est le plus pur de comportement inclure dans le modèle des classes.

Il n'y a pas de "vérité ultime", mais à l'aide de ce modèle, vous le trouverez facile à construire, tester et déployer vos applications, tout en conservant beaucoup de ré-utilisabilité et l'évolutivité.

---

EDIT 2:

Cela dit, même pour des applications de taille modeste, en plus de la création de l'architecture (qu'un mot nerds?) un système est beaucoup trop commun. Par exemple, l'enchaînement d'un ORM avec un modèle de référentiel, puis des services de rédaction d'utiliser le référentiel... tout cela est bon pour la séparation des préoccupations et tels, mais si votre projet ne nécessite pas (et n'est pas très probable à bientôt besoin de ces choses, de ne pas construire. Il n'y a rien de mal à sauter le référentiel tous ensemble, à l'écriture fine business services (ex. classes de requêtes) à l'encontre d'un ORM, ou même d'avoir votre contrôleur de parler directement à elle. Tout dépend de l'échelle.

---

EDIT 3:

Je voulais noter que cette explication et conseils pour le contexte de serveur-côté architecture MVC comme ASP.Net, pas pour clent côté de cadres comme knock-out ou de la colonne vertébrale.

Answer 2

Vous avez besoin de savoir un peu plus sur MVC avant d'aller de l'avant et de discuter de l'endroit où mettre le tout. Eh bien, si vous voulez suivre la tendance. Sinon, vous pouvez arrêter de lire maintenant.

Le motif est très vaguement définis. Il n'y a rien qui dit comment le contrôleur, la vue ou le modèle devrait ressembler, ou la façon dont elles doivent être structurées. Le modèle indique simplement que vous devez séparer les pièces et comment ils interagissent les uns avec les autres. Voyons donc un peu plus sur ce qu'ils sont (mon interprétation).

MVC

Modèle Le modèle peut être n'importe quoi. Il peut être un service web, vos dépôts, vos classes de service ou tout simplement vos modèles de domaine. Le Modèle sont tout ce qui sont utilisés pour obtenir les informations dont vous avez besoin. Considérer le "Modèle" comme une couche au lieu de juste un seul objet.

Contrôleur Le contrôleur est une colle. Il prend les informations du Modèle et de l'adapter à la vue, et vice-versa.

Vue La vue doit seulement rendre ce que l'utilisateur voit.

Notez que vous ne devez pas confondre le Modèle avec les Modèles de Vue. Microsoft devrait vraiment avoir nommé le "Modèle" dossier "Viewmodel" puisque c'est ce qu'ils sont. Je ne voudrais pas utiliser les informations du "Modèle" directement dans le point de vue. À défaut de le faire signifie que vous devez changer de Modèle si l'Affichage est modifié et l'autre manière autour.

La réponse

Le modèle n'est pas un modèle de vue, mais une couche. Tout dans le modèle est utilisé pour récupérer les informations nécessaires pour la vue. Le contrôleur prend que de l'information et de la place dans un unique modèle de vue.

Une seule action de contrôleur peut utiliser un ou plusieurs appels au "Modèle" pour être en mesure de rassembler l'information requise par la vue.

Cela signifie que votre deuxième option est la plus correcte quand, si vous voulez obtenir une application qui est facile à maintenir et à étendre.

Notez qu'une couche de service peut ne pas être nécessaire. Vous pouvez appeler le OU/M directement depuis les commandes. Mais si vous trouvez vous-même la duplication de code ou de l'obtention de la graisse contrôleurs, il suffit de déplacer la logique d'une couche de service. Rien de mais le contrôleur sera affectée par ce changement, puisque vous êtes en utilisant la bonne afficher les modèles.

Answer 3

Option 1: Vous pourriez penser à ce modèle == service. Le modèle EST également la couche métier.

L'option 2 est un anti-modèle de modèle de domaine anémique. http://en.wikipedia.org/wiki/Anemic_domain_model

Answer 4

L'option 2 correspond à ce que l'on appelle l'architecture Fat Stupid Ugly Controllers ( référence à l'auteur de cette expression ). Cette solution va généralement à l’encontre de l’esprit MVC dans la mesure où elle rompt la séparation des préoccupations.