it-swarm.dev

Unterschied zwischen DTO, VO, POJO, JavaBeans?

Habe einige ähnliche Fragen gesehen:

Können Sie mir bitte auch die Kontexte mitteilen, in denen sie verwendet werden? Oder der Zweck von ihnen?

526
jai

JavaBeans

Eine JavaBean ist eine Klasse, die den von Sun definierten JavaBeans-Konventionen folgt. Wikipedia hat eine ziemlich gute Zusammenfassung dessen, was JavaBeans sind:

JavaBeans sind wiederverwendbare Softwarekomponenten für Java, die visuell in einem Builder-Tool bearbeitet werden können. Praktisch handelt es sich um Klassen, die in der Programmiersprache Java geschrieben sind und einer bestimmten Konvention entsprechen. Sie werden verwendet, um viele Objekte in einem einzelnen Objekt (der Bean) zu kapseln, sodass sie als einzelnes Bean-Objekt anstatt als mehrere einzelne Objekte weitergegeben werden können. Eine JavaBean ist ein Java -Objekt, das serialisierbar ist, einen Null-Konstruktor aufweist und den Zugriff auf Eigenschaften mithilfe von Getter- und Setter-Methoden ermöglicht.

Um als JavaBean-Klasse zu fungieren, muss eine Objektklasse bestimmten Konventionen hinsichtlich Methodennamen, -aufbau und -verhalten entsprechen. Diese Konventionen ermöglichen Tools, die JavaBeans verwenden, wiederverwenden, ersetzen und verbinden können.

Die erforderlichen Konventionen sind:

  • Die Klasse muss einen öffentlichen Standardkonstruktor haben. Dies ermöglicht eine einfache Instanziierung innerhalb von Bearbeitungs- und Aktivierungsframeworks.
  • Auf die Klasseneigenschaften muss unter Verwendung von get-, set- und anderen Methoden (sogenannte Accessor-Methoden und Mutator-Methoden) gemäß einer Standardbenennungskonvention zugegriffen werden. Dies ermöglicht eine einfache automatisierte Überprüfung und Aktualisierung des Bean-Status innerhalb von Frameworks, von denen viele benutzerdefinierte Editoren für verschiedene Arten von Eigenschaften enthalten.
  • Die Klasse sollte serialisierbar sein. Auf diese Weise können Anwendungen und Frameworks den Bean-Status zuverlässig und unabhängig von VM und Plattform speichern, speichern und wiederherstellen.

Da diese Anforderungen größtenteils als Konventionen und nicht durch die Implementierung von Schnittstellen ausgedrückt werden, betrachten einige Entwickler JavaBeans als einfache alte Java Objekte, die bestimmten Namenskonventionen folgen.

POJO

Ein einfaches altes Java Objekt oder POJO ist ein Begriff, der ursprünglich eingeführt wurde, um ein einfaches Java Objekt zu bezeichnen, das keine javax.ejb Schnittstelle implementiert, im Gegensatz zu schwerem EJB 2.x (insbesondere Entity Beans) , Stateless Session Beans sind nicht so schlecht (IMO). Heutzutage wird der Begriff für jedes einfache Objekt ohne zusätzliches Material verwendet. Auch hier leistet Wikipedia gute Arbeit bei der Definition von POJO :

POJO ist eine Abkürzung für Plain Old Java Object. Der Name wird verwendet, um hervorzuheben, dass das betreffende Objekt ein gewöhnliches Java - Objekt ist, kein spezielles Objekt und insbesondere kein Enterprise JavaBean (insbesondere vor EJB 3). Der Begriff wurde im September 2000 von Martin Fowler, Rebecca Parsons und Josh MacKenzie geprägt:

"Wir haben uns gefragt, warum die Leute so dagegen sind, reguläre Objekte in ihren Systemen zu verwenden, und sind zu dem Schluss gekommen, dass einfache Objekte keinen ausgefallenen Namen haben. Deshalb haben wir ihnen einen gegeben, und das hat sich sehr positiv ausgewirkt."

Der Begriff setzt das Muster älterer Begriffe für Technologien fort, die keine ausgefallenen neuen Funktionen verwenden, z. B. POTS (Plain Old Telephone Service) in der Telefonie und PODS (Plain Old Data Structures), die in C++ definiert sind, jedoch nur Funktionen der Sprache C verwenden. und POD (Plain Old Documentation) in Perl.

Der Begriff hat höchstwahrscheinlich breite Akzeptanz gewonnen, da ein gemeinsamer und leicht verständlicher Begriff benötigt wird, der im Gegensatz zu komplizierten Objekt-Frameworks steht. Eine JavaBean ist ein POJO, das serialisierbar ist, über einen Konstruktor ohne Argumente verfügt und den Zugriff auf Eigenschaften mithilfe von Getter- und Setter-Methoden ermöglicht. Eine Enterprise JavaBean ist keine einzelne Klasse, sondern ein gesamtes Komponentenmodell (EJB 3 reduziert wiederum die Komplexität von Enterprise JavaBeans).

