Was genau ist eine JavaBean?

Ich habe verstanden, denke ich, dass eine "Bean" eine Java-Klasse mit Eigenschaften und Getter / Setter ist. Soweit ich weiß, entspricht es einer C-Struktur. Ist das wahr?

Gibt es auch einen echten syntaktischen Unterschied zwischen einer Bean und einer regulären Klasse? Gibt es eine spezielle Definition oder eine Schnittstelle?

Warum gibt es dafür einen Begriff?

Was bedeutet die SerializableSchnittstelle auch?

Eine JavaBean ist nur ein Standard

1. Alle Eigenschaften privat ( Getter / Setter verwenden )
2. Ein öffentlicher Konstruktor ohne Argumente
3. Geräte Serializable.

Das ist es. Es ist nur eine Konvention. Viele Bibliotheken hängen jedoch davon ab.

In Bezug auf Serializableaus der API-Dokumentation :

Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die die Schnittstelle java.io.Serializable implementiert. Klassen, die diese Schnittstelle nicht implementieren, haben keinen ihrer Zustände serialisiert oder deserialisiert. Alle Subtypen einer serialisierbaren Klasse sind selbst serialisierbar. Die Serialisierungsschnittstelle hat keine Methoden oder Felder und dient nur dazu, die Semantik der Serialisierbarkeit zu identifizieren.

Mit anderen Worten, serialisierbare Objekte können in Streams und damit in Dateien, Objektdatenbanken usw. geschrieben werden.

Es gibt auch keinen syntaktischen Unterschied zwischen einer JavaBean und einer anderen Klasse - eine Klasse ist eine JavaBean, wenn sie den Standards folgt.

Es gibt einen Begriff dafür, weil der Standard es Bibliotheken ermöglicht, programmgesteuert Dinge mit Klasseninstanzen zu tun, die Sie auf vordefinierte Weise definieren. Wenn eine Bibliothek beispielsweise ein Objekt streamen möchte, das Sie an sie übergeben, weiß sie, dass dies möglich ist, da Ihr Objekt serialisierbar ist (vorausgesetzt, die Bibliothek erfordert, dass Ihre Objekte ordnungsgemäße JavaBeans sind).

Es gibt einen Begriff dafür, dass es besonders klingt. Die Realität ist bei weitem nicht so mysteriös.

Grundsätzlich eine "Bohne":

• ist ein serialisierbares Objekt (das heißt, es implementiert java.io.Serializableund tut dies korrekt), das
• hat "Eigenschaften", deren Getter und Setter nur Methoden mit bestimmten Namen sind (wie zum Beispiel getFoo()der Getter für die "Foo" -Eigenschaft), und
• hat einen öffentlichen 0-arg-Konstruktor (so kann er nach Belieben erstellt und durch Festlegen seiner Eigenschaften konfiguriert werden).

Aktualisieren:

Wie für Serializable: Das ist nichts anderes als eine "Marker-Schnittstelle" (eine Schnittstelle, die keine Funktionen deklariert), die Java mitteilt, dass die implementierende Klasse der "Serialisierung" zustimmt (und impliziert, dass sie dazu in der Lage ist) - einem Prozess, der konvertiert eine Instanz in einen Strom von Bytes. Diese Bytes können in Dateien gespeichert, über eine Netzwerkverbindung usw. gesendet werden und verfügen über genügend Informationen, damit eine JVM (zumindest eine, die den Objekttyp kennt) das Objekt später rekonstruieren kann - möglicherweise in einer anderen Instanz der Anwendung oder sogar auf einer ganz anderen Maschine!

Dazu muss sich die Klasse natürlich an bestimmte Einschränkungen halten. Das Wichtigste unter ihnen ist, dass alle Instanzfelder entweder primitive Typen (int, bool usw.) sein müssen, Instanzen einer Klasse, die ebenfalls serialisierbar ist, oder als solche gekennzeichnet sein müssen, transientdamit Java nicht versucht, sie einzuschließen. (Dies bedeutet natürlich, dass transientFelder die Reise über einen Stream nicht überleben. Eine Klasse mit transientFeldern sollte darauf vorbereitet sein, diese bei Bedarf neu zu initialisieren.)

