tutorial example entre ejemplo diferencia choose beans bean java javabeans

example - ¿Cuál es la ventaja de usar Java Beans?



java beans pdf (5)

1) Beans es una plataforma independiente, lo que significa que se puede ejecutar en cualquier lugar.

2) Se puede ejecutar en cualquier localidad y se distribuye en la naturaleza.

3) Los métodos, propiedades y eventos de los frijoles pueden ser controlados.

4) Es fácil configurar Java beans.

5) Un bean puede recibir y crear eventos.

6) Los ajustes de configuración de un bean se pueden almacenar de forma persistente y se pueden recuperar en cualquier momento.

Creo que entiendo qué son los Java Beans: las clases Java que contienen un constructor sin argumentos, son serializables y exponen sus campos con captadores y definidores.

  1. ¿Un Java Bean tiene que exponer todos sus campos para calificar como un bean? Si no, ¿hay que exponer alguna ?

  2. ¿Pueden los Java Beans incluir constructores con argumentos, así como un constructor sin argumentos?

  3. ¿Cuál es el propósito de Java Beans, aparte de ajustarse a un cierto estilo de codificación? Parece que se habla mucho sobre ''frijoles esto'' o ''frijoles que'', pero no sé por qué son ventajosos, específicamente.

Puedo conseguir totalmente hacer el constructor sin argumentos. Puede haber varias razones para ello, y no me sorprendería que un constructor sin argumentos ayude al compilador a hacer algunas optimizaciones, tampoco. También puedo entender que tu clase sea serializable. Incluso si la clase nunca se serializa, podría serlo, y volver a hacerlo retroactivamente podría ser molesto (o imposible en una biblioteca de caja negra).

Pero lo más curioso es el requisito de tener campos accesibles a través de captadores y configuradores. Los uso en mi propio trabajo cuando los necesito, pero parece extraño que Java Beans los requiera (posiblemente todos, dependiendo de mi respuesta al # 1). Si es un problema con la reflexión, ¿no podría la reflexión obtener los campos con la misma facilidad? Si se trata de un problema con hacer más que simplemente establecer el valor, ¿podría la reflexión utilizar un captador / definidor en un campo si el método existe?


La mayor ventaja es que sus beans se crean de acuerdo con una especificación y se pueden utilizar directamente con bibliotecas y marcos "compatibles con bean".

Por ejemplo, la mayoría de los marcos para la serialización (XML, JSON, YAML, ...) a menudo pueden usar beans directamente sin configuración.


Más que nada, un Java Bean es un componente de software reutilizable .

Esto significa que no está bien acoplado a otros componentes. Si su clase Java crea una instancia de otra clase, o devuelve alguna clase de implementación específica, ya no es un bean. Los frijoles cubren una parte bien definida de la funcionalidad y están ligeramente acoplados a otras clases.

La ventaja de esto es que obtienes todas estas pequeñas piezas que luego puedes trabajar juntas con bastante facilidad. Además, estos son fáciles de reutilizar y unittest.

Incluso si no está utilizando algún entorno visual para unir frijoles (como sugiere la especificación de frijoles), esto sigue siendo una razón para usar frijoles: para obtener pequeños fragmentos de código que son fácilmente utilizables.

Si no usa una herramienta visual, no es tan importante que su bean tenga un constructor de 0 argumentos, o es serializable.


Se adhieren a una especificación clara.

Gracias a esto, hay increíblemente muchas herramientas para facilitar el trabajo con Javabeans (o al revés). Existen herramientas que pueden generarlas automáticamente en función de algunos datos de cierto tipo ( XML , JSON , CSV , DDL , etc.) y / o viceversa, y también para leer / manipular / mapearlos como Commons BeanUtils , Dozer , EZMorph , etc. . Además, hay muchos marcos MVC / ORM que funcionan con Java, como JPA , Hibernate , JSF , Spring , etc. Incluso un IDE un poco decente como Eclipse sabe cómo autogenerar Java en función de algunos campos.

Son las herramientas y los marcos alrededor de los habitantes de Java los que hacen nuestra vida más fácil. Es la especificación de los javanabes la que hizo que esas cosas existieran.


Un JavaBean por sí solo no es terriblemente interesante, es solo una clase de Java que cumple con algunos de los estándares que se enumeran anteriormente. Sin embargo, la conformidad con este estándar es uno de los pilares sobre los cuales se construye el marco Java EE y aparece en bastantes lugares. Sospecho que cuando escuche sobre todas las grandes cosas que JavaBeans puede hacer, a qué se refiere en Enterprise JavaBeans (EJBs). Para su información, hay algunos tipos diferentes de EJB enumerados a continuación:

  1. Habas de la entidad
  2. Frijoles de sesión con estado
  3. Frijoles de sesión sin estado

Algunos detalles ahora siguen ...

Habas de la entidad

Es posible que desee leer / escribir objetos en / desde una base de datos subyacente. Podría usar JDBC / SQL para hacer esto, pero también podría usar un marco de persistencia. La especificación de Java EE incluye una especificación para la persistencia mediante la cual declara que su clase es un "bean de entidad" y Java genera automáticamente tablas y lógica de base de datos para asignar entre entradas en su base de datos y objetos en su programa. Originalmente, la persistencia era algo que requería el uso de un Servidor de aplicaciones (como Glassfish, JBoss, Geronimo, etc.) pero AFAIK, puede usarlo en aplicaciones de escritorio sin componente de servidor. La implementación real es proporcionada por una biblioteca de nivel inferior como Eclipselink, Toplink, Hibernate, etc., pero la API de Java elimina cualquier diferencia entre ellos.

Frijoles de sesión con estado

Imagine que desea crear una instancia de una clase Java que existe en una JVM separada. Las JVM pueden ejecutarse en la misma máquina física, pero igualmente pueden estar en máquinas separadas que se comunican a través de una red. Al usar un servidor de aplicaciones Java EE, puede crear una clase que pueda ser instanciada por los clientes del servidor de aplicaciones. Estos clientes pueden crear una instancia de una clase que actuará como un objeto normal, pero cualquier método invocado en el objeto se ejecuta en el servidor y los resultados se devuelven al llamante. Es básicamente una forma orientada a objetos de llamadas a procedimientos remotos.

Frijoles de sesión sin estado

Esta es una variación menor en los beans de sesión con estado. Con los beans con estado, si el servidor tiene 1000 clientes, potencialmente tendrá que crear 1000 instancias del bean y recordar qué instancia pertenece a cada cliente. Con los beans sin estado, el servidor crea un grupo de beans y no se molesta en recordar qué cliente posee qué bean. Cuando un cliente invoca un método, el servidor elige un bean del grupo y lo utiliza, devolviéndolo al grupo al finalizar. Utiliza beans de sesión con estado cuando desea que el servidor recuerde detalles de cada cliente, usará beans sin estado cuando no necesite recordar detalles específicos del cliente. Tenga en cuenta que los frijoles sin estado bien pueden tener estado, es solo que este estado no será de interés para el cliente.