Che cos'è esattamente un JavaBean?

Ho capito, penso, che un "Bean" è una classe Java con proprietà e getter / setter. Per quanto ho capito, è l'equivalente di una struttura C. È vero?

Inoltre, c'è una vera differenza sintattica tra un bean e una classe normale? Esiste una definizione speciale o un'interfaccia?

Fondamentalmente, perché esiste un termine per questo?

Cosa significa anche l' Serializableinterfaccia?

Un JavaBean è solo uno standard

1. Tutte le proprietà private (usare getter / setter )
2. Un costruttore pubblico senza argomenti
3. Implementa Serializable.

Questo è tutto. È solo una convention. Molte librerie dipendono da questo però.

Per quanto riguarda Serializable, dalla documentazione API :

La serializzazione di una classe è abilitata dalla classe che implementa l'interfaccia java.io.Serializable. Le classi che non implementano questa interfaccia non avranno il loro stato serializzato o deserializzato. Tutti i sottotipi di una classe serializzabile sono a loro volta serializzabili. L'interfaccia di serializzazione non ha metodi o campi e serve solo per identificare la semantica di essere serializzabile.

In altre parole, gli oggetti serializzabili possono essere scritti su flussi, e quindi file, database di oggetti, qualsiasi cosa.

Inoltre, non esiste alcuna differenza sintattica tra un JavaBean e un'altra classe: una classe è un JavaBean se segue gli standard.

Esiste un termine perché lo standard consente alle biblioteche di fare programmaticamente cose con istanze di classe definite in modo predefinito. Ad esempio, se una libreria vuole trasmettere in streaming qualsiasi oggetto che vi passa, sa che può farlo perché l'oggetto è serializzabile (supponendo che la lib richieda che gli oggetti siano JavaBeans corretti).

C'è un termine per farlo sembrare speciale. La realtà non è affatto così misteriosa.

In sostanza, un "fagiolo":

• è un oggetto serializzabile (cioè implementa java.io.Serializablee lo fa correttamente), quello
• ha "proprietà" i cui getter e setter sono solo metodi con determinati nomi (come, diciamo, getFoo()è il getter per la proprietà "Foo"), e
• ha un costruttore pubblico 0-arg (quindi può essere creato a piacere e configurato impostando le sue proprietà).

Aggiornare:

Per quanto riguarda Serializable: Questa non è altro che una "interfaccia marker" (un'interfaccia che non dichiara alcuna funzione) che dice a Java che la classe di implementazione consente (e implica che è in grado di) "serializzazione" - un processo che converte un'istanza in un flusso di byte. Tali byte possono essere archiviati in file, inviati tramite una connessione di rete, ecc. E dispongono di informazioni sufficienti per consentire a una JVM (almeno uno che conosce il tipo di oggetto) di ricostruire l'oggetto in un secondo momento, possibilmente in una diversa istanza del applicazione, o anche su un'intera altra macchina!

Naturalmente, per farlo, la classe deve attenersi a determinate limitazioni. Il principale tra questi è che tutti i campi di istanza devono essere tipi primitivi (int, bool, ecc.), Istanze di qualche classe che è anche serializzabile o contrassegnate in transientmodo tale che Java non tenti di includerle. (Questo ovviamente significa che i transientcampi non sopravviveranno al viaggio su un flusso. Una classe che ha transientcampi dovrebbe essere pronta a reinizializzarli se necessario.)

Una classe che non può rispettare queste limitazioni non dovrebbe essere implementata Serializable(e, IIRC, il compilatore Java non glielo lascerà nemmeno fare).

JavaBeans sono classi Java che aderiscono a una convenzione di codifica estremamente semplice. Tutto quello che devi fare è farlo

1. implementa java.io.Serializableinterfaccia - per salvare lo stato di un oggetto
2. usa un costruttore di argomenti pubblico vuoto - per creare un'istanza dell'oggetto
3. fornire metodi getter / setter pubblici - per ottenere e impostare i valori delle variabili private (proprietà).

Proprietà di JavaBeans

Un JavaBean è un oggetto Java che soddisfa determinate convenzioni di programmazione:

1. La classe JavaBean deve implementare Serializableo Externalizable

2. La classe JavaBean deve avere un costruttore no-arg

3. Tutte le proprietà JavaBean devono avere metodi setter e getter pubblici

4. Tutte le variabili di istanza JavaBean devono essere private

Esempio di JavaBeans

@Entity
public class Employee implements Serializable{

   @Id
   private int id;
   private String name;   
   private int salary;  

   public Employee() {}

   public Employee(String name, int salary) {
      this.name = name;
      this.salary = salary;
   }
   public int getId() {
      return id;
   }
   public void setId( int id ) {
      this.id = id;
   }
   public String getName() {
      return name;
   }
   public void setName( String name ) {
      this.name = name;
   }
   public int getSalary() {
      return salary;
   }
   public void setSalary( int salary ) {
      this.salary = salary;
   }
}

Spiegazione con un esempio.

1. import java.io.Serializable

Per quanto riguarda la serializzazione, consultare la documentazione .

2. campi privati

I campi devono essere privati ​​per impedire alle classi esterne di modificarli facilmente. Invece di accedere direttamente a questi campi, vengono utilizzati solitamente metodi getter / setter.

3. Costruttore

Un costruttore pubblico senza alcun argomento.

4. getter / setter

Metodi getter e setter per l'accesso e la modifica di campi privati.

/** 1. import java.io.Serializable */
public class User implements java.io.Serializable {
    /** 2. private fields */
    private int id;
    private String name;

    /** 3. Constructor */
    public User() {
    }
    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    /** 4. getter/setter */
    // getter
    public int getId() {
        return id;
    }
    public String getName() {
        return name;
    }
    // setter
    public void setId(int id) {
        this.id = id;
    }
    public void setName(String name) {
        this.name = name;
    }
}

I bean Java utilizzano meno codice e più approccio al lavoro ... I bean Java vengono utilizzati in Java EE come contratto universale per il rilevamento e l'accesso al runtime. Ad esempio, JavaServer Pages (JSP) utilizza Java Beans come oggetti di trasferimento dati tra pagine o tra servlet e JSP. JavaBeans Activation Framework di Java EE utilizza Java Beans per integrare il supporto per i tipi di dati MIME in Java EE. L'API di gestione Java EE utilizza JavaBeans come base per la strumentazione delle risorse da gestire in un ambiente Java EE.

Informazioni sulla serializzazione:

Nella serializzazione degli oggetti un oggetto può essere rappresentato come una sequenza di byte che include i dati dell'oggetto, nonché informazioni sul tipo di oggetto e sui tipi di dati memorizzati nell'oggetto.

Dopo che un oggetto serializzato è stato scritto in un file, può essere letto dal file e deserializzato, ovvero le informazioni sul tipo e i byte che rappresentano l'oggetto e i suoi dati possono essere utilizzati per ricreare l'oggetto in memoria.

La serializzazione sarà utile quando si distribuisce il progetto su più server poiché i bean verranno mantenuti e trasferiti su di essi.

Java Beans è uno standard e i suoi requisiti di sintassi di base sono stati chiaramente spiegati dalle altre risposte.

Tuttavia, IMO, è più di un semplice standard di sintassi. Il vero significato o utilizzo previsto di Java Beans è, insieme a vari strumenti supportati attorno allo standard, per facilitare il riutilizzo del codice e l'ingegneria del software basata su componenti, ovvero consentire agli sviluppatori di creare applicazioni assemblando componenti (classi) esistenti e senza dover scrivere alcun codice (o devi solo scrivere un piccolo codice di colla). Sfortunatamente questa tecnologia è molto sottovalutata e sottoutilizzata dall'industria, cosa che può essere raccontata dalle risposte in questo thread.

Se leggi il tutorial di Oracle su Java Beans , puoi comprenderlo meglio.

Secondo Wikipedia:

1. La classe deve avere un costruttore predefinito pubblico (senza argomenti). Ciò consente una facile istanza all'interno di framework di modifica e attivazione.

2. Le proprietà della classe devono essere accessibili usando get, set, is (può essere usato per proprietà booleane anziché get) e altri metodi (i cosiddetti metodi di accesso e metodi di mutatore) secondo 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à. I setter possono avere uno o più argomenti.

3. La classe dovrebbe essere serializzabile. [Ciò consente ad applicazioni e framework di salvare, archiviare e ripristinare in modo affidabile lo stato del bean in modo indipendente dalla VM e dalla piattaforma.]

Per maggiori informazioni segui questo link.

Per quanto riguarda la seconda parte della domanda, la serializzazione è un meccanismo di persistenza utilizzato per archiviare gli oggetti come una sequenza di byte firmati. In termini meno formali, memorizza lo stato di un oggetto in modo da poterlo recuperare in un secondo momento tramite la deserializzazione.

Un Java Bean è una classe java [concettuale] che dovrebbe seguire le seguenti convenzioni:

1. Dovrebbe avere un costruttore no-arg.
2. Dovrebbe essere serializzabile.
3. Dovrebbe fornire metodi per impostare e ottenere i valori delle proprietà, noti come metodi getter e setter.

È un componente software riutilizzabile. Può incapsulare più oggetti in un unico oggetto in modo che sia possibile accedere allo stesso oggetto da più posizioni ed è un passo verso una facile manutenzione del codice.

Sono serializzabili, hanno un costruttore a argomento zero e consentono l'accesso alle proprietà usando i metodi getter e setter. Il nome "Bean" è stato dato per comprendere questo standard, che mira a creare componenti software riutilizzabili per Java. according to wiki

Gli oggetti che formano la struttura portante della tua applicazione e che sono gestiti dal contenitore Spring IoC sono chiamati bean. Un bean è un oggetto che viene istanziato, assemblato e altrimenti gestito da un contenitore Spring IoC. Altrimenti, un bean è semplicemente uno dei tanti oggetti nella tua applicazione. according to primavera io .

Solo un piccolo background / aggiornamento sul concetto di bean. Molte altre risposte hanno effettivamente il cosa, ma non tanto il perché di loro.

Sono stati inventati all'inizio in Java come parte della costruzione di GUI. Hanno seguito modelli facili da separare per gli strumenti, consentendo loro di creare un pannello delle proprietà in modo da poter modificare gli attributi del bean. In generale, le proprietà Bean rappresentavano un controllo sullo schermo (Pensa x, y, larghezza, altezza, testo, ..)

Puoi anche pensarlo come una struttura di dati fortemente tipizzata.

Nel tempo questi sono diventati utili per molti strumenti che utilizzavano lo stesso tipo di accesso (ad esempio, Hibernate per mantenere le strutture di dati nel database)

Man mano che gli strumenti si evolvono, si spostarono maggiormente verso le annotazioni e si allontanarono dal separare i nomi di setter / getter. Ora la maggior parte dei sistemi non richiede bean, possono prendere qualsiasi vecchio oggetto Java semplice con proprietà annotate per dire loro come manipolarli.

Ora vedo i bean come sfere di proprietà annotate: sono davvero utili solo per le annotazioni che portano.

I fagioli stessi non sono un modello sano. Distruggono l'incapsulamento per loro natura poiché espongono tutte le loro proprietà alla manipolazione esterna e man mano che vengono utilizzati c'è la tendenza (non è assolutamente necessario) creare codice per manipolare il bean esternamente invece di creare codice all'interno del bean (viola "don chiedi a un oggetto i suoi valori, chiedi a un oggetto di fare qualcosa per te "). L'uso di pojo annotati con getter minimi e senza setter è molto più OO che ripristina l'incapsulamento e con la possibilità di immutabilità.

A proposito, mentre accadevano tutte queste cose qualcuno ha esteso il concetto a qualcosa chiamato Enterprise Java Beans. Questi sono ... diversi. e sono abbastanza complicati che molte persone sentono di non aver compreso l'intero concetto di fagiolo e hanno smesso di usare il termine. Questo è, penso, il motivo per cui generalmente ascolti i fagioli chiamati POJO (poiché ogni oggetto java è un POJO, questo è tecnicamente OK, ma quando senti qualcuno dire POJO, spesso pensano a qualcosa che segue il modello del bean)

Un bean Java è qualsiasi classe java che soddisfa i seguenti tre criteri:

1. Dovrebbe implementare un'interfaccia serializzabile (un'interfaccia Marker).
2. Il costruttore dovrebbe essere pubblico e non avere argomenti (quello che gli altri chiamano "costruttore no-arg").
3. Dovrebbe avere getter e setter.

