Differenza tra DTO, VO, POJO, JavaBeans?

Ho visto alcune domande simili:

  • Qual è la differenza tra un JavaBean e un POJO?
  • Qual è la differenza tra POJO (Plain Old Java Object) e DTO (Data Transfer Object)?

Puoi dirmi anche quali sono i contesti in cui vengono utilizzati? O lo scopo di loro?

    JavaBeans

    Un JavaBean è una class che segue le convenzioni JavaBeans definite da Sun. Wikipedia ha una buona sintesi di cosa sono i JavaBeans :

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

    Per funzionare come una class JavaBean, una class di oggetti deve rispettare certe convenzioni sulla denominazione, costruzione e comportamento del metodo. Queste convenzioni rendono ansible avere strumenti che possono utilizzare, riutilizzare, sostituire e connettere JavaBeans.

    Le convenzioni richieste sono:

    • La class deve avere un costruttore pubblico predefinito. Ciò consente una facile istanziazione all’interno dei framework di modifica e triggerszione.
    • Le proprietà della class devono essere accessibili utilizzando get, set e altri metodi (i cosiddetti metodi accessor e i metodi mutator), seguendo una convenzione di denominazione standard. Ciò consente una facile ispezione e aggiornamento automatici dello stato dei bean all’interno dei framework, molti dei quali includono editor personalizzati per vari tipi di proprietà.
    • La class dovrebbe essere serializzabile. Ciò consente alle applicazioni e ai framework di salvare, memorizzare 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 piuttosto che implementando interfacce, alcuni sviluppatori visualizzano JavaBeans come Plain Old Java Objects che seguono convenzioni di denominazione specifiche.

    POJO

    Un object Plain Old Java o POJO è un termine inizialmente introdotto per designare un semplice object Java leggero, non implementando alcuna interfaccia javax.ejb , al contrario di EJB 2.x (in particolare Fagioli Entità, Fagioli Sesse Stateless non sono IMO male) . Oggi, il termine è usato per qualsiasi object semplice senza cose extra. Ancora una volta, Wikipedia fa un buon lavoro nel definire POJO :

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

    “Ci siamo chiesti perché la gente fosse così contraria all’utilizzo di oggetti regolari nei loro sistemi e ha concluso che era perché gli oggetti semplici non avevano un nome di fantasia, quindi li abbiamo dati uno, ed è stato catturato molto bene”.

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

    È probabile che il termine abbia ottenuto un’accettazione diffusa a causa della necessità di un termine comune e facilmente comprensibile che contrasti con le strutture di oggetti complicate. 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 class ma un intero modello di componente (anche in questo caso, EJB 3 riduce la complessità di Enterprise JavaBeans).

    Poiché i progetti che utilizzano POJO sono diventati più comunemente usati, sono sorti dei sistemi che forniscono 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.

    Oggetto di valore

    Un object valore o VO è un object come java.lang.Integer che contiene valori (quindi oggetti valore). Per una definizione più formale, faccio spesso riferimento alla descrizione di Martin Fowler dell’object valore :

    In Patterns of Enterprise Application Architecture ho descritto Value Object come un object di piccole dimensioni come un object Money o un intervallo di date. La loro proprietà chiave è che seguono la semantica del valore piuttosto che la semantica di riferimento.

    Di solito puoi dire loro perché la loro nozione di uguaglianza non è basata sull’id quadro, 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 testare l’uguaglianza.

    Un’euristica generale è che gli oggetti valore dovrebbero essere interamente immutabili. Se si desidera modificare un object valore, è necessario sostituire l’object con uno nuovo e non consentire l’aggiornamento dei valori dell’object valore stesso – gli oggetti valore aggiornabili causano problemi di aliasing.

    La prima letteratura J2EE usava il termine object valore per descrivere una nozione diversa, ciò che io chiamo un object di trasferimento dati . Da allora hanno cambiato il loro utilizzo e usano invece il termine Oggetto di trasferimento .

    Puoi trovare materiale più buono sugli oggetti value sul wiki e da Dirk Riehle .

    Oggetto di trasferimento dati

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

    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 per la memorizzazione e il recupero dei propri dati (accessori e mutatori).

    In un’architettura EJB tradizionale, le DTO servono a due scopi: in primo luogo, aggirano il problema che i bean di quadro non sono serializzabili; in secondo luogo, implicitamente definiscono una fase di assemblaggio in cui tutti i dati da utilizzare dalla vista vengono recuperati e inseriti nel 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 indicare qualcos’altro come abbiamo visto). La maggior parte del tempo, seguono le convenzioni JavaBeans e sono quindi anche JavaBeans. E tutti sono POJO.

    DTO vs VO

    DTO – Gli oggetti di trasferimento dati sono solo contenitori di dati che vengono utilizzati per trasportare i 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 ed e-mail.

    • Quando questo modulo viene inviato nel file RegistrationServlet, si ottengono tutti gli attributi dal livello vista al livello aziendale in cui si passano gli attributi ai bean java e quindi al DAO o al livello di persistenza.
    • Le DTO aiutano a trasportare gli attributi dal livello vista al livello aziendale e infine al livello di persistenza.

    Il DTO è stato principalmente utilizzato per ottenere dati trasportati attraverso la rete in modo efficiente, potrebbe anche passare da JVM a un’altra JVM.

    I DTO sono spesso java.io.Serializable – per trasferire i dati su JVM.

    VO – A Value Object [1] [2] rappresenta esso stesso un set fisso di dati ed è simile a un enum Java. L’identity framework di un object Value si basa sul loro stato piuttosto che sull’identity framework dell’object ed è immutabile. Un esempio reale sarebbe Color.RED, Color.BLUE, SEX.FEMALE ecc.

    POJO vs JavaBeans

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

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

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

    Fondamentalmente,

    DTO: “Gli oggetti di trasferimento dati” possono viaggiare tra livelli separati nell’architettura software.

    VO: “Oggetti valore” contengono un object come Integer, Money ecc.

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

    Java Beans: richiede una Java Class per essere serializzabile, avere un costruttore no-arg e un getter and setter per ogni campo

    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 degli oggetti Java in un IDE simile a VB. C’erano regole stabilite per oggetti qualificati come “Java Beans”:

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

    Gli EJB sono arrivati ​​dopo. Combinano componenti distribuiti e un modello transazionale, in esecuzione in un contenitore che gestisce i thread, il pool, il ciclo di vita e fornisce servizi. Sono ben lontani da Java Beans.

    Le DTO sono nate nel contesto Java perché le persone hanno scoperto che la specifica EJB 1.0 era troppo “chiacchierona” con il database. Piuttosto che fare un viaggio di andata e ritorno per ogni elemento di dati, le persone le impacchetterebbero in grani Java e le spedirebbero in giro.

    I POJO erano una reazione contro gli EJB.

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

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

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

    Prima parla di

    Classe normale : ciò significa che qualsiasi class definisce che è normalmente in java significa che si creano diversi tipi di proprietà del metodo, ecc.
    Bean – Bean è niente è solo un object di quella particolare class che usa questo bean puoi accedere alla tua class java come a un object. .

    e dopo parleremo dell’ultimo POJO

    POJOPOJO è quella class che non ha alcun servizio ha solo un costruttore predefinito e una proprietà privata e quelle proprietà per l’impostazione di un valore setter e metodi getter corrispondenti. È una forma abbreviata di Plain Java Object.

    tl; dr

    tavolo meme

    due immagini hanno spiegato tutto: