Diferencia entre DTO, VO, POJO, JavaBeans?

He visto algunas preguntas similares:

  • ¿Cuál es la diferencia entre JavaBean y POJO?
  • ¿Cuál es la diferencia entre POJO (objeto Java antiguo simple) y DTO (objeto de transferencia de datos)?

¿Puedes también decirme los contextos en los que se usan? O el propósito de ellos?

JavaBeans

Un JavaBean es una clase que sigue las convenciones de JavaBeans definidas por Sun. Wikipedia tiene un muy buen resumen de lo que son los JavaBeans :

Los JavaBeans son componentes de software reutilizables para Java que pueden manipularse visualmente en una herramienta de construcción. Prácticamente, son clases escritas en el lenguaje de progtwigción Java conforme a una convención particular. Se usan para encapsular muchos objetos en un solo objeto (el bean), de modo que se pueden pasar como un solo objeto bean en lugar de como objetos individuales múltiples. Un JavaBean es un objeto Java que es serializable, tiene un constructor nullary y permite el acceso a las propiedades usando los métodos getter y setter.

Para funcionar como una clase JavaBean, una clase de objeto debe obedecer ciertas convenciones sobre la denominación, construcción y comportamiento del método. Estas convenciones permiten tener herramientas que pueden usar, reutilizar, reemplazar y conectar JavaBeans.

Las convenciones requeridas son:

  • La clase debe tener un constructor predeterminado público. Esto permite una fácil creación de instancias dentro de marcos de edición y activación.
  • Las propiedades de clase deben ser accesibles usando get, set y otros métodos (los llamados métodos de acceso y métodos de mutador), siguiendo una convención de nomenclatura estándar. Esto permite una inspección automatizada y una fácil actualización 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 VM 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 antiguos de Java que siguen convenciones de nomenclatura específicas.

POJO

Un objeto Java simple o POJO es un término introducido inicialmente para designar un objeto Java ligero simple, que no implementa ninguna interfaz javax.ejb , a diferencia del pesado EJB 2.x (especialmente los beans de entidad, los beans de sesión sin estado no son tan malos IMO) . Hoy, el término se usa para cualquier objeto simple sin elementos adicionales. De nuevo, 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 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é las personas estaban tan en contra de usar objetos regulares en sus sistemas y concluimos que era porque los objetos simples carecían de un nombre elegante. Así que les dimos uno, y se capta muy bien”.

El término continúa el patrón de términos más antiguos para las tecnologías que no usan nuevas características sofisticadas, como POTS (servicio telefónico simple antiguo) en telefonía, y PODS (estructuras de datos antiguas simples) que se definen en C ++ pero usan solo características de lenguaje C, y POD (Documentación antigua llana) en Perl.

El término probablemente haya ganado aceptación generalizada debido a la necesidad de un término común y fácil de entender que contrasta con marcos de objetos complicados. Un JavaBean es un POJO que es serializable, tiene un constructor sin argumentos, y permite el acceso a propiedades usando los métodos getter y setter. Un Enterprise JavaBean no es una única clase sino un modelo completo de componentes (una vez más, EJB 3 reduce la complejidad de Enterprise JavaBeans).

A medida que los diseños que utilizan POJO se utilizan con más frecuencia, han surgido sistemas que brindan a POJOs algunas de las funcionalidades utilizadas en los marcos y más opciones sobre las áreas de funcionalidad que realmente se necesitan. Hibernate y Spring son ejemplos.

Objeto de valor

Un objeto de valor o VO es un objeto como java.lang.Integer que contiene valores (por lo tanto, valora los objetos). Para una definición más formal, a menudo me remito a la descripción de Martin Fowler de Value Object :

En Patterns of Enterprise Application Architecture, describí Value Object como un objeto pequeño, como un objeto Money o date range. Su propiedad clave es que siguen la semántica del valor en lugar de la semántica de referencia.

Por lo general, puede decirles que 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 necesita comparar todos los campos si un subconjunto es único; por ejemplo, los códigos de moneda para los 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 generan 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 usan el término Transferir Objeto .

Puedes encontrar más material bueno sobre objetos de valor en la wiki y por Dirk Riehle .

Objeto de transferencia de datos

Data Transfer Object o DTO es un patrón (anti) introducido con EJB. En lugar de realizar muchas llamadas remotas a EJB, la idea era encapsular datos en un objeto de valor que podría 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 :

