DTO = ViewModel?

103

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?

autonomatt
la source
9
Je pense qu'il est pertinent de mentionner que les ViewModels dans ASP.NET MVC ne sont pas équivalents à 100% aux ViewModels dans WPF (MVVM), car la plupart des réponses mentionnent MVVM et que vous travaillez avec ASP.NET MVC.
Matthijs Wessels

Réponses:

105

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.

Daniel Auger
la source
Pouvez-vous expliquer ceci: "DTO est la forme de données d'un objet sans aucun comportement"?
roozbeh S
2
Signification ... la classe DTO ne contient généralement que des propriétés et ne contient aucune méthode avec une logique métier, etc.
Daniel Auger
71

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.

Rayon
la source
4
C'est une bonne réponse; bien que peu de détails.
Phil
5
Pourquoi le ViewModel dans asp.net mvc devrait-il être identique à un DTO? Ça n'a aucun sens. Un ViewModel peut avoir un comportement non DTO. Cela ne dépend pas de mvc.
Elisabeth
8
+1 pour différencier ASP.NET MVC ViewModel et MVVM ViewModel.
Ronald
5
@Elisa - La réponse à votre question plutôt ancienne est que dans ASP.NET MVC, la vue invoque des actions sur le contrôleur (pas un ViewModel) afin de modifier le modèle et la vue de manière sans état. Pour cette raison, un DTO en forme de vue est essentiellement le même que le ViewModel. Cependant, dans les systèmes plus grands avec une autre limite de sérialisation, un DTO peut être bénéfique s'il est séparé d'un ViewModel spécialement conçu pour la vue.
dansan
27

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.

stiank81
la source
2
donc les DTO peuvent simplement être des structures (ou est-ce une classe qui devrait imiter les capacités d'une structure)?
Max Alexander
20

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

David
la source
13

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.

riadh gomri
la source
1
Je viens d'installer VS 2012 et y ai regardé MVC 4 Single Page Application. Dans l'exemple de projet, les DTO sont utilisés comme paramètres pour les méthodes de contrôleur (ou actions) dans WebApi. En d'autres termes, JSON est publié dans ces méthodes et avec une certaine magie MVC, les données sont automatiquement converties en DTO avant d'être transmises aux méthodes. Pensez-vous qu'il est erroné d'utiliser des DTO dans ce cas. ViewModels doit-il être utilisé avec une API Web? Je demande à mieux comprendre, car je ne connais pas encore très bien ces concepts.
Jean-François Beauchamp
Salut Jean-François Beauchamp :) ASP.NET MVC peut analyser les landaus url dans un objet, par exemple: supposons que je dispose de ce mappage vers une méthode Index ajax / index / {jobID} / {ResultsToSkip} / {ResultsToSend} "au lieu d'avoir dans le controlle Index (int jobID, int ResultsToSkip, int ResultsToSend) J'aurai Index (request) (la requête est un objet qui encapsule 3 champs jobID ...) Alors maintenant, au lieu de paramètres, vous parlez à votre application avec des objets qui encapsulent DATA, donc oui, nous pouvons dire requestDTO. Par exemple, vous devez ajouter un autre champ, vous ne modifiez que le DTO, pas les méthodes d'interface de l'API.
riadh gomri
9

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).

sgwill
la source
2
Belle réponse pragmatique.
Simon Tewsi
0

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.

Lalit Khanna
la source
-1

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.

Md. Saddam Hossain
la source