Differenza tra DTO, VO, POJO, JavaBeans?


Risposte:


848

JavaBeans

Un JavaBean è una classe che segue le convenzioni JavaBeans definite da Sun. Wikipedia ha un riassunto abbastanza buono di ciò che sono JavaBeans :

JavaBeans sono componenti software riutilizzabili per Java che possono essere manipolati visivamente in uno strumento di creazione. In pratica, sono classi scritte nel linguaggio di programmazione Java conforme a una particolare convenzione. Sono utilizzati per incapsulare molti oggetti in un singolo oggetto (il bean), in modo che possano essere passati come un singolo oggetto bean anziché come singoli oggetti multipli. Un JavaBean è un oggetto Java serializzabile, ha un costruttore nullo e consente l'accesso alle proprietà usando i metodi getter e setter.

Per funzionare come una classe JavaBean, una classe di oggetti deve obbedire a determinate convenzioni su denominazione, costruzione e comportamento del metodo. Queste convenzioni consentono di disporre di strumenti in grado di utilizzare, riutilizzare, sostituire e connettere JavaBeans.

Le convenzioni richieste sono:

  • La classe deve avere un costruttore predefinito pubblico. Ciò consente una facile istanza all'interno di framework di modifica e attivazione.
  • Le proprietà della classe devono essere accessibili usando get, set e altri metodi (i cosiddetti metodi accessor e metodi mutator), seguendo una convenzione di denominazione standard. Ciò consente una facile ispezione e aggiornamento automatizzati dello stato del bean all'interno di framework, molti dei quali includono editor personalizzati per vari tipi di proprietà.
  • La classe dovrebbe essere serializzabile. Ciò consente alle applicazioni e ai framework di salvare, archiviare e ripristinare in modo affidabile lo stato del bean in modo indipendente dalla VM e dalla piattaforma.

Poiché questi requisiti sono in gran parte espressi come convenzioni anziché mediante l'implementazione di interfacce, alcuni sviluppatori vedono JavaBeans come semplici vecchi oggetti Java che seguono convenzioni di denominazione specifiche.

POJO

Un semplice vecchio oggetto Java o POJO è un termine inizialmente introdotto per designare un semplice oggetto Java leggero, non implementando alcuna javax.ejbinterfaccia, al contrario di EJB 2.x pesante (in particolare i bean di entità, i bean di sessione senza stato non sono così male IMO). Oggi, il termine è usato per qualsiasi oggetto semplice senza roba extra. Ancora una volta, Wikipedia fa un buon lavoro nel definire POJO :

POJO è l'acronimo di Plain Old Java Object. Il nome viene utilizzato per sottolineare che l'oggetto in questione è un normale oggetto Java, non un oggetto speciale, e in particolare non un Enterprise JavaBean (specialmente prima di EJB 3). Il termine è stato coniato da Martin Fowler, Rebecca Parsons e Josh MacKenzie nel settembre 2000:

"Ci siamo chiesti perché le persone fossero così contrarie all'utilizzo di oggetti regolari nei loro sistemi e abbiamo concluso che era perché gli oggetti semplici non avevano un nome di fantasia. Quindi ne abbiamo dato uno, e si è preso molto bene."

Il termine continua il modello di termini più vecchi per le tecnologie che non utilizzano nuove fantasiose funzionalità, come POTS (Plain Old Telephone Service) nella telefonia e PODS (Plain Old Data Structures) che sono definiti in C ++ ma utilizzano solo funzionalità in linguaggio C, e POD (Plain Old Documentation) in Perl.

Il termine ha probabilmente ottenuto un'accettazione diffusa a causa della necessità di un termine comune e facilmente comprensibile che contrasta con schemi di oggetti complicati. Un JavaBean è un POJO serializzabile, ha un costruttore senza argomenti e consente l'accesso alle proprietà utilizzando i metodi getter e setter. Un Enterprise JavaBean non è una singola classe ma un intero modello di componente (di nuovo, EJB 3 riduce la complessità di Enterprise JavaBeans).

