Si un des modèles de la couche de service d'affichage de retour pour une application MVC?

Question

Supposons que vous avez un projet ASP.NET MVC et utilisez une couche de service, comme dans ce tutoriel sur le contact gestionnaire du site asp.net: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely- couplé -cs

Si vous avez viewmodels votre point de vue, est la couche de service l'endroit approprié pour fournir à chaque viewmodel? Par exemple, dans l'exemple de code de la couche de service il existe une méthode

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

Si au contraire vous vouliez un IEnumerable, devrait aller dans la couche de service, ou est-il un autre endroit qui est l'endroit « correct »?

Peut-être plus appropriée, si vous avez un viewmodel pour chaque vue associée à ContactController, devrait ContactManagerService avoir une méthode distincte pour retourner chaque viewmodel? Si la couche de service n'est pas l'endroit approprié où les objets doivent viewmodel être initialisés pour une utilisation par le contrôleur?

Answer 1

En général, non.

Voir les modèles sont destinés à fournir des informations et de points de vue et devrait être spécifique à l'application, par opposition au domaine général. Les contrôleurs doivent orchestrer l'interaction avec les référentiels, les services (je fais quelques hypothèses de la définition du service ici), etc et gérer la construction et la validation des modèles de vue, et contiennent également la logique de détermination des vues à rendre.

En fuite des modèles en vue d'un « service » couche, vous brouillent vos couches et maintenant application possible et la présentation mixte spécifique avec ce qui devrait cibléeLesfondsbénéficiantd'unestratégie des responsabilités au niveau du domaine.

Answer 2

Non, je ne pense pas. Les services devraient tenir compte que du domaine du problème, et non le point de vue qui rend les résultats. Les valeurs de retour doivent être exprimées en termes d'objets de domaine, et non vues.

Answer 3

Selon l'approche traditionnelle ou d'une théorie sage, ViewModel devrait faire partie de la couche d'interface utilisateur. le nom dit du moins.

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

Quelqu'un à la carte Modèles Entité / DB avec ViewModels (DTO mentionné à la fin). Si cela se fait dans [A] la couche d'interface utilisateur (par le contrôleur), ou [B] la couche de service?

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

