it-swarm.com.de

DTO = ViewModel?

Ich verwende NHibernate, um meine Domänenobjekte zu persistieren ... Um einfach zu bleiben, verwende ich ein ASP.NET-MVC-Projekt sowohl als Präsentationsschicht als auch als Serviceebene.

Ich möchte meine Domänenobjekte in XML aus meinen Controller-Klassen zurückgeben. Nachdem ich hier einige Beiträge über Stack Overflow gelesen habe, sind DTOs der richtige Weg. Ich bin jedoch auch auf Posts gestoßen, die über ViewModel sprechen.

Meine Frage: Sind Datenübertragungsobjekte und ViewModels dasselbe? Oder ist ein ViewModel eine Art Submuster einer DTO?

90
autonomatt

Die kanonische Definition eines DTO ist die Datenform eines Objekts ohne Verhalten.

ViewModels sind das Modell der Ansicht. ViewModels sind in der Regel vollständige oder unvollständige Daten von einem oder mehreren Objekten (oder DTOs) sowie zusätzlichen Mitgliedern, die für das Verhalten der Ansicht spezifisch sind (Methoden, die von der Ansicht ausgeführt werden können, Eigenschaften, die angeben, wie Ansichtselemente umzuschalten usw.). Sie können das Ansichtsmodell als alle Daten für eine Ansicht plus Verhalten anzeigen. ViewModels kann Business-Objekten oder DTOs eins zu eins zuordnen.

Übrigens, NHibernate projections ist hilfreich, wenn ein bestimmtes Viewmodel eine Untermenge der Daten eines persistenten Objekts benötigt.

87
Daniel Auger

ViewModel in ASP.NET MVC-Verfahren ist das gleiche wie das DTO. ViewModel im MVVM-Muster unterscheidet sich jedoch von DTO, da ViewModel in MVVM Verhalten hat, DTO jedoch nicht.

60
Ray

DTO! = ViewModel

Im Muster MVVM wird das ViewModel verwendet, um das Modell von der Ansicht zu isolieren. Um das Modell darzustellen, können Sie einfache DTO - Klassen verwenden, die wiederum einer Datenbank durch z. NHibernate. Ich habe jedoch noch nie eine ViewModel-Klasse gesehen, die als DTO modelliert ist. ViewModel-Klassen haben meistens ein Verhalten, das DTOs nicht haben. 

28
stiank81

DTO - Data Transfer Objects sind genau wie es heißt, Container für die Datenübertragung. Sie haben kein Benehmen, sondern nur ein paar Setzer und Getter. Einige Leute machen sie unveränderlich und erstellen bei Bedarf einfach neue, anstatt vorhandene zu aktualisieren. Sie sollten serialisierbar sein, um die Übertragung über das Kabel zu ermöglichen.

Im Allgemeinen werden DTOs verwendet, um Daten über Prozessgrenzen hinweg von einer Ebene an eine andere zu senden, da Aufrufe an einen Remote-Service teuer sein können, sodass alle erforderlichen Daten in ein DTO verschoben und in einem einzigen Abschnitt (grobkörnig) an den Client übertragen werden.

Einige Leute verwenden jedoch die Vorstellung von screen-gebundenen DTOs (nichts mit dem Überschreiten von Prozessgrenzen). Diese werden wiederum mit den erforderlichen Daten gefüllt (in der Regel die für einen bestimmten Bildschirm erforderlichen Daten und könnten eine Zusammenfassung von Daten aus verschiedenen Quellen sein) und an den Client gesendet.

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

Wie bereits erwähnt, kann dieses DTO in einfachen Fällen für die Bindung an die Ansicht verwendet werden, in komplexeren Fällen müssten jedoch ein ViewModel erstellt und Daten von DTO nach ViewModel entladen werden, was offensichtlich mehr Arbeit erfordert (beim Anwenden des MVVM-Musters). .

Also nochmal wie schon gesagt DTO! = ViewModel

und

DTO und ViewModel haben unterschiedliche Lebensziele

18
David

Erstens besteht der Hauptunterschied darin, dass ViewModel ein Verhalten oder Methoden haben kann, die DTO nicht darf !!! 

Zweitens: Wenn Sie DTO als ViewModel in ASP.NET MVC verwenden, wird Ihre Anwendung eng an DTO gekoppelt. Dies ist genau der gegenteilige Zweck der Verwendung von DTO. Wenn Sie dies tun, was ist der Unterschied zwischen Ihrem Domänenmodell oder DTO und der Komplexität, um ein Anti-Pattern zu erhalten?

Auch ViewModel in ASP.NET kann DataAnnotations zur Validierung verwenden. 

Derselbe DTO kann unterschiedliche ViewModels-Zuordnungen haben, und One ViewModel kann aus verschiedenen DTOs zusammengesetzt werden (immer mit Objektzuordnung, nicht Komposition). Ich denke, es ist noch schlimmer, wenn Sie ein ViewModel haben, das ein DTO enthält. Wir werden das gleiche Problem haben.

Denken Sie in Ihrer Präsentationsebene über DTO als Vertrag nach. Sie erhalten ein Objekt, das Sie als fremd in Ihrer Anwendung betrachten müssen und keine Kontrolle darüber haben (auch wenn Sie bereits über die Service-, die Dto- und die Präsentationsschicht verfügen.) sind deine).

Wenn Sie diese saubere Trennung durchführen, können Entwickler auf einfache Weise zusammenarbeiten. Die Person, die ViewModels, Views und Controller entwirft, muss sich nicht um die Service-Schicht oder die DTO-Implementierung kümmern, da sie bei den anderen die Zuordnung übernimmt Entwickler schließen ihre Implementierung ab ... __ Er kann sogar das Mocking-Tool oder manuelles Mocking verwenden, um die Präsentationsschicht mit Daten zum Testen zu füllen.

12
riadh gomri

Für einige einfache Ansichten verwende ich mein DTO als meine Modelle, aber da Ansichten komplexer werden, erstelle ich ViewModels. 

Für mich ist es ein Gleichgewicht zwischen Schnelligkeit (Verwendung von DTO, da ich sie bereits habe) und Flexibilität (Erstellen von ViewModels bedeutet mehr Trennung von Anliegen).

8
sgwill

Wenn Sie DTO als ViewModel verwenden, bedeutet dies, dass Sie aus einem bestimmten Grund eine hohe Abhängigkeit von DTO aufbauen, weil Sie DTO ändern. Dies kann Auswirkungen auf ViewModel haben.

Verwenden Sie besser DTO und konvertieren Sie es in Viewmodel.

0
Lalit Khanna