Mit der zunehmenden Verbreitung von POJO-Designs sind Systeme entstanden, die POJOs einen Teil der in Frameworks verwendeten Funktionalität und eine größere Auswahl darüber bieten, welche Funktionsbereiche tatsächlich benötigt werden. Ruhezustand und Frühling sind Beispiele.

Wertobjekt

Ein Wertobjekt oder VO ist ein Objekt wie Java.lang.Integer, das Werte enthält (daher Wertobjekte). Für eine formalere Definition verweise ich oft auf Martin Fowlers Beschreibung von Value Object :

In Patterns of Enterprise Application Architecture habe ich Value Object als kleines Objekt beschrieben, z. B. als Money- oder Datumsbereichsobjekt. Ihre Schlüsseleigenschaft ist, dass sie der Wertsemantik und nicht der Referenzsemantik folgen.

Sie können es ihnen normalerweise sagen, weil ihre Vorstellung von Gleichheit nicht auf Identität basiert, sondern zwei Wertobjekte gleich sind, wenn alle Felder gleich sind. Obwohl alle Felder gleich sind, müssen Sie nicht alle Felder vergleichen, wenn eine Teilmenge eindeutig ist. Beispielsweise reichen Währungscodes für Währungsobjekte aus, um die Gleichheit zu testen.

Eine allgemeine Heuristik ist, dass Wertobjekte völlig unveränderlich sein sollten. Wenn Sie ein Wertobjekt ändern möchten, sollten Sie das Objekt durch ein neues ersetzen und dürfen die Werte des Wertobjekts selbst nicht aktualisieren. Aktualisierbare Wertobjekte führen zu Aliasing-Problemen.

In der frühen J2EE-Literatur wurde der Begriff value object verwendet, um einen anderen Begriff zu beschreiben, den ich Data Transfer Object nenne. Sie haben seitdem ihre Verwendung geändert und verwenden stattdessen den Begriff Transfer Object .

Weiteres gutes Material zu Wertobjekten finden Sie im wiki und bei Dirk Riehle .

Datenübertragungsobjekt

Data Transfer Object oder DTO ist ein mit EJB eingeführtes (Anti) Muster. Anstatt viele Remote-Aufrufe an EJBs durchzuführen, sollten die Daten in einem Wertobjekt gekapselt werden, das über das Netzwerk übertragen werden kann: einem Datenübertragungsobjekt. Wikipedia hat eine anständige Definition von Datenübertragungsobjekt :

Data Transfer Object (DTO), früher als Value Objects oder VO bezeichnet, ist ein Entwurfsmuster, das zum Übertragen von Daten zwischen Softwareanwendungssubsystemen verwendet wird. DTOs werden häufig in Verbindung mit Datenzugriffsobjekten verwendet, um Daten aus einer Datenbank abzurufen.

Der Unterschied zwischen Datenübertragungsobjekten und Geschäftsobjekten oder Datenzugriffsobjekten besteht darin, dass ein DTO kein anderes Verhalten aufweist als das Speichern und Abrufen seiner eigenen Daten (Accessoren und Mutatoren).

In einer traditionellen EJB-Architektur dienen DTOs zwei Zwecken: Erstens umgehen sie das Problem, dass Entity-Beans nicht serialisierbar sind. Zweitens definieren sie implizit eine Assembly-Phase, in der alle von der Ansicht zu verwendenden Daten abgerufen und in die DTOs eingeordnet werden, bevor die Kontrolle an die Präsentationsebene zurückgegeben wird.


Für viele Menschen sind also DTOs und VOs dasselbe (aber Fowler verwendet VOs, um etwas anderes zu bedeuten, als wir gesehen haben). Meistens folgen sie den JavaBeans-Konventionen und sind daher auch JavaBeans. Und alle sind POJOs.

792
Pascal Thivent

DTO vs VO

DTO - Datenübertragungsobjekte sind nur Datencontainer, mit denen Daten zwischen Ebenen und Ebenen transportiert werden.

  • Es enthält hauptsächlich Attribute. Sie können sogar öffentliche Attribute ohne Getter und Setter verwenden.
  • Datenübertragungsobjekte enthalten keine Geschäftslogik.

Analogie:
Einfaches Registrierungsformular mit den Attributen Benutzername, Passwort und E-Mail-ID.

  • Wenn dieses Formular in der RegistrationServlet-Datei gesendet wird, erhalten Sie alle Attribute von der Ansichtsebene zur Geschäftsebene, wo Sie die Attribute an Java Beans und dann an das DAO oder die Persistenzebene übergeben.
  • DTOs helfen beim Transportieren der Attribute von der Ansichtsschicht zur Geschäftsschicht und schließlich zur Persistenzschicht.

