Qu'est-ce qu'un JavaBean exactement?

J'ai compris, je pense, qu'un "Bean" est une classe Java avec des propriétés et des getters / setters. Autant que je sache, c'est l'équivalent d'une structure en C. Est-ce vrai?

De plus, existe-t-il une réelle différence syntaxique entre un bean et une classe régulière? Existe-t-il une définition spéciale ou une interface?

En gros, pourquoi y a-t-il un terme pour cela?

Que signifie également l' Serializableinterface?

Un JavaBean n'est qu'un standard

1. Toutes les propriétés privées (utiliser des getters / setters )
2. Un constructeur public sans argument
3. Implémente Serializable.

C'est ça. C'est juste une convention. Beaucoup de bibliothèques en dépendent cependant.

En ce qui concerne Serializable, à partir de la documentation de l' API :

La sérialisation d'une classe est activée par la classe implémentant l'interface java.io.Serializable. Les classes qui n'implémentent pas cette interface n'auront aucun état sérialisé ou désérialisé. Tous les sous-types d'une classe sérialisable sont eux-mêmes sérialisables. L'interface de sérialisation n'a pas de méthodes ou de champs et ne sert qu'à identifier la sémantique d'être sérialisable.

En d'autres termes, les objets sérialisables peuvent être écrits dans des flux, et donc des fichiers, des bases de données d'objets, n'importe quoi vraiment.

De plus, il n'y a pas de différence syntaxique entre un JavaBean et une autre classe - une classe est un JavaBean si elle suit les normes.

Il y a un terme pour cela parce que la norme permet aux bibliothèques de faire par programmation des choses avec les instances de classe que vous définissez d'une manière prédéfinie. Par exemple, si une bibliothèque souhaite diffuser n'importe quel objet que vous lui passez, elle sait que c'est possible car votre objet est sérialisable (en supposant que la bibliothèque requiert que vos objets soient des JavaBeans appropriés).

Il y a un terme pour le rendre spécial. La réalité est loin d'être aussi mystérieuse.

Fondamentalement, un "Bean":

• est un objet sérialisable (c'est-à-dire qu'il implémente java.io.Serializableet le fait correctement),
• a des "propriétés" dont les getters et setters ne sont que des méthodes avec certains noms (comme, par exemple, getFoo()le getter pour la propriété "Foo"), et
• a un constructeur 0-arg public (donc il peut être créé à volonté et configuré en définissant ses propriétés).

Mise à jour:

Pour ce qui est de Serializable : Ce n'est rien d'autre qu'une "interface marqueur" (une interface qui ne déclare aucune fonction) qui indique à Java que la classe d'implémentation consent (et implique qu'elle est capable) de "sérialisation" - un processus qui convertit une instance dans un flux d'octets. Ces octets peuvent être stockés dans des fichiers, envoyés via une connexion réseau, etc., et avoir suffisamment d'informations pour permettre à une machine virtuelle Java (au moins, qui connaît le type de l'objet) de reconstruire l'objet ultérieurement - éventuellement dans une autre instance de la application, ou même sur une toute autre machine!

Bien sûr, pour ce faire, la classe doit respecter certaines limitations. Le plus important d'entre eux est que tous les champs d'instance doivent être soit des types primitifs (int, bool, etc.), des instances d'une classe qui est également sérialisable, soit marqués de transientmanière à ce que Java n'essaye pas de les inclure. (Cela signifie bien sûr que les transientchamps ne survivront pas au voyage sur un flux. Une classe qui a des transientchamps doit être prête à les réinitialiser si nécessaire.)

Une classe qui ne peut pas respecter ces limitations ne doit pas être implémentée Serializable(et, IIRC, le compilateur Java ne le laissera même pas faire).

Les JavaBeans sont des classes Java qui adhèrent à une convention de codage extrêmement simple. Tout ce que vous avez à faire est de

1. implémenter l' java.io.Serializableinterface - pour enregistrer l'état d'un objet
2. utiliser un constructeur d'arguments vide public - pour instancier l'objet
3. fournir des méthodes getter / setter publiques - pour obtenir et définir les valeurs des variables privées (propriétés).

