¿Diferencia entre DTO, VO, POJO, JavaBeans?

Respuestas:

848

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 :

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

Para funcionar como una clase JavaBean, una clase de objeto debe obedecer ciertas convenciones sobre nombres de métodos, construcción y comportamiento. Estas convenciones permiten 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 usando 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 manera independiente de la VM y la plataforma.

Debido a que estos requisitos se expresan en gran medida como convenciones en lugar de mediante la implementación de interfaces, algunos desarrolladores ven los JavaBeans como Objetos Java sencillos 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 liviano simple, sin implementar ninguna javax.ejbinterfaz, a diferencia del EJB 2.x de peso pesado (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 cosas adicionales. Nuevamente, 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 del uso de 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 entiende muy bien".

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

Lo más probable es que el término haya ganado una aceptación generalizada debido a la necesidad de un término común y fácil de entender que contraste con marcos de objetos complicados. Un JavaBean es un POJO que es serializable, tiene un constructor sin argumentos y permite el acceso a las propiedades utilizando 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 Enterprise JavaBeans).

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

Objeto de valor

Un objeto de valor o VO es un objeto como el java.lang.Integerque contiene 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 de Value Object :

En Patterns of Enterprise Application Architecture describí Value Object como un objeto pequeño, como un Money o un objeto de rango de fechas. Su propiedad clave es que siguen la semántica de valores en lugar de la 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 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 debe permitir actualizar los valores del objeto de valor en sí mismo; los objetos de valor actualizables conducen a problemas de alias.

La literatura temprana de J2EE usó 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 lugar.

Puede 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 en EJB, la idea era encapsular 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 utilizado para transferir datos entre subsistemas de aplicaciones de software. Los DTO a menudo se usan 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 u objetos de acceso a 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 dos propósitos: primero, evitan el problema de que los beans de entidad no son serializables; segundo, 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, los 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 POJOs.

Pascal Thivent
fuente
1
Entonces, si tengo una clase de conveniencia creada solo para transferir datos no relacionados como este class SomeClass { public String foo;public String bar; }dentro de una clase con mucha lógica complicada, seguro que no es un JavaBean, no puede ser un VO ya que es mutable, ¿podría ser un DTO? aunque no está dirigido a invocaciones remotas de ningún tipo. ¿Se puede considerar un POJO?
Jaime Hablutzel
3
@ user2601512: Todavía sería un Bean. : P No hay nada de malo en que un Bean tenga un comportamiento, de hecho, es bastante esperado. Si no hace nada más, es básicamente un DTO.
cHao
77
@xSNRG: en parte porque degrada los objetos a datos sobre los que actúa otro código. Eso es un paso atrás desde una perspectiva OO, donde los objetos actúan y deberían ser responsables de su propio estado. Los DTO son ocasionalmente una solución decente si en realidad solo está transfiriendo datos, de ahí el nombre, pero la encapsulación básicamente se va por la ventana, y generalmente pierde cualquier garantía de validez / consistencia que pueda proporcionar un objeto real.
cHao
1
@KumaresanPerumal: Puedes, si quieres. Pero el modelo es distinto de la capa de datos y tiene diferentes objetivos y reglas. La capa de datos generalmente necesita todo lo establecido y configurable arbitrariamente, y el modelo idealmente quiere ocultar datos y aplicar invariantes. Si desea utilizar objetos modelo para el almacenamiento, tendrá que comprometerse de un lado u otro.
cHao
1
@KumaresanPerumal: la capa de datos está allí para almacenar y recuperar datos. Para hacer eso, todo pero necesita acceso completo a cualquier objeto que contenga los datos, ya que la recuperación significa establecer valores en un objeto en algún lugar. Pero el modelo maneja esos datos dentro del sistema y está sujeto a los principios OO, como la encapsulación: la idea de que los objetos deben mantener el control sobre su estado interno y no tener otro código que juegue con sus entrañas arbitrariamente. Los DTO pueden cerrar esa brecha; la capa de datos puede acceder a ellos a voluntad, y el modelo no tiene que renunciar al control.
cHao
66

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 atributos. Incluso puede usar atributos públicos sin captadores y definidores.
  • Los objetos de transferencia de datos no contienen ninguna lógica empresarial.

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

  • Cuando se envía este formulario en el archivo RegistrationServlet, obtendrá todos los atributos de la capa de vista a la capa empresarial, donde pasará los atributos a los Java Beans y luego al 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 usó principalmente para transportar datos de manera eficiente a través de la red, 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 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 a todos sus atributos privados se accede a través de captadores y establecedores 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.

Srinivas MV
fuente
Perdón por comentar muuuy tarde, pero estoy aprendiendo sobre las diferencias entre ellos y tengo una pregunta. ¿Qué pasa si tengo una clase Java Bean, pero con otros métodos como doSomething ()? ¿Qué clase de clase sería? Saludos
jscherman
@srinivas ¿por qué no podemos pasar los datos en DOMAIN o MODELO objeto java? Pero yo uso MODELO sin DTO. explícame brevemente gracias
Kumaresan Perumal
46

Básicamente,

DTO: los "objetos de transferencia de datos" pueden viajar entre capas separadas en la arquitectura de software.

VO: "Objetos de valor" contienen un objeto como Integer, Money, etc.

POJO: Objeto Java antiguo simple que no es un objeto especial.

Java Beans: requiere Java Classque sea serializable, tenga un no-argconstructor y un getter y setter para cada campo

Olcay Tarazan
fuente
Estas descripciones son en su mayoría incorrectas / incompletas.
cellepo
24

Los Java Beans no son lo mismo que los EJB.

La especificación JavaBeans en Java 1.0 fue el intento de Sun de permitir que los objetos Java sean manipulados en un IDE que se parecía a VB. Se establecieron reglas para los objetos calificados 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. Tal vez otros que me estoy olvidando.

Los EJB llegaron después. Combinan componentes distribuidos y un modelo transaccional, ejecutándose en un contenedor que gestiona subprocesos, agrupación, 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 EJB 1.0 era demasiado "hablador" con la base de datos. En lugar de hacer un viaje de ida y vuelta para cada elemento de datos, las personas los empaquetarían en Java Beans a granel y los enviarían.

Los POJO fueron una reacción contra los EJB.

duffymo
fuente
1
Me equivoqué y preferí eliminar mi mensaje. Gracias por la corrección. Quiero notar que el significado de POJO ha cambiado hace algún tiempo. Primero, solo están hechos de propiedades privadas y sus accesorios. Ahora, consideremos un POJO una clase con anotaciones, la implantación y extensión de otras clases, etc
sinuhepop
¿Qué pasa con VO, como se hizo la pregunta? Esta no es una respuesta hasta que responda la pregunta completa
cellepo
4

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 se utilizan getters y setters apropiados 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).

Suraj Kalokhe
fuente
¿Qué pasa con VO, como se hizo la pregunta? Esta no es una respuesta hasta que responda la pregunta completa
cellepo
1

Primero hablar sobre

Clase normal : eso significa que cualquier clase define que es normalmente en Java, significa que crea diferentes tipos de propiedades de método, etc.
Bean: Bean no es nada, es solo un objeto de esa clase en particular. .

y después de eso hablamos del último POJO

POJO - POJO es esa clase que no tiene ningún servicio, solo tiene un constructor predeterminado 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.

CENAR KUMAR CENIZADO
fuente
¿Qué pasa con VO, como se hizo la pregunta? Esta no es una respuesta hasta que responda la pregunta completa
cellepo
1
  • Objeto de valor : se usa cuando es necesario medir la igualdad de los objetos en función del valor de los objetos.
  • Objeto de transferencia de datos : pase datos con múltiples atributos de una sola vez del cliente al servidor a través de la capa, para evitar múltiples llamadas al servidor remoto.
  • Objeto Java plano simple: es como una clase simple cuyas propiedades, constructor público sin argumentos. Como declaramos para la entidad JPA.

diferencia-entre-valor-objeto-patrón-y-transferencia-de-datos-patrón

Atul Jain
fuente