DTO wurde hauptsächlich verwendet, um Daten effizient über das Netzwerk zu transportieren, möglicherweise sogar von JVM zu einer anderen JVM.

DTOs sind häufig Java.io.Serializable - um Daten über JVM zu übertragen.

VO - Ein Wertobjekt [1] [2] stellt sich selbst als fester Datensatz dar und ähnelt einer Java-Aufzählung. Die Identität eines Wertobjekts basiert eher auf seinem Zustand als auf seiner Objektidentität und ist unveränderlich. Ein Beispiel aus der Praxis wäre Color.RED, Color.BLUE, SEX.FEMALE usw.

POJO vs JavaBeans

[1] Die Java-Beanness eines POJO besteht darin, dass auf seine privaten Attribute alle über öffentliche Getter und Setter zugegriffen wird, die den JavaBeans-Konventionen entsprechen. z.B.

    private String foo;
    public String getFoo(){...}
    public void setFoo(String foo){...}; 

[2] JavaBeans müssen Serializable implementieren und einen Konstruktor ohne Argumente haben, wohingegen in POJO diese Einschränkungen nicht gelten.

60
Srinivas M.V.

Grundsätzlich gilt,

DTO: "Datenübertragungsobjekte" können in der Softwarearchitektur zwischen verschiedenen Ebenen übertragen werden.

VO: "Wertobjekte" enthalten ein Objekt wie Integer, Money usw.

POJO: Plain Old Java Objekt, das kein spezielles Objekt ist.

Java Beans: Setzt voraus, dass ein Java Class serialisierbar ist, einen no-arg -Konstruktor sowie einen Getter und Setter für jedes Feld

42
Olcay Tarazan

Java Beans sind nicht dasselbe wie EJBs.

Die JavaBeans-Spezifikation in Java 1.0 war Suns Versuch, die Manipulation von Java Objekten in einem IDE zuzulassen, das wie VB aussah. Es wurden Regeln für Objekte festgelegt, die sich als "Java Beans" qualifizieren:

  1. Standardkonstruktor
  2. Getter und Setter für private Datenmitglieder, die die richtige Namenskonvention befolgt haben
  3. Serialisierbar
  4. Vielleicht andere, die ich vergesse.

EJBs kamen später. Sie kombinieren verteilte Komponenten und ein Transaktionsmodell, das in einem Container ausgeführt wird, der Threads, Pooling, Lebenszyklus und Dienste verwaltet. Sie sind weit entfernt von Java Beans.

DTOs entstanden im Kontext Java, weil die Leute herausfanden, dass die EJB 1.0-Spezifikation zu "gesprächig" mit der Datenbank war. Anstatt für jedes Datenelement einen Roundtrip durchzuführen, verpackten die Benutzer sie in Java Beans in loser Schüttung und versendeten sie herum.

POJOs waren eine Reaktion gegen EJBs.

24
duffymo

POJO: Dies ist eine Java-Datei (Klasse), die keine andere Java-Datei (Klasse) erweitert oder implementiert.

Bean: Dies ist eine Java -Datei (Klasse), in der alle Variablen privat sind, Methoden öffentlich sind und geeignete Get- und Setter für den Zugriff auf Variablen verwendet werden.

Normale Klasse: Dies ist eine Java-Datei (Klasse), die aus öffentlichen/privaten/standardmäßigen/geschützten Variablen bestehen kann und die eine andere Java Datei (Klasse).

4
Suraj Kalokhe

Erstes Gespräch über

Normale Klasse- Das bedeutet, dass jede Klasse definiert, die normalerweise in Java enthalten ist. Das bedeutet, dass Sie verschiedene Arten von Methodeneigenschaften erstellen etc. =
Bean - Bean ist nichts, es ist nur ein Objekt dieser bestimmten Klasse, mit dieser Bean können Sie auf Ihre Klasse Java wie object zugreifen. ..

und danach über das letzte POJO sprechen

POJO - POJO ist die Klasse, die keine Dienste hat, sondern nur einen Standardkonstruktor und eine Privateigenschaft sowie eine Eigenschaft zum Festlegen eines Werts für die entsprechenden Setter- und Getter-Methoden . Es ist eine Kurzform von Plain Java Object.

1
  • Wertobjekt : Verwenden Sie diese Option, wenn Sie die Gleichheit der Objekte basierend auf dem Wert der Objekte messen möchten.
  • Datenübertragungsobjekt : Übergeben Sie Daten mit mehreren Attributen in einer Aufnahme von Client zu Server über mehrere Ebenen hinweg, um mehrere Aufrufe an den Remoteserver zu vermeiden.
  • Plain Old Java Object : Es ist wie eine einfache Klasse, welche Eigenschaften, öffentliche Konstruktoren ohne Argumente. Wie wir für JPA Entität erklären.

Differenz-zwischen-Wert-Objektmuster-und-Datenübertragungsmuster

0
Atul Jain