Różnica między DTO, VO, POJO, JavaBeans?

Question

Różnica między DTO, VO, POJO, JavaBeans?

Widziałem podobne pytania:

Czy możesz mi również powiedzieć, w jakich kontekstach są one używane? Czy ich cel?

451

java terminology javabeans dto pojo

Author: Community, 2009-10-23

Source

6 answers

DTO vs VO

Dto - obiekty transferu danych to po prostu kontenery danych, które są używane do transportu danych między warstwami i warstwami.

zawiera głównie atrybuty. Można nawet używać atrybutów publicznych bez getterów i setterów.
obiekty transmisji danych nie zawierają żadnej logiki biznesowej.

Analogia:
prosty formularz rejestracyjny z atrybutami nazwa użytkownika, hasło i e-mail id.

Po przesłaniu tego formularza w pliku RegistrationServlet otrzymasz wszystkie atrybuty z warstwy widoku do warstwy biznesowej, w której przechodzisz atrybuty do java beans, a następnie do DAO lub warstwy persistence.

DTO pomaga w przenoszeniu atrybutów z warstwy widoku do warstwy biznesowej i wreszcie do warstwy trwałości.

DTO był używany głównie do wydajnego przesyłania danych przez sieć, może to być nawet z JVM do innego JVM.

Dto są często java.io.Serializable - w celu przesyłania danych przez JVM.

Vo - obiekt wartości [1][2] reprezentuje sobie stały zestaw danych i jest podobny do Java enum. Tożsamość obiektu wartości opiera się na jego stanie, a nie na jego tożsamości i jest niezmienna. Prawdziwym przykładem może być kolor.Czerwony, kolor.NIEBIESKI, SEKS.Kobieta itp.

POJO vs JavaBeans

[1] Java-Beanness POJO jest to, że jego prywatne atrybuty są dostępne poprzez publiczne gettery i settery zgodne z konwencjami JavaBeans. np.

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

[2] JavaBeans musi zaimplementować Serializable i mieć konstruktor bez argumentów, podczas gdy w POJO nie ma tych ograniczeń.

49

Author: Srinivas M.V.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-26 19:32:46

Zasadniczo,

DTO: "Obiekty transmisji danych" mogą przemieszczać się między oddzielnymi warstwami w architekturze oprogramowania.

VO: "Value objects" przechowuje obiekty takie jak Integer,Money itp.

POJO: zwykły stary obiekt Java, który nie jest obiektem specjalnym.

Java Beans: wymaga Java Class aby można było serializować, mieć konstruktor no-arg oraz getter i setter dla każdego pola

36

Author: Olcay Tarazan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-15 10:06:59

Ziarna Javy to nie to samo co EJB.

Specyfikacja JavaBeans w Javie 1.0 była próbą Sun, aby umożliwić manipulowanie obiektami Javy w IDE wyglądającym jak VB. Dla obiektów zakwalifikowanych jako "Java Beans"istniały reguły:

konstruktor domyślny
Gettery i settery dla prywatnych członków danych, które przestrzegały właściwej konwencji nazewnictwa
Serializable

EJBs przyszedł później. Łączą one rozproszone komponenty i model transakcyjny, działający w kontenerze, który zarządza wątkami, łączeniami, cyklem życia i świadczy usługi. Są dalekie od fasoli Jawy.

DTOs pojawił się w kontekście Javy, ponieważ ludzie odkryli, że specyfikacja EJB 1.0 była zbyt "gadatliwa" z bazą danych. Zamiast robić roundtrip dla każdego elementu danych, ludzie pakują je do Java Beans luzem i wysyłają je dookoła.

POJOs był reakcją na EJBs.

22

Author: duffymo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-26 12:58:36

POJO : Jest to plik java (Klasa), który nie rozszerza ani nie implementuje żadnego innego pliku java (Klasa).

Bean : Jest to plik(Klasa) Javy, w którym wszystkie zmienne są prywatne, metody są publiczne i odpowiednie gettery i settery są używane do uzyskiwania dostępu do zmiennych.

Klasa normalna : Jest to plik java (Klasa), który może składać się z publicznych/prywatnych/domyślnych / chronionych zmiennych i które mogą lub nie mogą rozszerzyć lub zaimplementować inny plik java(Klasa).

3

Author: Suraj Kalokhe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-08-17 05:31:53

Pierwsza Rozmowa O

Klasa normalna - oznacza to dowolne definiowanie klas, które jest normalnie w Javie oznacza to, że tworzysz różne typy właściwości metod itd.
Bean- Bean to nic to tylko obiekt danej klasy używając tego bean możesz uzyskać dostęp do swojej klasy java tak samo jak object..

I po tej rozmowie o ostatnim POJO

POJO - POJO to ta klasa, która nie ma żadnych usług, które ma tylko domyślny konstruktor i własność prywatna oraz te właściwości do ustawiania wartości odpowiadające metodom setter i getter. Jest to krótka forma zwykłego obiektu Java.

1

Author: ASHISH KUMAR SINGH,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-12-15 09:25:44

score 722 · Accepted Answer

JavaBeans

JavaBean jest klasą, która jest zgodna z konwencjami JavaBeans zdefiniowanymi przez Sun. Wikipedia ma całkiem dobre podsumowanie tego, czym JavaBeans są:

JavaBeans to komponenty oprogramowania do Javy wielokrotnego użytku, które można wizualnie manipulować w narzędziu do budowania. W praktyce są to Klasy napisane w języku programowania Java, zgodne z określoną konwencją. Są one używane do hermetyzacji wielu obiektów w jeden obiekt (fasola), więc że mogą być przekazywane jako pojedynczy obiekt bean zamiast jako wiele pojedynczych obiektów. JavaBean to obiekt Java, który można serializować, ma konstruktor zerowy i umożliwia dostęp do właściwości za pomocą metod getter i setter.

Aby funkcjonować jako klasa JavaBean, Klasa obiektu musi przestrzegać pewnych konwencji dotyczących nazewnictwa, budowy i zachowania metod. Konwencje te umożliwiają posiadanie narzędzi, które mogą używać, ponownie używać, zastępować i łączyć JavaBeans.

Wymagane konwencje to:

klasa musi mieć publiczny konstruktor domyślny. Umożliwia to łatwe tworzenie instancji w ramach edycji i aktywacji.

właściwości klasy muszą być dostępne za pomocą get, set i innych metod( tak zwanych metod accessor i metod mutator), zgodnie ze standardową konwencją nazewnictwa. Pozwala to na łatwą automatyczną kontrolę i aktualizację stanu fasoli w ramach frameworków, z których wiele zawiera niestandardowe edytory dla różnych typów właściwości.

klasa powinna być serializowalna. Pozwala to aplikacjom i frameworkom niezawodnie zapisywać, przechowywać i przywracać stan bean w sposób niezależny od maszyny wirtualnej i platformy.

Ponieważ wymagania te są w dużej mierze wyrażane jako konwencje, a nie implementacje interfejsów, niektórzy programiści postrzegają JavaBeans jako zwykłe stare obiekty Javy, które są zgodne z określonymi konwencjami nazewnictwa.

POJO

A Plain Old Java Object lub POJO to termin początkowo wprowadzony w celu określenia prostego lekkiego obiektu Java, nie implementującego żadnego interfejsu javax.ejb, w przeciwieństwie do ciężkiego EJB 2.x (zwłaszcza Entity Beans, Stateless Session Beans nie są tak złe IMO). Obecnie termin ten jest używany dla każdego prostego przedmiotu bez dodatkowych rzeczy. Po raz kolejny Wikipedia robi dobrą robotę w definiowaniu POJO :

POJO jest akronimem zwykłej starej Javy Obiekt. Nazwa jest używana dla podkreślenia że obiekt w pytaniu jest zwykły obiekt Java, a nie specjalny przedmiot, a w szczególności nie Enterprise JavaBean (zwłaszcza przed EJB 3). Termin został wymyślony przez Marcina Fowler, Rebecca Parsons i Josh MacKenzie we wrześniu 2000:

"zastanawialiśmy się, dlaczego ludzie są tak przeciwni używaniu zwykłych przedmiotów w swoich systemów i doszedł do wniosku, że jest ponieważ prostym przedmiotom brakowało fantazji nazwisko. Więc daliśmy im jeden i to jest złapany na bardzo ładnie."