Eine Klasse, die diese Einschränkungen nicht einhalten kann, sollte nicht implementiert werden Serializable(und IIRC, der Java-Compiler lässt dies nicht einmal zu .)

JavaBeans sind Java-Klassen, die einer extrem einfachen Codierungskonvention entsprechen. Alles was Sie tun müssen, ist zu

1. java.io.SerializableSchnittstelle implementieren - um den Status eines Objekts zu speichern
2. Verwenden Sie einen öffentlichen Konstruktor für leere Argumente, um das Objekt zu instanziieren
3. Bereitstellung öffentlicher Getter / Setter-Methoden - zum Abrufen und Festlegen der Werte privater Variablen (Eigenschaften).

Eigenschaften von JavaBeans

Eine JavaBean ist ein Java-Objekt, das bestimmte Programmierkonventionen erfüllt:

1. Die JavaBean-Klasse muss entweder Serializableoder implementierenExternalizable

2. Die JavaBean-Klasse muss einen Konstruktor ohne Argumente haben

3. Alle JavaBean-Eigenschaften müssen über öffentliche Setter- und Getter-Methoden verfügen

4. Alle JavaBean-Instanzvariablen sollten privat sein

Beispiel für 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;
   }
}

Erklärung mit einem Beispiel.

1. Importieren Sie java.io.Serializable

Informationen zur Serialisierung finden Sie in der Dokumentation .

2. private Felder

Felder sollten privat sein, um zu verhindern, dass äußere Klassen diese Felder leicht ändern können. Anstatt direkt auf diese Felder zuzugreifen, werden normalerweise Getter / Setter-Methoden verwendet.

3. Konstruktor

Ein öffentlicher Konstruktor ohne Argument.

4. Getter / Setter

Getter- und Setter-Methoden für den Zugriff auf und das Ändern von privaten Feldern.

/** 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;
    }
}

Java Beans werden für weniger Code und mehr Arbeitsansatz verwendet ... Java Beans werden in Java EE als universeller Vertrag für die Laufzeiterkennung und den Zugriff verwendet. Beispielsweise verwendet JavaServer Pages (JSP) Java Beans als Datenübertragungsobjekte zwischen Seiten oder zwischen Servlets und JSPs. Das JavaBeans Activation Framework von Java EE verwendet Java Beans, um die Unterstützung für MIME-Datentypen in Java EE zu integrieren. Die Java EE-Verwaltungs-API verwendet JavaBeans als Grundlage für die Instrumentierung von Ressourcen, die in einer Java EE-Umgebung verwaltet werden sollen.

Informationen zur Serialisierung:

Bei der Objektserialisierung kann ein Objekt als eine Folge von Bytes dargestellt werden, die die Daten des Objekts sowie Informationen über den Objekttyp und die im Objekt gespeicherten Datentypen enthält.

Nachdem ein serialisiertes Objekt in eine Datei geschrieben wurde, kann es aus der Datei gelesen und deserialisiert werden, dh die Typinformationen und Bytes, die das Objekt und seine Daten darstellen, können verwendet werden, um das Objekt im Speicher neu zu erstellen.

Die Serialisierung ist nützlich, wenn Sie Ihr Projekt auf mehreren Servern bereitstellen, da Beans beibehalten und auf diese übertragen werden.

Java Beans ist ein Standard, und seine grundlegenden Syntaxanforderungen wurden durch die anderen Antworten klar erklärt.

IMO ist jedoch mehr als ein einfacher Syntaxstandard. Die eigentliche Bedeutung oder beabsichtigte Verwendung von Java Beans besteht zusammen mit verschiedenen Tool-Unterstützungen rund um den Standard darin, die Wiederverwendung von Code und das komponentenbasierte Software-Engineering zu erleichtern, dh Entwicklern das Erstellen von Anwendungen zu ermöglichen, indem vorhandene Komponenten (Klassen) zusammengesetzt werden und keine geschrieben werden müssen Code (oder muss nur einen kleinen Klebercode schreiben). Leider wird diese Technologie von der Branche weit unterschätzt und nicht ausreichend genutzt, was aus den Antworten in diesem Thread hervorgeht.

Wenn Sie das Tutorial von Oracle zu Java Beans lesen , können Sie dies besser verstehen.

Laut Wikipedia:

1. Die Klasse muss einen öffentlichen Standardkonstruktor haben (ohne Argumente). Dies ermöglicht eine einfache Instanziierung innerhalb von Bearbeitungs- und Aktivierungsframeworks.

2. Auf die Klasseneigenschaften muss mit get, set, is (kann für boolesche Eigenschaften anstelle von get verwendet werden) und anderen Methoden (sogenannte Accessor-Methoden und Mutator-Methoden) gemäß einer Standard-Namenskonvention 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. Setter können ein oder mehrere Argumente haben.

3. Die Klasse sollte serialisierbar sein. [Auf diese Weise können Anwendungen und Frameworks den Status der Bean unabhängig von der VM und der Plattform zuverlässig speichern, speichern und wiederherstellen.]

Weitere Informationen finden Sie unter diesem Link.

In Bezug auf den zweiten Teil Ihrer Frage ist die Serialisierung ein Persistenzmechanismus, mit dem Objekte als Folge von vorzeichenbehafteten Bytes gespeichert werden. Weniger formal ausgedrückt, speichert es den Status eines Objekts, damit Sie es später durch De-Serialisierung abrufen können.

Eine Java Bean ist eine Java-Klasse [konzeptionell], die folgenden Konventionen folgen sollte:

1. Es sollte einen Konstruktor ohne Argumente haben.
2. Es sollte serialisierbar sein.
3. Es sollte Methoden zum Festlegen und Abrufen der Werte der Eigenschaften bereitstellen, die als Getter- und Setter-Methoden bezeichnet werden.

Es ist eine wiederverwendbare Softwarekomponente. Es kann viele Objekte in einem Objekt zusammenfassen, sodass von mehreren Stellen aus auf dasselbe Objekt zugegriffen werden kann, und ist ein Schritt in Richtung einer einfachen Wartung des Codes.

Sie sind serialisierbar, haben einen Konstruktor mit null Argumenten und ermöglichen den Zugriff auf Eigenschaften mithilfe von Getter- und Setter-Methoden. Der Name "Bean" wurde vergeben, um diesen Standard zu umfassen, der darauf abzielt, wiederverwendbare Softwarekomponenten für Java zu erstellen. according to Wiki

Die Objekte, die das Rückgrat Ihrer Anwendung bilden und vom Spring IoC-Container verwaltet werden, werden als Beans bezeichnet. Eine Bean ist ein Objekt, das von einem Spring IoC-Container instanziiert, zusammengestellt und anderweitig verwaltet wird. Andernfalls ist eine Bean einfach eines von vielen Objekten in Ihrer Anwendung. according to Frühling io .

Nur ein kleiner Hintergrund / Update zum Bean-Konzept. Viele andere Antworten haben tatsächlich das Was, aber nicht so sehr das Warum.

Sie wurden früh in Java als Teil der Erstellung von GUIs erfunden. Sie folgten Mustern, die für Werkzeuge leicht auseinander zu ziehen waren, sodass sie ein Eigenschaftenfenster erstellen konnten, in dem Sie die Attribute der Bean bearbeiten konnten. Im Allgemeinen stellten die Bean-Eigenschaften ein Steuerelement auf dem Bildschirm dar (Denken Sie an x, y, Breite, Höhe, Text usw.).

Sie können sich das auch als stark typisierte Datenstruktur vorstellen.

Im Laufe der Zeit wurden diese für viele Tools nützlich, die dieselbe Art von Zugriff verwendeten (z. B. Ruhezustand, um Datenstrukturen in der Datenbank beizubehalten).

Als sich die Werkzeuge weiterentwickelten, bewegten sie sich mehr in Richtung Anmerkungen und weg vom Herausziehen der Setter- / Getter-Namen. Jetzt benötigen die meisten Systeme keine Beans mehr. Sie können jedes einfache alte Java-Objekt mit kommentierten Eigenschaften verwenden, um zu erfahren, wie sie bearbeitet werden sollen.

Jetzt sehe ich Bohnen als kommentierte Eigenschaftsbälle - sie sind wirklich nur für die Anmerkungen nützlich, die sie tragen.

Bohnen selbst sind kein gesundes Muster. Sie zerstören die Kapselung von Natur aus, da sie alle ihre Eigenschaften einer externen Manipulation aussetzen. Bei ihrer Verwendung besteht die Tendenz (keineswegs erforderlich), Code zur externen Manipulation der Bean zu erstellen, anstatt Code innerhalb der Bean zu erstellen (verstößt gegen "don" Fragen Sie ein Objekt nicht nach seinen Werten, sondern ein Objekt, etwas für Sie zu tun "). Die Verwendung von kommentierten Pojos mit minimalen Getter und ohne Setter ist viel mehr OO, um die Kapselung wiederherzustellen und die Möglichkeit der Unveränderlichkeit.

Übrigens, als all diese Dinge passierten, erweiterte jemand das Konzept auf etwas, das als Enterprise Java Beans bezeichnet wurde. Diese sind ... anders. und sie sind so kompliziert, dass viele Menschen das Gefühl hatten, das gesamte Bean-Konzept nicht zu verstehen, und den Begriff nicht mehr verwendeten. Aus diesem Grund hören Sie im Allgemeinen Bohnen, die als POJOs bezeichnet werden (da jedes Java-Objekt ein POJO ist, ist dies technisch in Ordnung, aber wenn Sie jemanden POJO sagen hören, denken sie am häufigsten an etwas, das dem Bohnenmuster folgt.)

Eine Java Bean ist eine Java-Klasse, die die folgenden drei Kriterien erfüllt:

1. Es sollte eine serialisierbare Schnittstelle (A Marker-Schnittstelle) implementieren.
2. Der Konstruktor sollte öffentlich sein und keine Argumente haben (was andere Leute einen "Konstruktor ohne Argumente" nennen).
3. Es sollte Getter und Setter haben.

Gut zu beachten, dass das Feld serialVersionUID wichtig ist, um den Objektstatus aufrechtzuerhalten. Der folgende Code gilt als 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;
}}

Um JavaBean zu verstehen, müssen Sie Folgendes beachten: JavaBean ist ein konzeptionelles Element und kann keine Klasse bestimmter Dinge darstellen

JavaBean ist ein Entwicklungstool, das beim Betrieb wiederverwendbarer Softwarekomponenten visualisiert werden kann

JavaBean basiert auf der Sun JavaBeans-Spezifikation und kann wiederverwendbare Komponenten sein. Das größte Merkmal ist die Wiederverwendbarkeit.

Eine Bean ist eine Java-Klasse mit Methodennamen, die den Java Bean-Richtlinien (auch als Entwurfsmuster bezeichnet) für Eigenschaften , Methoden und Ereignisse folgen. Daher ist jede öffentliche Methode der Bean-Klasse, die nicht Teil einer Eigenschaftsdefinition ist, eine Bean-Methode. Eine Java-Klasse, auch wenn entweder eine Eigenschaft als einziges Mitglied vorhanden ist (natürlich ist ein öffentlicher Getter und Setter erforderlich), eine öffentliche Methode als einziges Mitglied oder nur eine Registrierungsmethode für öffentliche Ereignis-Listener eine Java-Bean ist. Darüber hinaus kann die Eigenschaft entweder eine schreibgeschützte Eigenschaft sein (hat eine Getter-Methode, aber keinen Setter) oder eine schreibgeschützte Eigenschaft (hat nur eine Setter-Methode). Die Java-Bean muss eine öffentliche Klasse sein, damit sie für jedes Beanbox-Tool oder -Container sichtbar ist. Der Container muss ihn instanziieren können. Daher muss es auch einen öffentlichen Konstruktor haben. Die JavaBeans-SpezifikationFür eine Bean ist kein expliziter oder standardmäßiger öffentlicher Null-Argument-Konstruktor erforderlich, damit ein Container ihn instanziieren kann. Wenn Sie eine Datei (mit der Erweiterung .ser) bereitstellen könnten, die eine serialisierte Instanz enthält, könnte ein Beanbox-Tool diese Datei verwenden, um eine Prototyp-Bean zu instanziieren. Andernfalls muss die Bean über einen öffentlichen Konstruktor mit null Argumenten verfügen, entweder explizit oder standardmäßig.

Sobald die Bean instanziiert ist, kann die Java Bean-API (java.beans. *) Sie überprüfen und Methoden darauf aufrufen. Wenn keine Klasse verfügbar ist, die die Schnittstelle BeanInfo implementiert oder eine BeanInfo-Implementierung, die SimpleBeanInfo-Klasse, erweitert, umfasst die Introspektion die Verwendung von Reflektion (implizite Introspektion), um die von einer Ziel-Bean unterstützten Methoden zu untersuchen und dann einfache Entwurfsmuster (die Richtlinien) anzuwenden, aus denen abgeleitet werden kann diese Methoden, welche Eigenschaften, Ereignisse und öffentlichen Methoden unterstützt werden. Wenn eine Klasse verfügbar ist, die die Schnittstelle BeanInfo implementiert (für eine Bean Foo muss sie FooBeanInfo heißen), umgeht die API die implizite Introspektion und verwendet öffentliche Methoden (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) dieser Klasse, um die zu erhalten Information. Wenn eine Klasse zur Erweiterung von SimpleBeanInfo verfügbar ist, Abhängig davon, welche der öffentlichen SimpleBeanInfo-Methoden (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) überschrieben werden, werden diese überschriebenen Methoden verwendet, um Informationen abzurufen. Für eine Methode, die nicht überschrieben wird, wird standardmäßig die entsprechende implizite Selbstbeobachtung verwendet. Eine Bohne muss ohnehin instanziiert werden, auch wenn keine implizite Selbstbeobachtung durchgeführt wird. Somit ist die Anforderung eines öffentlichen Zeri-Args-Konstruktors. Natürlich ist die Schnittstelle Serializable oder Externalizable nicht erforderlich, damit sie erkannt wird. In der Java Bean-Spezifikation heißt es jedoch: "Wir möchten auch, dass es für den häufigen Fall einer winzigen Bean, die einfach ihren internen Status speichern und nicht darüber nachdenken möchte," trivial "ist." Daher müssen alle Beans eine serialisierbare oder externisierbare Schnittstelle implementieren. Insgesamt, Die JavaBeans-Spezifikation ist nicht genau, was eine Bean ausmacht. "Das Schreiben von JavaBeans-Komponenten ist überraschend einfach. Sie benötigen kein spezielles Tool und müssen keine Schnittstellen implementieren. Beim Schreiben von Beans müssen Sie lediglich bestimmte Codierungskonventionen befolgen. Sie müssen lediglich Ihre Klasse so aussehen lassen, wie sie aussieht eine Bohne - Werkzeuge, die Beans verwenden, können Ihre Bohne erkennen und verwenden. " Trivialerweise ist sogar die folgende Klasse eine Java Bean,

public class Trivial implements java.io.Serializable {}

Angenommen, ein Bean-Konstruktor hat einige Parameter. Angenommen, einige sind einfache Typen. Der Container weiß möglicherweise nicht, welche Werte ihm zugewiesen werden sollen. Selbst wenn dies der Fall ist, kann die resultierende Instanz möglicherweise nicht wiederverwendet werden. Dies ist möglicherweise nur dann sinnvoll, wenn der Benutzer wie in Spring Beans beispielsweise Anmerkungen oder XML-Konfigurationsdateien konfigurieren (Werte angeben) kann. Angenommen, einige Parameter sind Klassen- oder Schnittstellentypen. Auch hier weiß der Container möglicherweise nicht, welche Werte ihm zugewiesen werden sollen. Dies ist möglicherweise nur dann sinnvoll, wenn der Benutzer bestimmte Objekte beispielsweise durch Anmerkungen oder XML-Konfigurationsdateien konfigurieren (angeben) kann. Selbst in Spring (über XML-Konfigurationsdateien) ist das Zuweisen bestimmter Objekte (mit Zeichenfolgennamen) zu Konstruktorargumenten (Attribut oder Element von Konstruktorargumenten) nicht typsicher, sondern im Grunde wie eine Ressourceninjektion. Das Verweisen auf andere Spring Beans (Collaborators genannt; via Element in einem Konstruktorargumentelement) ist im Grunde genommen eine Abhängigkeitsinjektion und somit typsicher. Offensichtlich kann eine Abhängigkeit (Collaborator Bean) einen Konstruktor mit injizierten Parametern haben. Diese injizierten Abhängigkeiten haben möglicherweise einen Konstruktor mit Parametern und so weiter. In diesem Szenario benötigen Sie letztendlich einige Bean-Klassen (z. B. MyBean.class), die der Container durch einfaches Aufrufen von new MyBean () instanziieren kann, bevor er die anderen zusammenarbeitenden Beans über die Abhängigkeitsinjektion von Konstruktoren erstellen kann - daher die Anforderung für Die Beans müssen einen öffentlichen Zero-Args-Konstruktor haben. Angenommen, ein Container unterstützt keine Abhängigkeitsinjektion und / oder erlaubt es nicht, dem Konstruktor über einige Anmerkungen oder XML-Konfigurationsdateien wie in Spring einfache Werte zuzuweisen. Bean-Konstruktoren sollten keine Parameter haben. Sogar eine Spring-Beans-Anwendung würde einige Beans benötigen, um einen öffentlichen Konstruktor mit null Argumenten zu haben (z. B. in einem Szenario, in dem Ihre Spring-Anwendung keine Bean mit nur einfachen Typen als Konstruktorargumente hat).

JSF-verwaltete Beans werden in einem Webcontainer ausgeführt. Sie können entweder mit der Annotation @ManagedBean oder mit einer Anwendungskonfigurationsressourcendatei manage-bean.xml konfiguriert werden. Es unterstützt jedoch die Injektion nur über die Ressourceninjektion (nicht typsicher). Nicht für die Injektion auf Konstruktoren geeignet. Die JSF-Spezifikationerfordert, dass verwaltete Beans einen öffentlichen Konstruktor mit null Argumenten haben müssen. Darüber hinaus heißt es: „Ab Version 2.3 dieser Spezifikation wird von der Verwendung der in diesem Abschnitt angegebenen verwalteten Bean-Funktion dringend abgeraten. Eine bessere und kohärentere integrierte Lösung zur Lösung des gleichen Problems ist die Verwendung von Contexts and Dependency Injection (CDI), wie in JSR-365 angegeben Die CDI-Spezifikation übernimmt die Managed Beans-Spezifikation, die für alle Container der JEE-Plattform gilt, nicht nur für die Webschicht. Daher muss der Webcontainer die CDI-Spezifikation implementieren.

Hier ist ein Auszug aus der Managed Bean-Spezifikation „Managed Beans sind Container-verwaltete Objekte mit minimalen Anforderungen, die auch unter dem Akronym„ POJOs “(Plain Old Java Objects) bekannt sind. Sie können als eine auf der Java EE-Plattform erweiterte Version des JavaBeans-Komponentenmodells auf der Java SE-Plattform angesehen werden …. Der Leser wird nicht übersehen, dass Managed Beans einen Vorläufer in der gleichnamigen Funktion der JavaServer Faces (JSF) -Technologie haben. Managed Beans, wie in dieser Spezifikation definiert, stellen eine Verallgemeinerung der in JSF gefundenen dar. Insbesondere können verwaltete Beans überall in einer Java EE-Anwendung verwendet werden, nicht nur in Webmodulen. Im Basiskomponentenmodell müssen verwaltete Beans beispielsweise einen Konstruktor ohne Argumente bereitstellen, aber eine Spezifikation, die auf verwalteten Beans aufbaut, z. B. CDI (JSR-299). kann diese Anforderung lockern und es Managed Beans ermöglichen, Konstruktoren komplexere Signaturen bereitzustellen, sofern sie einigen genau definierten Regeln folgen ... Eine Managed Bean darf nicht sein: eine letzte Klasse, eine abstrakte Klasse, eine nicht statische innere Klasse . Eine verwaltete Bean ist im Gegensatz zu einer normalen JavaBean-Komponente möglicherweise nicht serialisierbar. “ Daher ermöglicht die Spezifikation für verwaltete Bohnen, die auch als POJOs oder POJO-Beans bezeichnet wird, eine Erweiterung wie in CDI.

In der CDI-Spezifikation werden verwaltete Beans wie folgt neu definiert: Bei Ausführung in Java EE ist eine Java-Klasse der obersten Ebene eine verwaltete Bean, wenn sie die Anforderungen erfüllt:

• Es ist keine innere Klasse. • Es ist eine nicht abstrakte Klasse oder mit @Decorator versehen. • javax.enterprise.inject.spi.Extension wird nicht implementiert. • Es ist nicht mit @Vetoed oder in einem mit @Vetoed kommentierten Paket versehen. • Es hat entweder einen geeigneten Konstruktor: Die Klasse hat einen Konstruktor ohne Parameter, oder die Klasse deklariert einen Konstruktor mit der Bezeichnung @Inject.

Alle Java-Klassen, die diese Bedingungen erfüllen, sind verwaltete Beans. Daher ist keine spezielle Deklaration erforderlich, um eine verwaltete Bean zu definieren. Oder

wenn es von einer anderen Java EE-Spezifikation als verwaltete Bean definiert wird und wenn

• Es ist nicht mit einer EJB-Komponenten-definierenden Annotation versehen oder in ejb-jar.xml als EJB-Bean-Klasse deklariert.

Im Gegensatz zu Spring Beans werden Konstruktoren mit einfachen Typen nicht unterstützt. Dies ist möglicherweise möglich, wenn die Konfiguration mit XML-Konfigurationsdateien wie in Spring oder Anmerkungen unterstützt wird.

EJBs werden in einem EJB-Container ausgeführt. Seine Spezifikationsagt: "Eine Session-Bean-Komponente ist eine verwaltete Bean." "Die Klasse muss einen öffentlichen Konstruktor haben, der keine Argumente akzeptiert", heißt es sowohl für Session-Bean als auch für nachrichtengesteuerte Bean. Außerdem heißt es: "Die Session-Bean-Klasse ist nicht erforderlich, um die SessionBean-Schnittstelle oder die serialisierbare Schnittstelle zu implementieren. “ Aus dem gleichen Grund wie JSF-Beans, bei denen es sich bei der EJB3-Abhängigkeitsinjektion im Grunde genommen um eine Ressourceninjektion handelt, unterstützen JSF-Beans keine Konstruktoren mit Argumenten, dh über die Abhängigkeitsinjektion. Wenn der EJB-Container jedoch CDI implementiert, lautet „Optional: Die Klasse verfügt möglicherweise über eine Zusätzlicher Konstruktor, der mit der Annotation "Inject" versehen ist ", heißt es sowohl für Session-Bean als auch für Message-Driven-Bean, weil" ein EJB, der in ein CDI-Bean-Archiv gepackt und nicht mit javax.enterprise.inject.Vetoed-Annotation versehen ist, als CDI-fähig angesehen wird Bohne."

In der Praxis sind Bohnen nur handliche Objekte. Serialisierung bedeutet, dass Sie sie problemlos beibehalten können (in einer Form speichern, die leicht wiederhergestellt werden kann).

Typische Verwendung von Bohnen in der realen Welt:

• einfache wiederverwendbare Objekte POJO (Plain Old Java Objects)
• visuelle Objekte
• Spring verwendet Beans für Objekte, die verarbeitet werden sollen (z. B. Benutzerobjekt, das in einer Sitzung serialisiert werden muss).
• EJB (Enterprise Java Beans), komplexere Objekte wie JSF Beans (JSF ist eine alte, ziemlich veraltete Technologie) oder JSP Beans

Beans sind also nur eine Konvention / ein Standard , um von einem Java-Objekt etwas zu erwarten, das sich verhält (Serialisierung), und um einige Möglichkeiten zu bieten, es auf bestimmte Weise zu ändern (Setter für Eigenschaften).

Wie man sie benutzt, ist nur Ihre Erfindung, aber die häufigsten Fälle, die ich oben eingetragen habe.