È bene notare che il campo serialVersionUID è importante per mantenere lo stato dell'oggetto. Il codice seguente si qualifica come bean:

public class DataDog implements java.io.Serializable {

private static final long serialVersionUID = -3774654564564563L;

private int id;
private String nameOfDog;

//The constructor should NOT have arguments
public DataDog () {}


/** 4. getter/setter */

// getter(s)
public int getId() {
    return id;
}
public String getNameOfDog() {
    return nameOfDog;
}
// setter(s)
public void setId(int id) {
    this.id = id;
}
public void setNameOfDog(String nameOfDog) {
    this.nameOfDog = nameOfDog;
}}

Per capire JavaBean è necessario notare quanto segue: JavaBean è una cosa concettuale e non può rappresentare una classe di cose specifiche

JavaBean è uno strumento di sviluppo che può essere visualizzato nel funzionamento di componenti software riutilizzabili

JavaBean si basa sulla specifica Sun JavaBeans e può essere un componente riutilizzabile. La sua più grande caratteristica è la riutilizzabilità.

Un bean è una classe Java con nomi di metodi che seguono le linee guida Java Bean (chiamate anche modelli di progettazione) per proprietà , metodi ed eventi. Pertanto, qualsiasi metodo pubblico della classe bean che non fa parte della definizione di una proprietà è un metodo bean. Al minimo, una classe Java anche con una proprietà come unico membro (ovviamente, accompagnando il getter pubblico e il setter richiesti), un metodo pubblico come unico membro o solo un metodo di registrazione del listener di eventi pubblici è un bean Java. Inoltre, la proprietà può essere di sola lettura (ha un metodo getter ma nessun setter) o di sola scrittura (ha solo un metodo setter). Il bean Java deve essere una classe pubblica per essere visibile a qualsiasi strumento o contenitore beanbox. Il contenitore deve essere in grado di istanziarlo; quindi, deve avere anche un costruttore pubblico. La specifica JavaBeansnon richiede che un bean abbia un costruttore zero-args pubblico, esplicito o predefinito, per un contenitore per istanziarlo. Se è possibile fornire un file (con estensione .ser) contenente un'istanza serializzata, uno strumento beanbox può utilizzare quel file per creare un'istanza di un bean prototipo. Altrimenti, il bean deve avere un costruttore pubblico zero-args, esplicito o predefinito.

