DTO = ViewModel?

J'utilise NHibernate pour conserver mes objets de domaine. Pour simplifier les choses, j'utilise un projet ASP.NET MVC à la fois comme couche de présentation et comme couche de service.

Je souhaite renvoyer mes objets de domaine en XML à partir de mes classes de contrôleur. Après avoir lu quelques articles ici sur Stack Overflow, je suppose que les DTO sont la voie à suivre. Cependant, je suis également tombé sur des articles parlant du ViewModel.

Ma question: les objets de transfert de données et les ViewModels sont-ils la même chose? Ou un ViewModel est-il une sorte de sous-motif d'un DTO?

La définition canonique d'un DTO est la forme de données d'un objet sans aucun comportement.

ViewModels est le modèle de la vue. Les ViewModels sont généralement des données complètes ou partielles d'un ou plusieurs objets (ou DTO) plus tous les membres supplémentaires spécifiques au comportement de la vue (méthodes qui peuvent être exécutées par la vue, propriétés pour indiquer comment basculer les éléments de vue, etc.). Vous pouvez regarder le modèle de vue comme toutes les données d'une vue plus les comportements. ViewModels peut ou non mapper un à un sur des objets métier ou des DTO.

En passant, les projections NHibernate sont utiles si un certain modèle de vue a besoin d'un sous-ensemble des données d'un objet persistant.

ViewModel dans ASP.NET MVC est le même que le DTO, mais ViewModel dans le modèle MVVM est différent du DTO car ViewModel dans MVVM a des comportements mais pas DTO.

DTO! = ViewModel

Dans le modèle MVVM , le ViewModel est utilisé pour isoler le modèle de la vue. Pour représenter le modèle, vous pouvez utiliser des classes DTO simples , qui sont à nouveau mappées à une base de données via, par exemple, NHibernate. Mais je n'ai jamais vu une classe ViewModel qui est modélisée comme un DTO. Les classes ViewModel ont pour la plupart un comportement, ce que les DTO n'ont pas.

DTO - Les objets de transfert de données sont exactement comme il le dit, des conteneurs pour le transfert de données. Ils n'ont aucun comportement mais simplement un groupe de setters et de getters. Certaines personnes les rendent immuables et en créent simplement de nouvelles au besoin plutôt que de mettre à jour celles existantes. Ils doivent être sérialisables pour permettre le transfert sur le fil.

En général, les DTO sont utilisés pour expédier des données d'une couche à une autre à travers les limites du processus, car les appels à un service distant peuvent être coûteux, de sorte que toutes les données requises sont poussées dans un DTO et transférées au client en un seul morceau (à gros grains).

Cependant, certaines personnes utilisent la notion de DTO liés à l'écran (rien à voir avec le franchissement des limites de processus). Encore une fois, ceux-ci sont remplis avec les données requises (généralement les données requises pour un écran particulier et peuvent être une agrégation de données provenant de diverses sources) et envoyées au client.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

Dans des cas simples, comme cela a déjà été indiqué, ce DTO peut être utilisé pour la liaison à la vue, mais dans les cas plus complexes, il nécessiterait la création d'un ViewModel et le déchargement des données de DTO vers ViewModel, ce qui est évidemment plus de travail (lors de l'application du modèle MVVM) .

Encore une fois, comme déjà indiqué DTO! = ViewModel

et

DTO et ViewModel ont des objectifs différents dans la vie

Tout d'abord, la différence majeure est que ViewModel peut avoir un comportement ou des méthodes que DTO ne doit pas !!!

Deuxièmement, l'utilisation de DTO comme ViewModel dans ASP.NET MVC rend votre application étroitement couplée à DTO et c'est exactement le but opposé de l'utilisation de DTO. Si vous le faites, quelle est la différence en utilisant votre modèle de domaine ou DTO, plus de complexité pour obtenir un anti-pattern?

ViewModel dans ASP.NET peut également utiliser DataAnnotations pour la validation.

Le même DTO peut avoir différents mappages ViewModels, et un ViewModel peut être composé de différents DTO (toujours avec un mappage d'objets et non une composition). parce que je pense que c'est encore pire si vous avez un ViewModel qui contient un DTO, nous aurons le même problème.

À partir de votre couche de présentation, pensez à DTO comme à un contrat, vous recevrez un objet que vous devez considérer comme étranger à votre application et n'avez aucun contrôle sur celui-ci (même si vous avez ex le service, les couches dto et présentation sont vôtres).

Enfin, si vous effectuez cette séparation nette, les développeurs peuvent travailler ensemble facilement. La personne qui conçoit des ViewModels, des Vues et des Controllers n'a pas à se soucier de la couche de service ou de l'implémentation DTO car elle fera le mappage lorsque les autres développeurs auront terminé leur implémentation ... Il peut même utiliser l'outil de simulation ou la simulation manuelle pour remplir la couche de présentation avec des données à tester.

Pour certaines vues simples, j'utiliserai mon DTO comme modèles, mais à mesure que les vues deviennent plus complexes, je créerai des ViewModels.

Pour moi, c'est un équilibre entre rapidité (en utilisant DTO, puisque je les ai déjà) et flexibilité (créer des ViewModels signifie plus de séparation des préoccupations).

Si vous utilisez DTO comme ViewModel, cela signifie que vous faites une forte dépendance à DTO en raison d'une raison quelconque pour laquelle vous modifiez DTO, cela pourrait avoir un impact sur ViewModel.

Mieux vaut utiliser DTO et convertir en viewmodel.

Nous pouvons utiliser DTOidentique à la classe Model et nous pouvons utiliser viewmodel lorsque nous devons afficher / utiliser plusieurs données / propriétés de modèles dans une seule vue. Exemple: je crée d'abord un modèle en utilisant la base de données du framework d'entité. Donc, maintenant, tous les modèles sont générés en fonction de la base de données. et maintenant nous avons besoin d'annotation de données, pour ces annotations de données, nous pouvons créer un nom de dossier DTO, Dans ce dossier DTO, nous pouvons conserver tous les modèles exacts qui génèrent déjà et ajoutent une annotation de données au-dessus de la propriété. Ensuite, nous pouvons utiliser n'importe quelle opération (utiliser le contrôleur, les vues) en utilisant ces classes DTO. Et lorsque nous avons besoin d'une vue complexe, je veux dire que lorsque nous avons besoin de plusieurs données de classes dans une seule vue, nous pouvons utiliser viewmodel. Pour viewmodel, nous pouvons créer un nom de dossier viewmodel, puis créer une classe personnalisée et conserver la propriété dont nous avons besoin. J'ai essayé de me dégager. Toute suggestion très appréciée.