Man mano che i progetti che utilizzano POJO sono diventati più comunemente utilizzati, sono sorti sistemi che offrono ai POJO alcune delle funzionalità utilizzate nei framework e una maggiore scelta su quali aree di funzionalità sono effettivamente necessarie. Hibernate e Spring sono esempi.

Valore oggetto

Un oggetto valore o VO è un oggetto come quello java.lang.Integerche contiene valori (quindi oggetti valore). Per una definizione più formale, mi riferisco spesso alla descrizione di Value Object di Martin Fowler :

In Patterns of Enterprise Application Architecture ho descritto Value Object come un piccolo oggetto come un oggetto Money o intervallo di date. La loro proprietà chiave è che seguono la semantica di valore anziché la semantica di riferimento.

Di solito puoi dirlo perché la loro nozione di uguaglianza non si basa sull'identità, invece due oggetti valore sono uguali se tutti i loro campi sono uguali. Sebbene tutti i campi siano uguali, non è necessario confrontare tutti i campi se un sottoinsieme è univoco, ad esempio i codici valuta per gli oggetti valuta sono sufficienti per verificare l'uguaglianza.

Un'euristica generale è che gli oggetti valore dovrebbero essere completamente immutabili. Se si desidera modificare un oggetto valore, è necessario sostituire l'oggetto con uno nuovo e non poter aggiornare i valori dell'oggetto valore stesso: gli oggetti valore aggiornabili comportano problemi di aliasing.

La prima letteratura J2EE ha usato il termine valore oggetto per descrivere una nozione diversa, ciò che chiamo un oggetto di trasferimento dati . Da allora hanno cambiato il loro utilizzo e usano invece il termine Transfer Object .

Puoi trovare altro materiale valido sugli oggetti di valore sul wiki e da Dirk Riehle .

Oggetto di trasferimento dati

Data Transfer Object o DTO è un modello (anti) introdotto con EJB. Invece di eseguire molte chiamate remote su EJB, l'idea era di incapsulare i dati in un oggetto valore che potesse essere trasferito sulla rete: un oggetto di trasferimento dati. Wikipedia ha una definizione decente di Data Transfer Object :

Il Data Transfer Object (DTO), precedentemente noto come oggetti valore o VO, è un modello di progettazione utilizzato per trasferire dati tra sottosistemi di applicazioni software. I DTO vengono spesso utilizzati insieme agli oggetti di accesso ai dati per recuperare i dati da un database.

La differenza tra oggetti di trasferimento dati e oggetti business o oggetti di accesso ai dati è che un DTO non ha alcun comportamento tranne che per l'archiviazione e il recupero dei propri dati (accessori e mutatori).

In un'architettura EJB tradizionale, i DTO hanno due scopi: in primo luogo, aggirano il problema che i bean di entità non sono serializzabili; in secondo luogo, definiscono implicitamente una fase di assemblaggio in cui tutti i dati da utilizzare dalla vista vengono recuperati e sottoposti a marshalling nei DTO prima di restituire il controllo al livello di presentazione.