Propriétés de JavaBeans

Un JavaBean est un objet Java qui satisfait certaines conventions de programmation:

1. La classe JavaBean doit implémenter soit Serializableou Externalizable

2. La classe JavaBean doit avoir un constructeur sans argument

3. Toutes les propriétés JavaBean doivent avoir des méthodes publiques setter et getter

4. Toutes les variables d'instance JavaBean doivent être privées

Exemple de 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;
   }
}

Explication avec un exemple.

1. importez java.io.Serializable

Quant à la sérialisation, voir la documentation .

2. champs privés

Les champs doivent être privés pour empêcher les classes externes de modifier facilement ces champs. Au lieu d'accéder directement à ces champs, des méthodes getter / setter usuelles sont utilisées.

3. Constructeur

Un constructeur public sans aucun argument.

4. getter / setter

Obtention et modification des méthodes d'accès et de modification des champs privés.

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

Les Java Beans utilisent pour moins de code et plus d'approche de travail ... Les Java Beans sont utilisés dans Java EE comme un contrat universel pour la découverte et l'accès au runtime. Par exemple, JavaServer Pages (JSP) utilise des Java Beans comme objets de transfert de données entre des pages ou entre des servlets et des JSP. JavaBeans Activation Framework Java EE utilise Java Beans pour intégrer la prise en charge des types de données MIME dans Java EE. L'API de gestion Java EE utilise JavaBeans comme base pour l'instrumentation des ressources à gérer dans un environnement Java EE.

À propos de la sérialisation:

Dans la sérialisation d'objet, un objet peut être représenté comme une séquence d'octets qui inclut les données de l'objet ainsi que des informations sur le type de l'objet et les types de données stockées dans l'objet.

Une fois qu'un objet sérialisé a été écrit dans un fichier, il peut être lu dans le fichier et désérialisé, c'est-à-dire que les informations de type et les octets qui représentent l'objet et ses données peuvent être utilisés pour recréer l'objet en mémoire.

La sérialisation vous sera utile lors du déploiement de votre projet sur plusieurs serveurs, car les beans seront conservés et transférés entre eux.

Java Beans est un standard, et ses exigences de syntaxe de base ont été clairement expliquées par les autres réponses.

Cependant, l'OMI, c'est plus qu'une simple norme de syntaxe. La véritable signification ou utilisation prévue de Java Beans est, avec divers supports d'outils autour de la norme, de faciliter la réutilisation du code et l'ingénierie logicielle basée sur les composants, c'est-à-dire permettre aux développeurs de créer des applications en assemblant des composants (classes) existants et sans avoir à en écrire code (ou seulement écrire un petit code de colle). Malheureusement, cette technologie est bien sous-estimée et sous-utilisée par l'industrie, ce qui peut être dit à partir des réponses dans ce fil.

Si vous lisez le didacticiel d'Oracle sur Java Beans , vous pouvez mieux comprendre cela.

Selon Wikipedia:

1. La classe doit avoir un constructeur public par défaut (sans arguments). Cela permet une instanciation facile dans les cadres d'édition et d'activation.

2. Les propriétés de classe doivent être accessibles à l'aide de get, set, is (peut être utilisé pour les propriétés booléennes au lieu de get) et d'autres méthodes (méthodes appelées accesseurs et méthodes de mutation) selon une convention de dénomination standard. Cela permet une inspection et une mise à jour automatisées faciles de l'état du bean dans les frameworks, dont beaucoup incluent des éditeurs personnalisés pour différents types de propriétés. Les setters peuvent avoir un ou plusieurs arguments.

3. La classe doit être sérialisable. [Cela permet aux applications et aux infrastructures de sauvegarder, stocker et restaurer de manière fiable l'état du bean d'une manière indépendante de la machine virtuelle et de la plate-forme.]

Pour plus d'informations, suivez ce lien.