Encore une fois, allons avec l'option A, mettre ViewModel dans la couche d'interface utilisateur (et le modèle d'entité dans la couche de service).

Si la couche de service doit mapper ViewModel, puis la couche de service ont besoin d'accéder ViewModel dans la couche d'interface utilisateur. Quelle bibliothèque / projet? Le viewmodel devrait être dans un projet distinct dans la couche d'interface utilisateur, et ce projet doit être référencé par couche de service. Si le ViewModel est pas dans un projet distinct, alors il est fait référence circulaire, donc pas aller. Il semble maladroit d'avoir accès à la couche de service couche d'interface utilisateur mais nous pourrions y faire face.

Mais s'il y a une autre application de l'interface utilisateur en utilisant ce service? Et s'il y a une application mobile? Quelle différence ViewModel peut être? Si le service accéder à la même vue projet modèle? Est-ce que tous les projets de l'interface utilisateur accéder au même projet ViewModel ou ils ont leur propre?

Après ces considérations, ma réponse serait de mettre le projet viewmodel dans la couche de service. Chaque couche d'interface utilisateur doit accéder à la couche de service de toute façon! Et il pourrait y avoir beaucoup de ViewModels semblables qu'ils pouvaient tous utiliser (d'où la cartographie devient plus facile pour la couche de service). Mappings se font par LINQ ces jours-ci, ce qui est un autre avantage.

Enfin, il y a cette discussion au sujet DTO. Et aussi sur l'annotation de données dans ViewModels. ViewModels avec annotations de données (Microsoft.Web.Mvc.DataAnnotations.dll) ne peuvent pas résider dans la couche de service au lieu qu'ils se trouvent dans la couche d'interface utilisateur (mais ComponentModel.DataAnnotations.dll peuvent résider dans la couche de service). Si tous les projets sont dans une solution (.sln), il n'a pas d'importance couche que vous le mettez. Dans les applications d'entreprise, chaque couche aura sa propre solution.

DTO est en fait un ViewModel parce que la plupart du temps, il y aura un sur une correspondance entre les deux (dire avec AutoMapper). Encore une fois DTO a encore 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 (si nous utilisons Microsoft.Web.Mvc.DataAnnotations.dll) est juste de copier les données de DTO, avec un certain « comportement » / attributs ajoutés.

[Maintenant, cette discussion est sur le point de prendre une tournure intéressante à lire ...: I]

Et ne pense pas que les attributs de données annotation ne sont que pour l'interface utilisateur. Si vous limitez la validation à l'aide System.ComponentModel.DataAnnotations.dll puis la même ViewModel peut également être utilisé pour la fin de l'avant et d'arrière-plan validation (éliminant ainsi UI-résidence-ViewModel-copy-of-DTO). De plus les attributs peuvent également être utilisés dans les modèles d'entité. Par exemple: en utilisant .tt, les modèles de données Entity Framework peuvent être générées automatiquement à la validation des attributs de faire quelques DB comme longueur max validation avant de l'envoyer à l'arrière. Un autre avantage est que si des changements de validation de back-end dans DB puis .tt (détails DB et lit créer l'attribut pour la classe d'entité) utilisera automatiquement cela. Cela peut forcer les tests unitaires de validation de l'interface utilisateur à l'échec aussi bien, ce qui est un gros plus (afin que nous puissions corriger et d'informer tous les consommateurs UIS / au lieu d'oublier accidentellement et à défaut). Oui, la discussion se dirige vers une bonne conception-cadre. Comme vous pouvez le voir est tous liés. Validation sage niveau, stratégie de test unitaire, la stratégie de mise en cache, etc

Bien que pas directement lié à la question. 'ViewModel façade' mentionné dans ce doit regarder canal 9 lien est également la peine d'explorer. Il commence exactement à 11 minutes 49 secondes dans la vidéo. Parce que ce serait la prochaine étape / pensée une fois que votre question actuelle ci-dessus est réglé: «Comment organiser ViewModels?

Aussi dans votre exemple « _repository.ListContacts () » est un retour ViewModel du référentiel. Ce n'est pas une façon mature. Référentiels devraient fournir des modèles d'entités ou de modèles DB. Cela est converti en voir les modèles et il est ce modèle de vue qui est renvoyée par la couche de service.

Answer 4

Je suppose que cela dépend de ce que vous considérez les « services » d'être. Je ne l'ai jamais vraiment aimé le terme Service dans le cadre d'une seule classe; il est incroyablement vague et ne vous dit pas grand-chose sur le but réel de la classe.

Si la « couche de service » est une couche physique, comme un service Web, puis absolument pas; services dans un contexte SOA devraient exposer les opérations de domaine / d'affaires, pas des données et non pas la logique de présentation. Mais si Service est simplement utilisé comme un concept abstrait pour un autre niveau d'encapsulation, je ne vois pas de problème avec l'utilisation comme vous le desribe.

Il suffit de ne pas mélanger les concepts. Si vos offres de services avec des modèles de vue, il doit être service de présentation et être en couches sur le dessus de la réelle Modèle, jamais toucher directement la base de données ou de toute logique commerciale.

Answer 5

est venu un peu d'un « ça dépend » où je travaille - nous avons eu en général un automate consommateur un service (s) - puis la combinaison de retour DTO en « ViewModel » qui serait alors être transmis au client - soit par conséquent JSON, ou lié dans le modèle de rasoir.

La chose est, environ 80% du temps, - la mise en correspondance de DTO à ViewModel est 1-1. Nous commençons à aller vers « Au besoin, juste consommer le DTO directement, mais quand le DTO et ce que nous avons besoin dans notre client / vue ne correspondent pas - nous créons un ViewModel et faire la correspondance entre les objets au besoin ».

Bien que je ne suis toujours pas convaincu que c'est la meilleure solution ou à droite - « ? Nous contentons-nous ajoutons X au DTO pour répondre aux besoins de la vue », car il finit par conduire à des discussions animées de