Modèle Fat / contrôleur mince vs couche de service
Je développe des applications d'entreprise depuis de nombreuses années en utilisant .Net Mes applications ont généralement un modèle de domaine contenant des entités mappées aux tables SQL DB. J'utilise un modèle de référentiel, une injection de dépendance et une couche de service.
Récemment, nous avons commencé à travailler sur des projets MVC 3 et nous avons eu un débat où mettre quelle logique. Je suis tombé sur une architecture de contrôleur/modèle FAT mince et je me demandais comment la couche de service s’intégrerait
Option 1 - Modèle de discussions avec les services
Le contrôleur est mince, appelle des méthodes sur les modèles. Les modèles "savent" comment se charger à partir de la base de données et parler aux référentiels ou aux services. Par exemple. customerModel a une méthode Load (id) et charge le client et certains objets enfants comme GetContracts ().
Option 2 - Le contrôleur parle aux services
Le contrôleur demande aux services de récupérer les objets du modèle. La logique de chargement/stockage, etc. est dans la couche service. Le modèle est un modèle d'entité pur avec des données uniquement.
Pourquoi l'option 1 serait-elle un meilleur choix, en particulier lorsque nous parlons d'applications d'entreprise, mon expérience me dit de séparer les préoccupations, de garder les modèles ET les contrôleurs aussi fins que possible et d'avoir des services spécialisés faisant la logique métier (imcl. L'interaction DB)
Merci pour tous les conseils et références aux bonnes ressources.
Tout cela dépend de l'intention et des exigences de votre application.
Cela dit, voici ma suggestion pour des applications Web "à échelle moyenne" (pas un restaurant local et pas Twitter/Facebook).
Modélisation de domaine allégée
Objets secs de style POCO, de préférence ignorants de l'architecture MVC de votre application Web pour rester aussi faiblement couplés que possible à votre implémentation particulière. Peut-être même que la bibliothèque de classes peut être remballée pour une utilisation dans une application externe, par exemple a REST API via un service Web WCF).
"Modèle" dans MVC signifie le plus précisément le modèle dont le contrôleur a connaissance et donc le modèle destiné au Voir .
Dans les applications plus petites (souvent didacticiel), les modèles d'entité de votre "couche de modèle d'application/domaine" sont souvent les mêmes objets instanciés que le contrôleur envoie à une vue.
Dans les applications plus grandes, les développeurs utilisent souvent les principes de l'architecture MVVM et commencent à utiliser des objets View Model distincts. Les contrôleurs appellent souvent des services de niveau intermédiaire qui fonctionnent avec les entités invisibles ci-dessous. Dans ce scénario, le M dans MVC signifie le plus précisément le modèle d'affichage.
Couche de service robuste
Cela ne signifie pas logique obèse , mais des services à but unique bien écrits. Bien que le codage de votre logique métier dans des services en dehors du modèle soit un peu plus "procédural" que pur "POO", il aide beaucoup à un couplage lâche, à des tests et à un déploiement flexible (ex. Déploiement à n niveaux).
Dans ma pratique personnelle, je code des services à la fois au niveau de la couche de données, que je considère comme ma modélisation comportementale des objets POCO (mécanique de la persistance, validation de bas niveau, etc.), et des services de niveau supérieur (fonction métier/workflow) de plus près la mécanique MVC.
Contrôleurs Lean
Je m'assure que mon contrôleur est simplement l'entraîneur , en ce qu'il n'est ni le jeu (services) ou le joueur (modèle d'entité ou modèle de vue), mais décide simplement qui joue quelle position et quel jeu faire. Mes contrôleurs font deux choses:
Services d'appel qui interagissent avec les modèles d'entité/de domaine
Préparez un modèle de vue pour la vue appropriée.
Même les actions de contrôleur authentifiées/autorisées sont effectuées via des services/attributs injectés.
MODIFIER 1:
Gardez à l'esprit que cela ne signifie pas que votre modèle d'entité/de domaine est ou doit être anémique. Les ORM, les référentiels et les usines, la validation ou la mécanique d'état sont les bienvenus. Cela signifie uniquement pour les applications d'échelle modérée, le modèle dans MVC représente le modèle destiné au contrôleur, à portée de main off à votre vue .
Espérons que ce point calmera les apôtres Fowler qui croient que le modèle de données anémiques est un anti-modèle . En même temps, il reflète un angle légèrement plus procédural que OOP où il est plus pur d'inclure un comportement dans les classes modélisées.
Il n'y a pas de "vérité ultime", mais en utilisant ce modèle, il vous sera facile de créer, tester et déployer vos applications - tout en conservant une grande réutilisabilité et évolutivité.
MODIFIER 2:
Cela dit, même pour des applications de taille modeste, la surarchitecture (qu'un nerds Word a constituée?) D'un système est beaucoup trop courante. Par exemple, envelopper un ORM avec un modèle de référentiel, puis écrire des services pour utiliser le référentiel ... tout cela est bon pour la séparation des préoccupations et autres, mais si votre projet ne nécessite pas (et n'est pas très susceptible de bientôt exiger) de telles choses, ne le construisez pas. Il n'y a rien de mal à ignorer le référentiel tous ensemble, à écrire des services métier légers (par exemple, des classes de requête) contre un ORM, ou même à demander à votre contrôleur de lui parler directement. Tout dépend de l'échelle.
MODIFIER 3:
Je voulais noter que cette explication et ces conseils concernent le contexte de l'architecture MVC côté serveur comme ASP.Net, pas les cadres côté clent comme Knockout ou Backbone.
Vous devez en savoir plus sur MVC avant d'aller de l'avant et de discuter où mettre tout. Eh bien, si vous voulez suivre le modèle. Sinon, vous pouvez arrêter de lire maintenant.
Le motif est défini de façon très lâche. Rien ne dit à quoi le contrôleur, la vue ou le modèle doivent ressembler ni comment ils doivent être structurés. Le modèle indique simplement que vous devez séparer les parties et comment elles doivent interagir les unes avec les autres. Voyons donc un peu plus ce qu'ils sont (mon interprétation).
MVC
Modèle Le modèle peut être n'importe quoi. Il peut s'agir d'un webservice, de vos référentiels, de vos classes de service ou simplement de vos modèles de domaine. Le modèle est tout ce qui est utilisé pour obtenir les informations dont vous avez besoin. Considérez le "modèle" comme un calque au lieu d'un simple objet.
Controller Le contrôleur est une colle. Il prend les informations du modèle et les adapte à la vue et vice versa.
View La vue ne doit rendre que ce que l'utilisateur voit.
Notez que vous ne devez pas confondre le modèle avec les modèles de vue. Microsoft aurait vraiment dû nommer le dossier "Model" "ViewModels" car c'est ce qu'ils sont. Je n'utiliserais pas les informations du "modèle" directement dans les vues. Si vous ne le faites pas, vous devrez changer le modèle si la vue est modifiée et inversement.
La réponse
Le modèle n'est pas un modèle de vue mais un calque. Tout dans le modèle est utilisé pour récupérer les informations nécessaires à la vue. Le contrôleur prend ces informations et les place dans un modèle à vue unique.
Une seule action du contrôleur peut utiliser un ou plusieurs appels au "modèle" pour pouvoir assembler les informations nécessaires à la vue.
Cela signifie que votre deuxième option est la plus correcte lorsque vous souhaitez obtenir une application facile à maintenir et à étendre.
Notez qu'une couche de service peut ne pas être nécessaire. Vous pouvez appeler l'OR/M directement à partir des contrôleurs. Mais si vous vous retrouvez à dupliquer du code ou à obtenir de gros contrôleurs, déplacez simplement la logique vers une couche de service. Rien que le contrôleur ne sera affecté par ce changement puisque vous utilisez des modèles de vue appropriés.
Option 1: Vous pourriez penser que le modèle == service. Modélisez également IS 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
L'option 2 est ce qui est décrit comme l'architecture Fat Stupid Ugly Controllers ( Référence à l'auteur de cette expression ). Cette solution est généralement contraire à l'esprit MVC car elle rompt la séparation des préoccupations.