Was ist ein Datenübertragungsobjekt (DTO)?

Question

Was ist ein Datenübertragungsobjekt?

In MVC sind die Modellklassen DTO, und wenn nicht, was sind die Unterschiede und brauchen wir beide?

Answer 1

Ein Datentransferobjekt ist ein Objekt, das dazu dient, Daten zu kapseln und sie von einem Teilsystem einer Anwendung an ein anderes zu senden.

DTOs werden am häufigsten von der Diensteschicht in einer N-Tier-Anwendung verwendet, um Daten zwischen ihr und der Benutzeroberflächenschicht zu übertragen. Der Hauptvorteil besteht darin, dass die Menge der Daten, die in verteilten Anwendungen über die Leitung gesendet werden müssen, reduziert wird. Sie eignen sich auch hervorragend als Modelle für das MVC-Muster.

Eine weitere Verwendung für DTOs kann darin bestehen, Parameter für Methodenaufrufe zu kapseln. Dies kann nützlich sein, wenn eine Methode mehr als vier oder fünf Parameter benötigt.

Wenn Sie das DTO-Muster verwenden, werden Sie auch DTO-Assembler einsetzen. Die Assembler werden verwendet, um DTOs aus Domain Objects zu erstellen und umgekehrt.

Die Konvertierung von einem Domänenobjekt zu einem DTO und wieder zurück kann ein kostspieliger Prozess sein. Wenn Sie keine verteilte Anwendung erstellen, werden Sie wahrscheinlich keine großen Vorteile aus diesem Muster ziehen, da Martin Fowler erklärt hier .

Answer 2

Die Definition für DTO ist zu finden unter Website von Martin Fowler . DTOs werden zur Übergabe von Parametern an Methoden und als Rückgabetypen verwendet. Viele Leute verwenden diese in der Benutzeroberfläche, aber andere blasen daraus Domänenobjekte auf.

Answer 3

Ein DTO ist ein dummes Objekt - es enthält nur Eigenschaften und hat Getter und Setter, aber keine andere Logik von Bedeutung (außer vielleicht einem compare() o equals() Umsetzung).

Typischerweise sind Modellklassen in MVC (hier wird von .net MVC ausgegangen) DTOs, oder Sammlungen/Aggregate von DTOs

Answer 4

Im Allgemeinen Wert-Objekte sollte unveränderlich sein. Wie Integer o Zeichenfolge Objekte in Java. Wir können sie für die Übertragung von Daten zwischen Softwareschichten verwenden. Wenn die Softwareschichten oder Dienste in verschiedenen entfernten Knoten laufen, wie in einer Microservices-Umgebung oder in einer Legacy Java Enterprise App. Wir müssen fast exakte Kopien von zwei Klassen erstellen. Hier sind wir auf DTOs gestoßen.

|-----------|                                                   |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------|                                                   |--------------|

In Legacy-Java-Enterprise-Systemen können DTOs verschiedene EJB-Elemente enthalten.

Ich weiß nicht, ob dies eine bewährte Praxis ist oder nicht, aber ich persönlich verwende Wert-Objekte in meinen Spring MVC/Boot-Projekten wie folgt:

        |------------|         |------------------|                             |------------|
-> Form |            | -> Form |                  | -> Entity                   |            |
        | Controller |         | Service / Facade |                             | Repository |
<- View |            | <- View |                  | <- Entity / Projection View |            |
        |------------|         |------------------|                             |------------|

Controller Die Ebene weiß nicht, was die Entitäten sind. Sie kommuniziert mit Formular y Wertobjekte anzeigen . Form Objects verfügt über JSR 303 Validierungsannotationen (zum Beispiel @NotNull) und Wertobjekte anzeigen haben Jackson Annotations für die benutzerdefinierte Serialisierung. (zum Beispiel @JsonIgnore)

Die Dienstebene kommuniziert mit der Repository-Ebene über Entity-Objekte. Entitätsobjekte sind mit JPA/Hibernate/Spring Data-Annotationen versehen. Jede Schicht kommuniziert nur mit der unteren Schicht. Die Kommunikation zwischen den Schichten ist wegen der zirkulären/zyklischen Abhängigkeit verboten.

User Service ----> XX CANNOT CALL XX ----> Order Service

Einige ORM Frameworks haben die Möglichkeit der Projektion durch die Verwendung zusätzlicher Schnittstellen oder Klassen. So können Repositories View-Objekte direkt zurückgeben. Hierfür ist keine zusätzliche Transformation erforderlich.

Dies ist zum Beispiel unsere Entität Benutzer:

@Entity
public final class User {
    private String id;
    private String firstname;
    private String lastname;
    private String phone;
    private String fax;
    private String address;
    // Accessors ...
}

Aber Sie sollten eine paginierte Liste von Benutzern zurückgeben, die nur id, Vorname, Nachname enthält. Dann können Sie ein View Value Object für die ORM-Projektion erstellen.

public final class UserListItemView {
    private String id;
    private String firstname;
    private String lastname;
    // Accessors ...
}

Sie können das paginierte Ergebnis leicht von der Repository-Ebene abrufen. Dank Spring können Sie auch nur Schnittstellen für Projektionen verwenden.

List<UserListItemView> find(Pageable pageable);

Machen Sie sich keine Sorgen um andere Umwandlungsvorgänge BeanUtils.copy Methode funktioniert einwandfrei.

Answer 5

1. Für mich ist die beste Antwort auf diese Frage Was ist eine DTO? ist das DTOs sind einfache Objekte, die keine Geschäftslogik oder Methodenimplementierung enthalten sollten, die einen Test erfordern würden. .
2. Normalerweise sind Ihre Modelle (unter Verwendung des MVC-Musters) intelligente Modelle, und sie können viele/einige Methoden enthalten, die einige verschiedene Operationen speziell für dieses Modell durchführen (keine Geschäftslogik, dies sollte bei den Controllern sein). Wenn Sie jedoch Daten übertragen (z.B. durch den Aufruf einer REST ( GET / POST /was auch immer) Endpunkt von irgendwo, oder einen Webservice mit SOA, etc...) Sie wollen nicht das große Objekt mit Code, der nicht für den Endpunkt notwendig ist, wird Daten verbrauchen, und verlangsamen die Übertragung zu übertragen.