Value Objects y DataTransfer Objects
Value Objects y DataTransfer Objects
Ayer me surgió una duda muy interesante sobre los Value Objects y los DataTransfer Objects en la cual se definen de una forma diferente y según entiendo en Java se han llegado a confundir estos términos utilizándolos indistintamente.
Value Object: http://c2.com/cgi/wiki?ValueObject
DataTransfer Object: http://en.wikipedia.org/wiki/Data_transfer_object
Me gustaría saber cuales son sus opiniones y como definirían los conceptos de Value Objects y de DataTransfer Objects.
Themocracy
Pues segun lo que leo en las definiciones yo diria que la principal diferencia se da en que los data transfer estan hechos con la idea de que sean transferidos.
jeje un poco obvio
Di mae la verdad no se que tenga que ver uno con el otro …
Un value object es un mae primitivo, un NO reference object por decirlo asi, un int por ejemplo, lo que ya todos sabemos que es un value type, un Data Transfer Object diria yo es mas un concepto, en el sentido de que es una estructura de datos para pasar de una capa a otra, por ejemplo tengo un objeto persona (sea una clase o un struct en .net) ese objeto tiene nombre y cedula, la idea de un DTO (hasta donde yo he visto) es que esa estructura de datos pueda ser comprendida por cualquiera de las capas, desde el accesso a datos, hasta el UI, donde cualquier de ellos puede consumirlos, estos objetos la idea es que no contengan implementacion, lo que se conoce como Entities por ejemplo, algo muy comun en arquitecturas SOA, por ejemplo en WCF el DataContract viene siendo un DTO.
Saludos !!!
Si es cierto David Chaverri tiene toda la razón en lo que es un value Object por decirlo así y aunque suene redundante es un objeto que va atado a un valor o representa un valor, estos comportamientos también los podemos ver en los tipos enumerados donde cada uno representa un valor no importando la plataforma en la que estén, sea esta Java o .Net, o los Integers que tienen un rango definido pero solo pueden tener valores integres y cada variable o instancia de un integer es inmutable lo que lo hace ser un objeto que corresponde con el valor que almacena y así un Value Object, en el caso de la confusión es que en Java el termino de Value Object como el de DataTransfer Object se emplea por igual siempre que se crea un Objeto de Transferencia de Datos se le pone el nombre de Value Object lo cual no es correcto por que no es un Objeto que represente un Valor como tal si no que sirve para transferir información.
En cuanto a la comparación de entities no estoy de acuerdo debido a que una entidad tiene comportamiento he implementación impuesta por un Framework (implementaciones como algoritmos de cache, lazy loading, etc…) o cualquier otra cosa que utilicemos y se supone que los DataTransfer Object se utilizan para transferir objetos entre capas sin ninguna implementación. ¿Veámoslo así si una entidad Persona tiene una relación con una Entidad Direccion como haría la entidad Persona para cargar todas las direcciones que le pertenezcan a esa entidad Direccion sin tener implementación?
Usted esta hablando de un entity de una manera muy subjetiva, en cuanto a que significa un entity para usted, un Business Entity tal como yo los conozco solo representan la estructura del objeto el hecho de como implemente usted la relacion con otro objeto, cuando lo cargue y demas no tiene que ver con el concepto de entity en si, si no con COMO lo implemente usted, yo no acostumbro tener la implementacion en el Business Entity siempre existe un handler/manager como quiera llamarle que me brinda el SERVICIO de obtener el o los objetos relacionados, que ud los llame dentro del entity, que haga un lazy load, etc etc etc, es implementacion especifica, pero el concepto de Entity, DTO es un objeto que simplemente tiene la estructura del objeto, inclusive podria yo decir que es un objeto 100 serializable, y que no contiene metodos, si lo quiere ver de otra forma. Es la abstraccion pura del objeto La clase y sus atributos. Por eso puse el ejemplo de WCF o bien Web Services, si un servicio utiliza una estructura como la famosa clase Persona, esta se debe conocer por el cliente tambien, y el WS en si es el que contiene la implementacion, por eso el ejemplo del DtaContract
Si creo que lo que pasa o donde ponen la diferencia es que los VO’s son tipos que contienen nada mas que valor y cuya identidad se define por esos valores. La confusión está, incluso en wikipedia los definen como si fueran lo mismo. Yo he visto que el término value object lo extienden al punto que no solo se refiere a tipos primitivos sino a tipos que solo tienen tipos primitivos. POCO’s que no contienen valores por referencia.
Generalmente estos tipos que no crean una estructura sino que son hasta cierto punto una aglomeración de propiedades para transportar datos los he visto usados para cumplir tareas especificas como cargar un grid o cosas así. Por eso el enredo de términos.
A fin de cuentas todos estos los he visto implementados como POJOs (o POCOs) que no tienen implementación de ningún tipo porque de alguna manera en la simplicidad es que está el valor de estos objetos. Se cargan usando patrones que les mantengan cierta independencia.
Creo que el problema es que siempre hay mucho apego a los términos y mucha gente influyente quiere adueñarse de x concepto y todos le ponen diferente nombre a la misma cosa con mínimas variantes, o inclusive nombran prácticas comunes para adueñarselas y de ahí nacen las confusiones.