Quindi, per molte persone, DTO e VO sono la stessa cosa (ma Fowler usa i VO per significare qualcos'altro che abbiamo visto). Il più delle volte seguono le convenzioni JavaBeans e sono quindi anche JavaBeans. E tutti sono POJO.


1
Quindi se ho una classe di convenienza creata solo per trasferire dati non correlati come questo class SomeClass { public String foo;public String bar; }all'interno di una classe con molta logica complicata, di sicuro non è un JavaBean, non può essere un VO in quanto è mutabile, potrebbe essere un DTO? tuttavia non è destinato a invocazioni remote di alcun tipo. Può essere considerato un POJO?
Jaime Hablutzel,

3
@ user2601512: sarebbe ancora un fagiolo. : P Non c'è niente di sbagliato nel fatto che un fagiolo abbia un comportamento - in effetti, è praticamente previsto. Se non fa nient'altro, è fondamentalmente un DTO.
cHao,

7
@xSNRG: in parte perché riduce gli oggetti in dati su cui agisce un altro codice. Questo è un passo indietro da una prospettiva OO, in cui gli oggetti agiscono e dovrebbero essere responsabili del proprio stato. I DTO sono occasionalmente una soluzione decente se in realtà stai solo trasferendo dati - da qui il nome - ma l'incapsulamento in pratica va fuori dalla finestra e in genere perdi qualsiasi garanzia di validità / coerenza che un oggetto reale potrebbe fornire.
cHao,

1
@KumaresanPerumal: puoi, se vuoi. Ma il modello è distinto dal livello dati e ha obiettivi e regole diversi. Il livello dati in genere richiede tutto ciò che è disposto e arbitrariamente impostabile, e il modello vuole idealmente nascondere i dati e imporre gli invarianti. Vuoi usare oggetti modello per l'archiviazione, dovrai scendere a compromessi da una parte o dall'altra.
cHao,

1
@KumaresanPerumal: il livello dati è lì per archiviare e recuperare i dati. Per fare ciò, ha quasi bisogno del pieno accesso a qualunque oggetto contenga i dati, dal momento che il recupero significa impostare valori in un oggetto da qualche parte. Ma il modello gestisce quei dati all'interno del sistema ed è vincolato dai principi di OO, come l'incapsulamento, l'idea che gli oggetti debbano mantenere il controllo sul loro stato interno e non avere altri codici che vanno in giro arbitrariamente con le loro viscere. I DTO possono colmare questa lacuna; il livello dati può accedervi a piacimento e il modello non deve rinunciare al controllo.
cHao,

66

DTO vs VO

DTO - Gli oggetti di trasferimento dati sono solo contenitori di dati che vengono utilizzati per trasportare dati tra livelli e livelli.

  • Contiene principalmente attributi. Puoi persino usare attributi pubblici senza getter e setter.
  • Gli oggetti di trasferimento dati non contengono alcuna logica aziendale.

Analogia:
modulo di registrazione semplice con attributi nome utente, password e ID e-mail.

  • Quando questo modulo viene inviato nel file RegistrationServlet, otterrai tutti gli attributi dal livello di visualizzazione al livello aziendale in cui passi gli attributi ai java bean e quindi al DAO o al livello di persistenza.
  • DTO aiuta a trasportare gli attributi dal livello di visualizzazione al livello aziendale e infine al livello di persistenza.

DTO è stato utilizzato principalmente per trasportare i dati in modo efficiente attraverso la rete, può essere persino da JVM a un'altra JVM.

I DTO sono spesso java.io.Serializable- al fine di trasferire dati attraverso JVM.

VO - A Value Object [1] [2] rappresenta se stesso un insieme fisso di dati ed è simile a un enum Java. L'identità di un oggetto valore si basa sul suo stato anziché sull'identità dell'oggetto ed è immutabile. Un esempio reale potrebbe essere Color.RED, Color.BLUE, SEX.FEMALE ecc.

POJO vs JavaBeans

[1] Il Java-Beanness di un POJO è che tutti i suoi attributi privati ​​sono accessibili tramite getter e setter pubblici conformi alle convenzioni JavaBeans. per esempio

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

[2] JavaBeans deve implementare Serializable e avere un costruttore senza argomenti, mentre in POJO non ha queste restrizioni.


Ci scusiamo per il commento in ritardo, ma sto imparando le differenze tra loro e ho una domanda. E se avessi una classe Java Bean, ma con altri metodi come doSomething (). Che tipo di classe sarebbe? Saluti
jscherman

@srinivas perché non possiamo trasmettere i dati nell'oggetto java DOMAIN o MODEL? Ma io uso MODELLO senza DTO. per favore spiegami brevemente. grazie
Kumaresan Perumal,

46

Fondamentalmente,

DTO: "Oggetti di trasferimento dati" possono spostarsi tra livelli separati nell'architettura software.

VO: "Oggetti valore" contengono un oggetto come Intero, Denaro ecc.

POJO: Plain Old Java Object che non è un oggetto speciale.

Fagioli Java: richiede Java Classdi essere serializzabile, avere un no-argcostruttore, un getter e setter per ogni campo


Queste descrizioni sono per lo più errate / incomplete.
cellepo

24

I bean Java non sono la stessa cosa degli EJB.

La specifica JavaBeans in Java 1.0 era il tentativo di Sun di consentire la manipolazione di oggetti Java in un IDE che sembrava VB. Esistono regole stabilite per oggetti qualificati come "Java Beans":

  1. Costruttore predefinito
  2. Getter e setter per i membri di dati privati ​​che hanno seguito la convenzione di denominazione corretta
  3. Serializable
  4. Forse altri che sto dimenticando.

I bean vennero più tardi. Combinano componenti distribuiti e un modello transazionale, in esecuzione in un contenitore che gestisce thread, pooling, ciclo di vita e fornisce servizi. Sono molto lontani dai fagioli di Java.

I DTO sono nati nel contesto Java perché le persone hanno scoperto che le specifiche EJB 1.0 erano troppo "chiacchierone" con il database. Invece di fare un viaggio di andata e ritorno per ogni elemento di dati, le persone li impacchetterebbero in Java Beans in blocco e li spedirebbero in giro.

I POJO sono stati una reazione contro gli EJB.


1
Ho sbagliato e ho preferito eliminare il mio messaggio. Grazie per la correzione. Voglio notare che il significato di POJO è cambiato qualche tempo fa. Innanzitutto, sono fatti solo di proprietà private e dei loro accessori. Ora consideriamo un POJO una classe con annotazioni, implementazione ed estensione di altre classi, ecc.
sinuhepop,

Che dire di VO, come è stata posta la domanda? Questa non è una risposta fino a quando non risponde all'intera domanda
cellepo,

4

POJO : è un file java (classe) che non estende o implementa nessun altro file java (classe).

Bean : è un file java (classe) in cui tutte le variabili sono private, i metodi sono pubblici e per accedere alle variabili vengono utilizzati getter e setter appropriati.

Classe normale : è un file java (classe) che può essere costituito da variabili pubbliche / private / predefinite / protette e che può o meno estendere o implementare un altro file java (classe).


Che dire di VO, come è stata posta la domanda? Questa non è una risposta fino a quando non risponde all'intera domanda
cellepo,

1

First Talk About

Classe normale - questo significa che qualsiasi classe definisce che è normalmente in Java, significa che crei un diverso tipo di proprietà del metodo, ecc.
Bean - Bean non è altro che è solo un oggetto di quella particolare classe usando questo bean puoi accedere alla tua classe java come oggetto. .

e dopo quel discorso sull'ultimo POJO

POJO - POJO è quella classe che non ha alcun servizio, ha solo un costruttore predefinito e proprietà privata e quelle proprietà per impostare un valore corrispondente metodi setter e getter. È una forma abbreviata di Plain Java Object.


Che dire di VO, come è stata posta la domanda? Questa non è una risposta fino a quando non risponde all'intera domanda
cellepo,

1
  • Valore oggetto : utilizzare quando è necessario misurare l'uguaglianza degli oggetti in base al valore degli oggetti.
  • Oggetto di trasferimento dati : passa i dati con più attributi in un colpo dal client al server attraverso il layer, per evitare più chiamate al server remoto.
  • Plain Old Java Object : è come una semplice classe quali proprietà, costruttore pubblico no-arg. Come dichiariamo per l'entità JPA.

differenza-tra-value-oggetto-pattern-e-data-transfer-pattern

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.