Termin kontynuuje wzorzec starsze terminy dla technologii, które nie używaj wymyślnych nowych funkcji, takich jak Garnki (zwykły stary telefon) w telefonii, oraz PODS (zwykłe stare dane Struktury), które są zdefiniowane w C++ ale używać tylko funkcji języka C i POD (zwykła stara dokumentacja) w Perlu.

Określenie najprawdopodobniej zyskało powszechna akceptacja ze względu na potrzeba wspólnego i łatwego rozumiane pojęcie, które kontrastuje z skomplikowane struktury obiektów. A JavaBean to POJO, które jest serializowalny, nie ma argumentu konstruktora, oraz umożliwia dostęp do właściwości za pomocą gettera i settera metody. Przedsiębiorstwo JavaBean nie jest jedna klasa, ale cały komponent model (ponownie EJB 3 zmniejsza complexity of Enterprise JavaBeans).

Ponieważ projekty wykorzystujące Pojo stały się częściej stosowane, systemy mają powstały, które dają POJOs niektóre z funkcjonalność stosowana w frameworkach i więcej wybór o jakich obszarach funkcjonalność jest rzeczywiście potrzebna. Hibernate i Spring są przykładami.

Obiekt Wartości

Obiekt wartości lub VO jest obiektem takim jak java.lang.Integer, który przechowuje wartości (stąd obiekty wartości). Aby uzyskać bardziej formalną definicję, często odwołuję się do opisu Martina Fowlera Value Object :

W wzorcach architektury aplikacji korporacyjnych opisałem obiekt Value jako mały obiekt, taki jak obiekt pieniędzy lub zakresu dat. Ich klucz właściwość polega na tym, że kierują się semantyką wartości, a nie semantyką odniesienia.

Zazwyczaj można im powiedzieć, ponieważ ich pojęcie równości nie opiera się na tożsamości, zamiast tego dwa obiekty wartości są równe, jeśli wszystkie ich pola są równe. Chociaż wszystkie pola są równe, nie musisz porównywać wszystkich pól, jeśli podzbiór jest unikalny - na przykład kody walut dla obiektów waluty są wystarczające, aby sprawdzić równość.

Ogólna heurystyka polega na tym, że obiekty wartości powinny być całkowicie niezmienny. Jeśli chcesz zmienić obiekt value, powinieneś zastąpić go nowym i nie mieć prawa do aktualizacji wartości samego obiektu value - aktualizowanie obiektów value prowadzi do problemów z aliasingiem.

Wczesna Literatura J2EE używała terminu value object do opisania innego pojęcia, co nazywam Data Transfer Object. Od tego czasu zmienili swoje użycie i zamiast tego używają terminu Transfer Object .

Możesz znaleźć więcej dobrego materiału na obiektach value na wiki i przez Dirk Riehle .

Obiekt Transmisji Danych

Data Transfer Object lub DTO jest (anty) wzorcem wprowadzonym z EJB. Zamiast wykonywać wiele zdalnych wywołań EJB, chodziło o to, aby zamknąć dane w obiekcie value, który może być przesyłany przez sieć: obiekcie transferu danych. Wikipedia ma przyzwoitą definicję Data Transfer Object :

Data transfer object (DTO), dawniej znany jako value objects lub Vo, jest wzorcem projektowym używanym do przesyłania danych między podsystemami aplikacji. Dto są często używane w połączeniu z obiektami data access do pobierania danych z bazy danych.

Różnica między obiektami transferu danych a obiektami biznesowymi lub obiektami dostępu do danych polega na tym, że DTO nie zachowuje się w żaden sposób poza przechowywaniem i pobieraniem własnych danych (accesorów i mutatorów).

W tradycyjnej architekturze EJB, DTOs służą podwójnym celom: po pierwsze, działają wokół problemu, że entity beans nie są serializowalne; po drugie, domyślnie definiują fazę montażu, w której wszystkie dane używane przez Widok są pobierane i przesyłane do DT przed powrotem kontroli do warstwy prezentacji.

Więc dla wielu ludzi DTOs i VOs to to samo (ale Fowler używa VOs, aby oznaczać coś innego, jak widzieliśmy). W większości przypadków są one zgodne z konwencjami JavaBeans i dlatego też są Javabeansami. I wszyscy są Pojami.