Une couche de service doit-elle renvoyer des modèles de vue pour une application MVC?

Question

Disons que vous avez un ASP.NET projet MVC et sont à l'aide d'une couche de service, comme c'est le gestionnaire de contacts tutoriel sur la asp.net site: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely-coupled-cs

Si vous avez des viewmodels vos points de vue, est la couche de service de l'endroit le plus approprié pour fournir à chaque viewmodel? Par exemple, dans la couche de service de l'exemple de code il y a une méthode

    public IEnumerable<Contact> ListContacts()
    {
        return _repository.ListContacts();
    }

En revanche, si vous voulais un IEnumerable, faut-il aller dans la couche de service, ou est-il quelque part d'autre qui est le "bon" endroit?

Plus exactement peut-être, si vous avez un viewmodel pour chaque vue associée à ContactController, devrait ContactManagerService ont une méthode distincte pour chaque viewmodel? Si la couche de service n'est pas à la bonne place, où devrait-viewmodel objets être initialisé pour une utilisation par le contrôleur?

Answer 1

Généralement, aucun.

Afficher les modèles sont destinés à fournir des renseignements et de points de vue et devraient être spécifiques à l'application, par opposition au domaine général. Les contrôleurs doivent orchestrer l'interaction avec les référentiels, les services (je suis en faisant certaines hypothèses de la définition de service, cliquez ici), etc et de gérer la construction et la validation de modèles de vue, et contiennent également de la logique de la détermination de points de vue pour le rendu.

Par des fuites de vue des modèles dans un "service" de la couche, vous êtes le flou de vos couches et maintenant avoir l'application et la présentation mixte spécifique dans avec ce qui aurait porté avec un domaine de niveau de responsabilités.

Answer 2

Non je ne pense pas. Les services doivent se préoccuper uniquement du domaine problématique, pas de la vue qui génère des résultats. Les valeurs renvoyées doivent être exprimées en termes d'objets de domaine et non de vues.

Answer 3

Selon l'approche traditionnelle ou de la théorie sage, ViewModel devrait être une partie de la couche d'interface Utilisateur. Au moins le nom le dit.

Mais lorsque vous descendez à la mise en œuvre de soi-même, avec l'Entity Framework MVC, Dépôt, etc, alors vous réalisez quelque chose d'autre.

Quelqu'un a à la carte des Modèles d'Entité avec Viewmodel(DTO mentionné à la fin). Cela doit être fait dans A) la couche d'INTERFACE utilisateur (par le Contrôleur), ou B) de la couche de Service?

Je pars avec l'Option B. l'Option A est un pas à cause du simple fait que plusieurs des modèles d'entité se combinent pour former un ViewModel. Nous ne pouvons pas transmettre les données à la couche d'INTERFACE utilisateur, alors que dans l'option B, le service peut jouer avec les données et les transmettre que le nécessaire/minimum de la couche d'INTERFACE utilisateur après la cartographie (pour le ViewModel).

Encore une fois, nous supposons que nous mettre ViewModel dans la couche d'INTERFACE utilisateur(et le modèle d'entité dans la couche de Service).

Si la couche de Service des besoins à la carte pour le ViewModel, puis la couche de Service nécessaire à l'accès ViewModel dans la couche d'INTERFACE utilisateur. Bibliothèque/projet? Ce Dernier devrait être dans un autre projet dans la couche d'INTERFACE utilisateur, et ce projet doit être référencé par la Couche de Service. Si ce Dernier n'est pas dans un projet distinct, alors il y a de la circulaire de référence, donc pas aller. Il a l'air gêné d'avoir de la couche de Service d'accéder couche d'INTERFACE utilisateur, mais encore nous avons pu faire face avec elle.

Mais que faire si il y a une autre INTERFACE utilisateur de l'app à l'aide de ce service? Que faire si il n'y est une application mobile? Quelle différence peut le ViewModel être? Si le Service d'accès le même point de vue, le modèle de projet? Va toute l'INTERFACE utilisateur de projets d'accéder à la même ViewModel projet ou ils ont leur propre?

Après ces considérations, ma réponse serait de mettre le Viewmodel de projet dans la Couche de Service. Chaque couche d'INTERFACE utilisateur a accès à la couche de Service de toute façon! Et il pourrait y avoir beaucoup de semblables Viewmodel que tous puissent utiliser (d'où la cartographie devient plus facile pour la couche de service). Les mappages sont effectuées grâce à linq ces jours, ce qui est un autre atout.

Enfin il y a cette discussion sur la DTO. Et aussi sur l'annotation de données dans le Viewmodel. Viewmodel avec annotations de données ne peuvent pas résider dans la couche de service. Afin de lire DTO comme ViewModel, car pour la plupart il y en aura un sur la mise en correspondance entre les deux(avec AutoMapper). Nouveau DTO a encore de la logique nécessaire pour l'INTERFACE utilisateur(ou plusieurs applications) et réside dans la Couche de Service. Et la couche d'INTERFACE utilisateur ViewModel est juste pour copier les données à partir de DTO, avec quelques "comportement" a été ajoutée.

Bien que n'étant pas directement liées à la question. 'ViewModel Façade, mentionnés dans le présent doit regarder canal 9 lien est également intéressant à étudier. Il commence exactement à 11 minutes 49 secondes dans la vidéo.

Également dans votre exemple "_repository.ListContacts()" est de retour d'un viewmodel de référentiel. Ce n'est pas une manière mature. Les référentiels doivent fournir des modèles d'entité ou db modèles. Ce est converti les modèles de vue et c'est ce modèle de vue qui est retourné par le service de la couche.

Answer 4

C'est un peu un "ça dépend", où je travaille - nous ont eu en général un contrôleur de consommer service(s) - puis de les combiner retourné DTO est dans un "ViewModel" qui serait ensuite passées au client, soit par l'intermédiaire de résultat JSON, ou lié dans le Modèle de Rasoir.

Chose est, environ 80% du temps - la cartographie de la DTO de ViewModel a été 1-1. Nous avons commencé à déplacer vers " Où nécessaire, il suffit de consommer de la DTO directement, mais quand la DTO et ce dont nous avons besoin dans nos client/vue ne correspondent pas - ensuite, nous créons un ViewModel et de faire le mapping entre les objets en tant que de besoin.

Bien que je ne suis toujours pas convaincu que c'est la meilleure ou la bonne solution, car elle met fin à aboutir à des discussions passionnées de " sommes-nous juste l'ajout de X à la DTO pour répondre aux besoins de la vue?'

Answer 5

Je suppose que cela dépend de ce que vous considérez comme les "services" de l'être. Je n'ai jamais vraiment aimé le terme de service dans le contexte d'une classe unique; c'est très vague et ne pas vous en dire beaucoup sur l'objet réel de la classe.

Si la "couche de service" est une couche physique, comme un service web, puis absolument pas; les services dans un contexte SOA doit exposer de domaine/les entreprises, pas les données et non pas logique de présentation. Mais si le service est tout simplement être utilisé comme un concept abstrait pour un autre niveau d'encapsulation, je ne vois pas de problème avec l'aide de la façon qui vous décrivent.

Il suffit de ne pas mélanger les concepts. Si votre service traite avec les modèles de vue, alors il devrait être un service de présentation et être en couches sur le dessus de la réelle Modèle, jamais directement en contact avec la base de données ou de toute logique commerciale.