Una volta creata un'istanza del bean, l'API Java Bean (java.beans. *) Può introspettarlo e chiamarci metodi. Se non è disponibile alcuna classe che implementa l'interfaccia BeanInfo o l'estensione di un'implementazione di BeanInfo, la classe SimpleBeanInfo, l'introspezione comporta l'uso della riflessione (introspezione implicita) per studiare i metodi supportati da un bean di destinazione e quindi applicare modelli di progettazione semplici (linee guida) da cui dedurre quei metodi quali proprietà, eventi e metodi pubblici sono supportati. Se è disponibile una classe che implementa l'interfaccia BeanInfo (per un bean Foo, deve essere denominata FooBeanInfo), l'API ignora l'introspezione implicita e utilizza metodi pubblici (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) di questa classe per ottenere il informazione. Se è disponibile una classe che estende SimpleBeanInfo, a seconda di quale dei metodi pubblici SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) vengono sovrascritti, utilizzerà tali metodi per ottenere informazioni; per un metodo che non viene sostituito, verrà impostato automaticamente l'introspezione implicita corrispondente. Un bean deve comunque essere istanziato anche se non viene effettuata alcuna introspezione implicita. Pertanto, il requisito di un costruttore pubblico di zeri-args. Ma, naturalmente, l'interfaccia Serializable o Externalizable non è necessaria per essere riconosciuta. Tuttavia, la specifica Java Bean dice: "Vorremmo anche che fosse" banale "per il caso comune di un piccolo Bean che vuole semplicemente salvare il suo stato interno e non vuole pensarci". Pertanto, tutti i bean devono implementare l'interfaccia Serializable o Externalizable. Complessivamente, La specifica JavaBeans non è difficile e veloce su ciò che costituisce un bean. "Scrivere componenti JavaBeans è sorprendentemente facile. Non è necessario uno strumento speciale e non è necessario implementare alcuna interfaccia. Scrivere bean è semplicemente una questione di seguire determinate convenzioni di codifica. Tutto quello che devi fare è rendere la tua classe simile a un bean: gli strumenti che utilizzano i bean saranno in grado di riconoscere e utilizzare il bean. " In verità, anche la seguente classe è un Java Bean,