En ce qui concerne la deuxième partie de votre question, la sérialisation est un mécanisme de persistance utilisé pour stocker des objets sous la forme d'une séquence d'octets signés. En termes moins formels, il stocke l'état d'un objet afin que vous puissiez le récupérer plus tard, par désérialisation.

Un Java Bean est une classe java [conceptuelle] qui doit suivre les conventions suivantes:

1. Il devrait avoir un constructeur sans argument.
2. Il doit être sérialisable.
3. Il doit fournir des méthodes pour définir et obtenir les valeurs des propriétés, appelées méthodes getter et setter.

Il s'agit d'un composant logiciel réutilisable. Il peut encapsuler de nombreux objets en un seul objet afin que le même objet soit accessible à partir de plusieurs endroits et constitue une étape vers une maintenance facile du code.

Ils sont sérialisables, ont un constructeur à zéro argument et permettent d'accéder aux propriétés à l'aide des méthodes getter et setter. Le nom "Bean" a été donné pour englober cette norme, qui vise à créer des composants logiciels réutilisables pour Java. according to wiki

Les objets qui forment l'épine dorsale de votre application et qui sont gérés par le conteneur Spring IoC sont appelés beans. Un bean est un objet qui est instancié, assemblé et autrement géré par un conteneur Spring IoC. Sinon, un bean est simplement l'un des nombreux objets de votre application. according to printemps io .

Juste un peu d'histoire / mise à jour sur le concept de bean. Beaucoup d'autres réponses ont en fait le pourquoi mais pas tant le pourquoi.

Ils ont été inventés très tôt à Java dans le cadre de la création d'interfaces graphiques. Ils ont suivi des modèles faciles à séparer par les outils, ce qui leur a permis de créer un panneau de propriétés afin que vous puissiez modifier les attributs du bean. En général, les propriétés du Bean représentaient un contrôle à l'écran (pensez x, y, largeur, hauteur, texte, ..)

Vous pouvez également le considérer comme une structure de données fortement typée.

Au fil du temps, ceux-ci sont devenus utiles pour de nombreux outils qui utilisaient le même type d'accès (par exemple, Hibernate pour conserver les structures de données dans la base de données)

Au fur et à mesure que les outils évoluaient, ils se déplaçaient davantage vers les annotations et s'éloignaient pour séparer les noms de setter / getter. Maintenant, la plupart des systèmes ne nécessitent pas de beans, ils peuvent prendre n'importe quel ancien objet Java simple avec des propriétés annotées pour leur dire comment les manipuler.

Maintenant, je vois les beans comme des boules de propriétés annotées - ils ne sont vraiment utiles que pour les annotations qu'ils portent.

Les haricots eux-mêmes ne sont pas un modèle sain. Ils détruisent l'encapsulation par leur nature car ils exposent toutes leurs propriétés à des manipulations externes et au fur et à mesure de leur utilisation, il y a une tendance (en aucun cas une exigence) à créer du code pour manipuler le bean à l'extérieur au lieu de créer du code à l'intérieur du bean (viole "don 'ne demandez pas à un objet ses valeurs, demandez à un objet de faire quelque chose pour vous "). L'utilisation de pojos annotés avec un minimum de getters et aucun setters est beaucoup plus OO restaurant l'encapsulation et avec la possibilité d'immuabilité.

Soit dit en passant, alors que tout cela se passait, quelqu'un a étendu le concept à quelque chose appelé Enterprise Java Beans. Ce sont ... différents. et ils sont suffisamment compliqués pour que de nombreuses personnes aient l'impression de ne pas comprendre tout le concept Bean et ont cessé d'utiliser le terme. C'est, je pense, pourquoi vous entendez généralement des beans appelés POJO (puisque chaque objet java est un POJO, c'est techniquement OK, mais lorsque vous entendez quelqu'un dire POJO, il pense le plus souvent à quelque chose qui suit le modèle de bean)

Un Java Bean est une classe java qui satisfait aux trois critères suivants:

