Wozu dient DTO (Data Transfer Objects)?

Was ist der Sinn von DTO und ist es ein veraltetes Konzept? Ich verwende POJOs in der Ansichtsebene, um Daten zu übertragen und zu speichern. Können diese POJOs als Alternative zu DTOs betrachtet werden?

DTO ist ein Muster und unabhängig von der Implementierung (POJO / POCO). Laut DTO sollte die Antwort auf jeden Anruf so viele Daten wie möglich bringen, da jeder Anruf an eine Remote-Schnittstelle teuer ist. Wenn also mehrere Anforderungen erforderlich sind, um Daten für eine bestimmte Aufgabe zu übertragen, können die zu übertragenden Daten in einem DTO kombiniert werden, sodass nur eine Anforderung alle erforderlichen Daten übertragen kann. Der Musterkatalog der Enterprise-Anwendungsarchitektur enthält weitere Details.

DTOs sind ein grundlegendes Konzept, nicht veraltet.

DTO als Konzept (Objekte, deren Zweck darin besteht, Daten zu sammeln, die vom Server an den Client zurückgegeben werden sollen) ist sicherlich nicht veraltet.

Was ist etwas veraltet der Begriff der mit DTOs ist , die überhaupt keine Logik enthalten, werden verwendet , nur für die Übertragung von Daten und „abgebildet“ von Domänenobjekten vor der Übertragung an den Client, und Modelle sehen abgebildet , bevor sie auf der Anzeigeschicht vorbei. In einfachen Anwendungen können die Domänenobjekte häufig direkt als DTOs wiederverwendet und direkt an die Anzeigeebene übergeben werden, sodass nur ein einheitliches Datenmodell vorhanden ist. Bei komplexeren Anwendungen möchten Sie nicht das gesamte Domänenmodell für den Client verfügbar machen. Daher ist eine Zuordnung von Domänenmodellen zu DTOs erforderlich. Ein separates Ansichtsmodell, das die Daten aus den DTOs dupliziert, ist so gut wie nie sinnvoll.

Der Grund, warum dieser Begriff veraltet und nicht einfach falsch ist, ist, dass einige (hauptsächlich ältere) Frameworks / Technologien dies erfordern, da ihre Domänen- und Ansichtsmodelle nicht POJOS sind und stattdessen direkt an das Framework gebunden sind.

Vor allem waren Entity Beans in J2EE vor dem EJB 3-Standard keine POJOs, sondern vom App-Server erstellte Proxy-Objekte. Sie konnten einfach nicht an den Client gesendet werden, sodass Sie keine andere DTO-Ebene benötigen - Es war obligatorisch.

Obwohl DTO kein veraltetes Muster ist, wird es oft unnötig angewendet, was dazu führen kann, dass es veraltet erscheint.

Das am häufigsten missbrauchte Muster in der Java Enterprise-Community ist das DTO. DTO wurde klar als Lösung für ein Distributionsproblem definiert. DTO sollte ein grobkörniger Datencontainer sein, der Daten effizient zwischen Prozessen (Ebenen) transportiert. ~ Adam Bien

Angenommen, Sie haben eine JSF ManagedBean. Eine häufig gestellte Frage ist, ob die Bean direkt einen Verweis auf eine JPA-Entität enthalten soll oder ob sie einen Verweis auf ein Zwischenobjekt beibehalten soll, das später in eine Entität konvertiert wird. Ich habe gehört, dass dieses Zwischenobjekt als DTO bezeichnet wird. Wenn jedoch Ihre ManagedBeans und Entities in derselben JVM ausgeführt werden, hat die Verwendung des DTO-Musters nur geringe Vorteile.

Beachten Sie Anmerkungen zur Bean-Validierung. Ihre JPA-Entitäten sind wahrscheinlich mit @NotNull- und @Size-Überprüfungen versehen. Wenn Sie ein DTO verwenden, möchten Sie diese Überprüfungen in Ihrem DTO wiederholen, damit Clients, die Ihre Remoteschnittstelle verwenden, keine Nachricht senden müssen, um festzustellen, ob die grundlegende Überprüfung fehlgeschlagen ist. Stellen Sie sich die zusätzliche Arbeit vor, die beim Kopieren von Bean-Validierungs-Annotationen zwischen Ihrem DTO und Entity anfällt. Wenn Ihre View und Entities jedoch in derselben JVM ausgeführt werden, müssen Sie diese zusätzliche Arbeit nicht übernehmen: Verwenden Sie einfach die Entities.

IAmTheDudes Link zum Musterkatalog der Enterprise-Anwendungsarchitektur bietet eine kurze Erklärung der DTOs, und hier sind weitere Referenzen, die mir aufgefallen sind:

• HANDHABUNG MIT J2EE UND DESIGNMUSTERN
• Verwendung von DTO in JSF + Spring + Hibernate
• Vor- und Nachteile von Datenübertragungsobjekten

Absolut nicht! Erst kürzlich habe ich gelernt, wie man DTOs besser einsetzt als das von Ihnen verwendete Geschäftsobjekt (möglicherweise an den ORM-Mapper gebunden).

Verwenden Sie sie jedoch nur, wenn sie für die Verwendung geeignet sind, und nicht nur, um sie zu verwenden, da sie in einem guten Musterbuch erwähnt werden.
Ein typisches Beispiel, das mir gerade einfällt, ist, wenn Sie eine Schnittstelle für Dritte bereitstellen. In einem solchen Szenario möchten Sie die ausgetauschten Objekte ziemlich stabil halten, was Sie normalerweise mit DTOs gut erreichen können.

Ein Ort, an dem sich DTOs als besonders nützlich erwiesen haben, ist das Enthalten von Logik für API-Antworten. Mit diesem Muster ist es einfach, verschiedene Arten von Antworten von Objekten in verschiedenen Formaten testbar zu verwalten. Anhand dieses Musters konnten wir in meiner derzeitigen Rolle mit dem Testen der Antwortformate für unsere APIs beginnen. Dies hat sich als nützlich erwiesen, da unser Stack bei verschiedenen Clients (http / mobile) isomorpher wird. Auf keinen Fall veraltet.