public class Trivial implements java.io.Serializable {}

Supponiamo che un costruttore di bean abbia alcuni parametri. Supponiamo che alcuni siano tipi semplici. Il contenitore potrebbe non sapere quali valori assegnare loro; anche se lo fa, l'istanza risultante potrebbe non essere riutilizzabile. Può avere senso solo se l'utente può configurare (specificare i valori), ad esempio annotazioni o file di configurazione XML come nei bean Spring. Supponiamo che alcuni parametri siano tipi di classe o interfaccia. Ancora una volta, il contenitore potrebbe non sapere quali valori assegnare ad esso. Può avere senso solo se l'utente può configurare (specificare oggetti specifici) dicendo annotazioni o file di configurazione XML. Tuttavia, anche in primavera (tramite file di configurazione xml), l'assegnazione di oggetti specifici (con nomi di stringa) agli argomenti del costruttore (attributo o elemento degli argomenti del costruttore) non è un errore di battitura, è sostanzialmente come l'iniezione di risorse. Fare riferimenti ad altri bean Spring (chiamati collaboratori; tramite elemento in un elemento argomento del costruttore) è fondamentalmente l'iniezione di dipendenza e quindi la tipesa. Ovviamente, una dipendenza (bean collaboratore) potrebbe avere un costruttore con parametri iniettati; quelle dipendenze iniettate potrebbero avere un costruttore con parametri e così via. In questo scenario, in definitiva, occorrerebbero alcune classi di bean (ad esempio MyBean.class) che il contenitore può creare un'istanza semplicemente chiamando il nuovo MyBean () prima che possa costruire gli altri bean collaboranti tramite l'iniezione di dipendenza sui costruttori, quindi il requisito per i bean per avere un costruttore pubblico zero-args. Supponiamo che, se un contenitore non supporta l'iniezione di dipendenza e / o non consente l'assegnazione di valori di tipo semplice al costruttore tramite alcune annotazioni o file di configurazione XML come in Spring, i costruttori di bean non dovrebbero avere parametri. Anche un'applicazione Spring bean avrebbe bisogno di alcuni bean per avere un costruttore pubblico a zero-args (ad esempio, in uno scenario in cui l'applicazione Spring non ha bean con solo semplici tipi come argomenti del costruttore).

I bean gestiti JSF vengono eseguiti in un contenitore Web. Possono essere configurati con l'annotazione @ManagedBean o con un file di risorse della configurazione dell'applicazione gestito-bean.xml. Tuttavia, supporta solo l'iniezione tramite iniezione di risorse (non typesafe); non adatto per l'iniezione su costruttori. Le specifiche JSFrichiede che i bean gestiti debbano disporre di costruttori pubblici a argomento zero. Inoltre dice: “A partire dalla versione 2.3 di questa specifica, l'uso della funzione bean gestita come specificato in questa sezione è fortemente sconsigliato. Una soluzione migliore e integrata in modo più coerente per risolvere lo stesso problema consiste nell'utilizzare Contexts and Dependency Injection (CDI), come specificato in JSR-365. "In altre parole, utilizzare i bean gestiti CDI, che offre un'iniezione di dipendenza tipica su costruttori affini ai bean Spring. La specifica CDI adotta la specifica Managed Beans, che si applica a tutti i contenitori della piattaforma JEE, non solo al livello Web. Pertanto, il contenitore Web deve implementare la specifica CDI.

Ecco un estratto dalla specifica Managed Bean "I fagioli gestiti sono oggetti gestiti dal contenitore con requisiti minimi, altrimenti noti con l'acronimo" POJOs "(Plain Old Java Objects) ... possono essere visti come una versione potenziata della piattaforma Java EE del modello di componente JavaBeans trovato sulla piattaforma Java SE .... Il lettore non mancherà che Managed Beans ha un precursore nell'omonima struttura trovata nella tecnologia JSF (JavaServer Faces) ... I fagioli gestiti come definiti in questa specifica rappresentano una generalizzazione di quelli trovati in JSF; in particolare, Managed Beans può essere utilizzato ovunque in un'applicazione Java EE, non solo nei moduli web. Ad esempio, nel modello di componente di base, Managed Beans deve fornire un costruttore senza argomenti, ma una specifica che si basa su Managed Beans, come CDI (JSR-299), può rilassare tale requisito e consentire a Managed Beans di fornire ai costruttori firme più complesse, purché seguano alcune regole ben definite ... Un Managed Bean non deve essere: una classe finale, una classe astratta, una classe interna non statica . Un bean gestito potrebbe non essere serializzabile a differenza di un normale componente JavaBean. " Pertanto, la specifica di Managed Beans, altrimenti nota come POJOs o POJO bean, consente l'estensione come nel CDI.

La specifica CDI ridefinisce i bean gestiti come: Durante l'esecuzione in Java EE, una classe Java di livello superiore è un bean gestito se soddisfa i requisiti:

• Non è una classe interiore. • È una classe non astratta o è annotata @Decorator. • Non implementa javax.enterprise.inject.spi.Extension. • Non è annotato @Vetoed o in un pacchetto annotato @Vetoed. • Ha anche un costruttore appropriato: la classe ha un costruttore senza parametri, oppure la classe dichiara un costruttore annotato @Inject.

Tutte le classi Java che soddisfano queste condizioni sono bean gestiti e pertanto non è richiesta alcuna dichiarazione speciale per definire un bean gestito. O

se è definito come un bean gestito da qualsiasi altra specifica Java EE e se

• Non è annotato con un'annotazione che definisce i componenti EJB né dichiarato come classe bean EJB in ejb-jar.xml.

A differenza dei bean Spring, non supporta i costruttori con tipi semplici, il che potrebbe essere possibile se supportasse la configurazione con file di configurazione XML come in Spring o eventuali annotazioni.

Gli EJB vengono eseguiti in un contenitore EJB. Le sue specifichedice: "Un componente bean di sessione è un bean gestito." "La classe deve avere un costruttore pubblico che non accetta argomenti", afferma sia per il bean di sessione che per il bean basato sui messaggi. Inoltre, dice: "La classe del bean di sessione è non è richiesto per implementare l'interfaccia SessionBean o l'interfaccia Serializable. " Per lo stesso motivo dei bean JSF, che l'iniezione di dipendenza EJB3 è fondamentalmente l'iniezione di risorse, i bean JSF non supportano i costruttori con argomenti, ovvero tramite l'iniezione di dipendenza. Tuttavia, se il contenitore EJB implementa CDI, "Opzionalmente: la classe può avere un costruttore aggiuntivo annotato con l'annotazione Inject, "indica sia il bean di sessione che il bean basato sui messaggi perché," un bean impacchettato in un archivio bean CDI e non annotato con javax.enterprise.inject.Vetoed annotation, è considerato abilitato per CDI fagiolo."

In pratica, i fagioli sono solo oggetti che sono utili da usare. Serializzarli significa poterli perseverare facilmente (conservare in una forma facilmente recuperabile).

Usi tipici dei fagioli nel mondo reale:

• oggetti riutilizzabili semplici POJO (Plain Old Java Objects)
• oggetti visivi
• Spring utilizza Beans per gli oggetti da gestire (ad esempio, l'oggetto Utente che deve essere serializzato in sessione)
• EJB (Enterprise Java Beans), oggetti più complessi, come JSF Beans (JSF è una tecnologia piuttosto obsoleta) o JSP Beans

Quindi, in effetti, i bean sono solo una convenzione / standard che si aspettano qualcosa da un oggetto Java che si comporterebbe (serializzazione) e darebbe dei modi per cambiarlo (setter per proprietà) in un certo modo.

Come usarli, è solo una tua invenzione, ma i casi più comuni che ho elencato sopra.