Objeto de transferencia de datos (DTO), anteriormente conocido como objetos de valor o VO, es un patrón de diseño utilizado para transferir datos entre subsistemas de aplicaciones de software. Los DTO se usan 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 de negocio u objetos de acceso a datos es que un DTO no tiene ningún comportamiento excepto para el almacenamiento y la recuperación de sus propios datos (accesadores y mutadores).

En una architecture EJB tradicional, los DTO tienen dos propósitos: primero, resuelven el problema de que los beans de entidad no son serializables; en segundo lugar, definen implícitamente una fase de ensamblaje donde todos los datos que se utilizarán en la vista se captan y se agrupan en los DTO antes de devolver el control al nivel de presentación.


Entonces, para muchas personas, los DTO y los VO son lo mismo (pero Fowler usa los 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.

  • Principalmente contiene atributos. Incluso puede usar atributos públicos sin getters y setters.
  • Los objetos de transferencia de datos no contienen ninguna lógica comercial.

Analogía:
Formulario de registro simple con atributos nombre de usuario, contraseña e id de correo electrónico.

  • Cuando este formulario se envía en el archivo RegistrationServlet obtendrá todos los atributos de la capa de vista a la capa de negocio donde pasa los atributos a java beans y luego a DAO o la capa de persistencia.
  • El DTO ayuda a transportar los atributos de la capa de vista a la capa de negocios y finalmente a la capa de persistencia.

DTO se utilizó principalmente para transportar datos a través de la red de manera eficiente, puede ser incluso desde 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] se representa a sí mismo como 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 en lugar de 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 sus atributos privados se acceden a través de getters y setters públicos que se ajustan a las convenciones de JavaBeans. p.ej

  private String foo; public String getFoo(){...} public void setFoo(String foo){...}; 

[2] JavaBeans debe implementar Serializable y tener un constructor sin argumentos, mientras que en POJO no tiene estas restricciones.

Básicamente,

DTO: “Objetos de transferencia de datos” puede viajar entre capas separadas en la architecture del software.

VO: “Value Objects” contiene un objeto como Integer, Money etc.

POJO: Plain Old Java Object que no es un objeto especial.

Java Beans: requiere que una Java Class sea ​​serializable, tenga un constructor no-arg y un getter y setter para cada campo

Los Java Beans no son lo mismo que los EJB.

La especificación JavaBeans en Java 1.0 fue el bash de Sun de permitir manipular objetos Java en un IDE que se parecía a VB. Hubo reglas establecidas para objetos que calificaron como “Java Beans”:

  1. Constructor predeterminado
  2. Getters y setters para miembros de datos privados que siguieron la convención de nomenclatura adecuada
  3. Serializable
  4. Quizás otros que me estoy olvidando.

Los EJB llegaron más tarde. Combinan componentes distribuidos y un modelo transaccional, que se ejecuta en un contenedor que gestiona los hilos, la puesta en común, el ciclo de vida y proporciona servicios. Están muy lejos de Java Beans.

Los DTO surgieron en el contexto de Java porque la gente descubrió que la especificación de EJB 1.0 era demasiado “parlante” con la base de datos. En lugar de hacer un viaje de ida y vuelta para cada elemento de datos, la gente los empacaría en Java Beans a granel y los enviaría por todos lados.

POJOs fueron una reacción contra los EJB.

POJO : Es un archivo java (clase) que no extiende ni implementa ningún otro archivo java (clase).

Bean : es un archivo java (clase) en el que todas las variables son privadas, los métodos son públicos y los getters y setters apropiados se usan para acceder a las variables.

Clase normal : es un archivo java (clase) que puede consistir en variables públicas / privadas / predeterminadas / protegidas y que puede o no extender o implementar otro archivo java (clase).

Primero hablar sobre

Clase normal : eso significa que cualquier definición de clase que es normalmente en Java significa que usted crea diferentes tipos de propiedades de método, etc.
Bean – Bean no es nada, es solo un objeto de esa clase en particular que usa este bean, puedes acceder a tu clase Java como objeto. .

y después de eso hablar sobre el último POJO

POJOPOJO es aquella clase que no tiene ningún servicio, tiene solo un constructor por defecto y una propiedad privada y esas propiedades para establecer un valor correspondiente a los métodos setter y getter. Es una forma abreviada de Plain Java Object.

tl; dr

Mesa Meme

dos imágenes lo explicaron todo: