La guía paso a paso o código que encontrarás en este post es la solución más fácil y válida que hallamos a esta duda o problema.
Solución:
JavaBeans
Un JavaBean es una clase que sigue las convenciones de JavaBeans definidas por Sun. Wikipedia tiene un resumen bastante bueno de lo que son los JavaBeans:
Los JavaBeans son componentes de software reutilizables para Java que se pueden manipular visualmente en una herramienta de construcción. Prácticamente, son clases escritas en el lenguaje de programación Java conforme a una convención particular. Se utilizan para encapsular muchos objetos en un solo objeto (el bean), de modo que puedan pasarse como un solo objeto bean en lugar de como varios objetos individuales. Un JavaBean es un objeto Java que se puede serializar, tiene un constructor nular y permite el acceso a las propiedades mediante métodos getter y setter.
Para funcionar como una clase JavaBean, una clase de objeto debe obedecer ciertas convenciones sobre el nombre, la construcción y el comportamiento de los métodos. Estas convenciones hacen posible tener herramientas que pueden usar, reutilizar, reemplazar y conectar JavaBeans.
Las convenciones requeridas son:
- La clase debe tener un constructor público predeterminado. Esto permite una fácil creación de instancias dentro de los marcos de edición y activación.
- Las propiedades de la clase deben ser accesibles mediante get, set y otros métodos (los llamados métodos de acceso y métodos de mutación), siguiendo una convención de nomenclatura estándar. Esto permite una fácil inspección y actualización automatizadas del estado del bean dentro de los marcos, muchos de los cuales incluyen editores personalizados para varios tipos de propiedades.
- La clase debe ser serializable. Esto permite que las aplicaciones y los marcos guarden, almacenen y restauren de manera confiable el estado del bean de una manera que es independiente de la máquina virtual y la plataforma.
Debido a que estos requisitos se expresan en gran medida como convenciones en lugar de implementar interfaces, algunos desarrolladores ven los JavaBeans como simples objetos Java antiguos que siguen convenciones de nomenclatura específicas.
POJO
Un objeto Java antiguo simple o POJO es un término introducido inicialmente para designar un objeto Java simple y ligero, que no implementa ningún javax.ejb interfaz, a diferencia del peso pesado EJB 2.x (especialmente Entity Beans, Stateless Session Beans no son tan malos en mi opinión). Hoy en día, el término se usa para cualquier objeto simple sin elementos adicionales. Una vez más, Wikipedia hace un buen trabajo al definir POJO:
POJO es un acrónimo de Plain Old Java Object. El nombre se usa para enfatizar que el objeto en cuestión es un Objeto Java ordinario, no un objeto especial y, en particular, no es un Enterprise JavaBean (especialmente antes de EJB 3). El término fue acuñado por Martin Fowler, Rebecca Parsons y Josh MacKenzie en septiembre de 2000:
“Nos preguntamos por qué la gente estaba tan en contra del uso de objetos regulares en sus sistemas y llegamos a la conclusión de que se debía a que los objetos simples carecían de un nombre elegante. Así que les dimos uno y se entendió muy bien”.
El término continúa el patrón de términos más antiguos para tecnologías que no usan características nuevas y sofisticadas, como POTS (Plain Old Telephone Service) en telefonía y PODS (Plain Old Data Structures) que se definen en C ++ pero usan solo características del lenguaje C, y POD (Plain Old Documentation) en Perl.
Es muy probable que el término haya ganado una amplia aceptación debido a la necesidad de un término común y fácil de entender que contrasta con los marcos de objetos complicados. Un JavaBean es un POJO que es serializable, tiene un constructor sin argumentos y permite el acceso a las propiedades usando métodos getter y setter. Un Enterprise JavaBean no es una clase única sino un modelo de componente completo (nuevamente, EJB 3 reduce la complejidad de los Enterprise JavaBeans).
A medida que los diseños que utilizan POJO se han vuelto más utilizados, han surgido sistemas que brindan a los POJO algunas de las funciones utilizadas en los marcos y más opciones sobre qué áreas de funcionalidad son realmente necesarias. Hibernate y Spring son ejemplos.
Objeto de valor
Un objeto de valor o VO es un objeto como java.lang.Integer que contienen valores (por lo tanto, objetos de valor). Para una definición más formal, a menudo me refiero a la descripción de Martin Fowler del objeto de valor:
En Patterns of Enterprise Application Architecture, describí el objeto de valor como un objeto pequeño, como dinero o un objeto de rango de fechas. Su key La propiedad es que siguen una semántica de valores en lugar de una semántica de referencia.
Por lo general, puede decirles porque su noción de igualdad no se basa en la identidad, sino que dos objetos de valor son iguales si todos sus campos son iguales. Aunque todos los campos son iguales, no es necesario comparar todos los campos si un subconjunto es único; por ejemplo, los códigos de moneda para objetos de moneda son suficientes para probar la igualdad.
Una heurística general es que los objetos de valor deben ser completamente inmutables. Si desea cambiar un objeto de valor, debe reemplazar el objeto por uno nuevo y no se le permitirá actualizar los valores del objeto de valor en sí; los objetos de valor actualizables dan lugar a problemas de alias.
La literatura temprana de J2EE usaba el término objeto de valor para describir una noción diferente, lo que yo llamo un objeto de transferencia de datos. Desde entonces, han cambiado su uso y en su lugar utilizan el término Transferir objeto.
Puede encontrar más material bueno sobre objetos de valor en la wiki y por Dirk Riehle.
Objeto de transferencia de datos
El objeto de transferencia de datos o DTO es un patrón (anti) introducido con EJB. En lugar de realizar muchas llamadas remotas en EJB, la idea era encapsular los datos en un objeto de valor que pudiera transferirse a través de la red: un objeto de transferencia de datos. Wikipedia tiene una definición decente de objeto de transferencia de datos:
El objeto de transferencia de datos (DTO), anteriormente conocido como objetos de valor o VO, es un patrón de diseño que se utiliza para transferir datos entre subsistemas de aplicaciones de software. Los DTO se utilizan a menudo junto con objetos de acceso a datos para recuperar datos de una base de datos.
La diferencia entre los objetos de transferencia de datos y los objetos comerciales o los objetos de acceso a los datos es que un DTO no tiene ningún comportamiento excepto el almacenamiento y la recuperación de sus propios datos (accesores y mutadores).
En una arquitectura EJB tradicional, los DTO tienen un doble propósito: primero, solucionan el problema de que los beans de entidad no son serializables; en segundo lugar, definen implícitamente una fase de ensamblaje en la que todos los datos que utilizará la vista se obtienen y se agrupan en los DTO antes de devolver el control al nivel de presentación.
Entonces, para muchas personas, DTO y VO son lo mismo (pero Fowler usa VO para significar algo más, como vimos). La mayoría de las veces, siguen las convenciones de JavaBeans y, por lo tanto, también son JavaBeans. Y todos son POJO.
DTO vs VO
DTO – Los objetos de transferencia de datos son solo contenedores de datos que se utilizan para transportar datos entre capas y niveles.
- Contiene principalmente attributes. Incluso puedes usar public attributes sin getters ni setters.
- Los objetos de transferencia de datos no contienen ninguna lógica empresarial.
Analogía:
Formulario de registro simple con attributes nombre de usuario, contraseña e identificación de correo electrónico.
- Cuando este formulario se envía en el archivo RegistrationServlet, obtendrá todos los attributes de la capa de vista a la capa de negocio donde pasa el attributes a Java beans y luego al DAO o la capa de persistencia.
- DTO ayuda a transportar el attributes de la capa de vista a la capa de negocio y finalmente a la capa de persistencia.
DTO se utilizó principalmente para transportar datos a través de la red de manera eficiente, incluso puede ser de JVM a otra JVM.
Los DTO son a menudo java.io.Serializable – para transferir datos a través de JVM.
VO – Un objeto de valor [1][2] representa en sí mismo un conjunto fijo de datos y es similar a una enumeración de Java. La identidad de un objeto de valor se basa en su estado más que en su identidad de objeto y es inmutable. Un ejemplo del mundo real sería Color.RED, Color.BLUE, SEX.FEMALE, etc.
POJO vs JavaBeans
[1]
El Java-Beanness de un POJO es que su attributes se accede a todos a través de captadores y definidores públicos que se ajustan a las convenciones de JavaBeans. p.ej
private String foo;
public String getFoo()...
public void setFoo(String foo)...;
[2]
Los JavaBeans deben implementar Serializable y tener un constructor sin argumentos, mientras que en POJO no tiene estas restricciones.
Básicamente,
DTO: Los “objetos de transferencia de datos” pueden viajar entre capas separadas en la arquitectura del software.
VO: “Objetos de valor” contienen un objeto como Integer, Money, etc.
POJO: Objeto simple de Java antiguo que no es un objeto especial.
Java Beans: requiere un Java Class para ser serializable, tener un no-arg constructor y un getter y setter para cada campo
Si te ha sido de utilidad este post, sería de mucha ayuda si lo compartieras con otros juniors de esta forma contrubuyes a dar difusión a nuestro contenido.