1. Il devrait implémenter une interface sérialisable (interface A Marker).
2. Le constructeur doit être public et ne pas avoir d'arguments (ce que les autres appellent un "constructeur sans argument").
3. Il devrait y avoir des getter et des setters.

Bon à noter que le champ serialVersionUID est important pour maintenir l'état de l'objet. Le code ci-dessous est considéré comme un 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;
}}

Pour comprendre JavaBean, vous devez noter les éléments suivants: JavaBean est un truc conceptuel et ne peut pas représenter une classe de choses spécifiques

JavaBean est un outil de développement pouvant être visualisé dans le fonctionnement de composants logiciels réutilisables

JavaBean est basé sur la spécification Sun JavaBeans et peut être des composants réutilisables. Sa plus grande caractéristique est la réutilisation.

Un bean est une classe Java avec des noms de méthode qui suivent les directives Java Bean (également appelées modèles de conception) pour les propriétés , les méthodes et événements. Ainsi, toute méthode publique de la classe de bean qui ne fait pas partie d'une définition de propriété est une méthode de bean. Au minimum, une classe Java même avec une propriété comme seul membre (bien sûr, accompagnant le getter et le setter requis), une méthode publique comme le seul membre ou juste une méthode d'enregistrement d'écouteur d'événement public est un bean Java. De plus, la propriété peut être soit une propriété en lecture seule (a une méthode getter mais pas de setter) ou une propriété en écriture seule (a une méthode setter uniquement). Le bean Java doit être une classe publique pour être visible par n'importe quel outil ou conteneur de beanbox. Le conteneur doit pouvoir l'instancier; ainsi, il doit également avoir un constructeur public. le spécification JavaBeansn'exige pas qu'un bean ait un constructeur public zéro-args, explicite ou par défaut, pour qu'un conteneur l'instancie. Si vous pouviez fournir un fichier (avec l'extension .ser) contenant une instance sérialisée, un outil beanbox pourrait utiliser ce fichier pour instancier un bean prototype. Sinon, le bean doit avoir un constructeur public à zéro argument, explicite ou par défaut.

Une fois le bean instancié, l'API Java Bean (java.beans. *) Peut l'introspecter et appeler des méthodes dessus. Si aucune classe implémentant l'interface BeanInfo ou étendant une implémentation BeanInfo, classe SimpleBeanInfo, n'est disponible, l'introspection implique l'utilisation de la réflexion (introspection implicite) pour étudier les méthodes prises en charge par un bean cible, puis appliquer des modèles de conception simples (les directives) à déduire de ces méthodes quelles propriétés, événements et méthodes publiques sont pris en charge. Si une classe implémentant l'interface BeanInfo (pour un bean Foo, il doit être nommé FooBeanInfo) est disponible, l'API contourne l'introspection implicite et utilise des méthodes publiques (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) de cette classe pour obtenir le information. Si une classe étendant SimpleBeanInfo est disponible, selon laquelle des méthodes publiques SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) sont remplacées, elle utilisera ces méthodes substituées pour obtenir des informations; pour une méthode qui n'est pas remplacée, elle sera par défaut l'introspection implicite correspondante. Un bean doit de toute façon être instancié même si aucune introspection implicite n'y est effectuée. Ainsi, l'exigence d'un constructeur zeri-args public. Mais, bien sûr, l'interface Serializable ou Externalizable n'est pas nécessaire pour qu'elle soit reconnue. Cependant, la spécification Java Bean dit: «Nous aimerions également que ce soit« trivial »pour le cas commun d'un petit Bean qui veut simplement que son état interne soit sauvegardé et ne veut pas y penser. Ainsi, tous les beans doivent implémenter une interface sérialisable ou extensible. Global, La spécification JavaBeans n'est pas difficile et rapide sur ce qui constitue un bean. "L'écriture de composants JavaBeans est étonnamment simple. Vous n'avez pas besoin d'un outil spécial et vous n'avez pas besoin d'implémenter d'interfaces. L'écriture de beans consiste simplement à suivre certaines conventions de codage. Tout ce que vous avez à faire est de faire ressembler votre classe un bean - les outils qui utilisent des beans pourront reconnaître et utiliser votre bean. " Trivialement, même la classe suivante est un Java Bean,

public class Trivial implements java.io.Serializable {}

Disons qu'un constructeur de bean a des paramètres. Supposons que certains sont des types simples. Le conteneur peut ne pas savoir quelles valeurs leur affecter; même si c'est le cas, l'instance résultante pourrait ne pas être réutilisable. Cela n'a de sens que si l'utilisateur peut configurer (spécifier des valeurs) par exemple des annotations ou des fichiers de configuration xml comme dans les beans Spring. Et supposons que certains paramètres soient des types de classe ou d'interface. Encore une fois, le conteneur peut ne pas savoir quelles valeurs lui affecter. Cela n'a de sens que si l'utilisateur peut configurer (spécifier des objets spécifiques) par exemple des annotations ou des fichiers de configuration xml. Cependant, même dans Spring (via les fichiers de configuration xml), l'attribution d'objets spécifiques (avec des noms de chaîne) aux arguments du constructeur (attribut ou élément des arguments du constructeur) n'est pas sécurisée de type; c'est essentiellement comme l'injection de ressources. Faire des références à d'autres beans Spring (appelés collaborateurs; via un élément dans un élément d'argument constructeur) est essentiellement une injection de dépendance et donc sûr pour les types. De toute évidence, une dépendance (bean collaborateur) peut avoir un constructeur avec des paramètres injectés; ces dépendances injectées peuvent avoir un constructeur avec des paramètres et ainsi de suite. Dans ce scénario, en fin de compte, vous auriez besoin de certaines classes de bean (par exemple, MyBean.class) que le conteneur peut instancier en appelant simplement new MyBean () avant de pouvoir construire les autres beans collaboratifs via l'injection de dépendances sur les constructeurs - ainsi, l'exigence de les beans pour avoir un constructeur public à zéro args. Supposons que si un conteneur ne prend pas en charge l'injection de dépendances et / ou n'autorise pas l'attribution de valeurs de type simple au constructeur via des annotations ou des fichiers de configuration xml comme dans Spring, Les constructeurs de bean ne doivent pas avoir de paramètres. Même une application Spring beans aurait besoin de certains beans pour avoir un constructeur public sans arguments (par exemple, dans un scénario où votre application Spring n'a pas de bean avec juste des types simples comme arguments de constructeur).

Les beans gérés JSF s'exécutent dans un conteneur Web. Ils peuvent être configurés avec l'annotation @ManagedBean ou avec un fichier de ressources de configuration d'application managed-bean.xml. Cependant, il prend en charge l'injection via l'injection de ressources (non sécurisée) uniquement; ne convient pas à l'injection sur les constructeurs. le spécification JSFrequiert que les beans gérés doivent avoir un constructeur public à zéro argument. De plus, il indique: «À partir de la version 2.3 de cette spécification, l'utilisation de la fonction de bean géré comme spécifié dans cette section est fortement déconseillée. Une solution meilleure et intégrée de manière plus cohérente pour résoudre le même problème consiste à utiliser Contexts and Dependency Injection (CDI), comme spécifié dans JSR-365. "En d'autres termes, les beans gérés CDI à utiliser, qui offrent une injection de dépendance de typesafe sur les constructeurs similaires aux Spring beans. La spécification CDI adopte la spécification Managed Beans, qui s'applique à tous les conteneurs de la plate-forme JEE, pas seulement au niveau Web. Ainsi, le conteneur Web doit implémenter la spécification CDI.

Voici un extrait du spécification du bean géré «Les beans gérés sont des objets gérés par conteneur avec des exigences minimales, autrement connus sous l'acronyme« POJO »(Plain Old Java Objects)… ils peuvent être vus comme une version améliorée de la plate-forme Java EE du modèle de composant JavaBeans trouvé sur la plate-forme Java SE …. Le lecteur ne manquera pas que les beans gérés ont un précurseur dans l'installation homonyme trouvée dans la technologie JavaServer Faces (JSF)… Les beans gérés tels que définis dans cette spécification représentent une généralisation de ceux trouvés dans JSF; en particulier, les beans gérés peuvent être utilisés n'importe où dans une application Java EE, pas seulement dans les modules Web. Par exemple, dans le modèle de composant de base, les beans gérés doivent fournir un constructeur sans argument, mais une spécification qui s'appuie sur les beans gérés, comme CDI (JSR-299), peut assouplir cette exigence et permettre aux beans gérés de fournir aux constructeurs des signatures plus complexes, à condition qu'ils suivent des règles bien définies ... Un bean géré ne doit pas être: une classe finale, une classe abstraite, une classe interne non statique . Un bean géré peut ne pas être sérialisable contrairement à un composant JavaBean standard. » Ainsi, la spécification des beans gérés, autrement appelés POJO ou POJO, permet une extension comme dans CDI.

La spécification CDI redéfinit les beans gérés comme: Lors de l'exécution dans Java EE, une classe Java de niveau supérieur est un bean géré si elle répond aux exigences:

• Ce n'est pas une classe intérieure. • Il s'agit d'une classe non abstraite ou est annotée @Decorator. • Il n'implémente pas javax.enterprise.inject.spi.Extension. • Il n'est pas annoté @Vetoed ou dans un package annoté @Vetoed. • Elle a un constructeur approprié, soit: la classe a un constructeur sans paramètres, soit la classe déclare un constructeur annoté @Inject.

Toutes les classes Java qui remplissent ces conditions sont des beans gérés et donc aucune déclaration spéciale n'est requise pour définir un bean géré. Ou

s'il est défini comme étant un bean géré par toute autre spécification Java EE et si

• Il n'est pas annoté avec une annotation de définition de composant EJB ou déclaré en tant que classe de bean EJB dans ejb-jar.xml.

Contrairement aux beans Spring, il ne prend pas en charge les constructeurs avec des types simples, ce qui pourrait être possible s'il prend en charge la configuration avec des fichiers de configuration xml comme dans Spring ou toute autre annotation.

Les EJB s'exécutent dans un conteneur EJB. Ses spécificationdit: "Un composant de bean session est un bean géré." "La classe doit avoir un constructeur public qui ne prend aucun argument", dit-elle pour le bean session et le bean géré par message. De plus, il dit: "La classe bean session est pas nécessaire pour implémenter l'interface SessionBean ou l'interface Serializable. " Pour la même raison que les beans JSF, l'injection de dépendances EJB3 étant essentiellement une injection de ressources, les beans JSF ne prennent pas en charge les constructeurs avec des arguments, c'est-à-dire via l'injection de dépendances. Cependant, si le conteneur EJB implémente CDI, «Facultativement: la classe peut avoir un constructeur supplémentaire annoté avec l'annotation Inject ", indique-t-il pour le bean session et le bean géré par message car," Un EJB empaqueté dans une archive de bean CDI et non annoté avec javax.enterprise.inject.Vetoed annotation, est considéré comme un CDI-enabled haricot."

En pratique, les Beans ne sont que des objets pratiques à utiliser. Les sérialiser signifie pouvoir les conserver facilement (stocker sous une forme facilement récupérable).

Utilisations typiques des haricots dans le monde réel:

• objets réutilisables simples POJO (Plain Old Java Objects)
• objets visuels
• Spring utilise des beans pour gérer les objets (par exemple, objet utilisateur qui doit être sérialisé en session)
• EJB (Enterprise Java Beans), des objets plus complexes, comme JSF Beans (JSF est une ancienne technologie assez obsolète) ou JSP Beans

Donc, en fait, les haricots ne sont qu'une convention / norme pour attendre quelque chose d'un objet Java qu'il se comporterait (sérialisation) et donner des moyens de le changer (paramètres pour les propriétés) d'une certaine manière.

Comment les utiliser, c'est juste votre invention, mais la plupart des cas que j'ai enrôlés ci-dessus.