style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Duda existencial, DTO(VO,TO) con las mismas propiedades que un Bean de JPA

Viendo el excelente ejemplo de @ingscjoshua, me dí cuenta que usa clases del tipo:

UsuarioTO.java
LoginTO.java

Y tiene también sus Entidades del tipo:

UsuarioEntity.java
loginEntity.java

Y bueno, sus métodos para llenar los TO con las propiedades de las Entidades..

//codigo por aca...
List<UsuarioTO> listaUsuarios = new ArrayList<UsuarioTO>();
List<UsuarioEntity> listTempUsuarios = usuarioDAO.getAllUsuarios();

for (UsuarioEntity usuarioEntity : listTempUsuarios) {
    UsuarioTO usuarioTO = new UsuarioTO();
    BeanUtils.copyProperties(usuarioEntity, usuarioTO);
    listaUsuarios.add(usuarioTO);
}
//mas codigo por aca...

LoginTO loginTO = null;
LoginEntity loginEntity = loginDAO.getLogin(usuario);

if (loginEntity != null) {
    loginTO = new LoginTO();
    BeanUtils.copyProperties(loginEntity, loginTO);
    UsuarioTO usuarioTO = new UsuarioTO();
    BeanUtils.copyProperties(loginEntity.getUsuario(), usuarioTO);
    loginTO.setUsuarioTO(usuarioTO);
 
   PerfilTO perfilTO = new PerfilTO();
    BeanUtils.copyProperties(loginEntity.getPerfil(), perfilTO);
    loginTO.setPerfilTO(perfilTO);
}
// ...y asi...

Mi pregunta es, qué tan necesario es hacer éso? porqué no sólo hace uso de las entidades tal y como están?
Digo no digo que esté bien o mal, sólo pregunto, porque aunque tengo amistades que me dicen que así lo hacen,
yo sinceramente nunca he hecho tal cosa, creo pojos pero con propiedades específicas, no reflejos de las entidades.
Está bien hacerlo así?
Porqué?
Que ventajas/desventajas hay en hacerlo de ésa forma?
Mataré a mi jefe por tratarme como senior en C# .net cuando no soy ni junior partido por la mitad?

Todas son preguntas serias.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ingscjoshua

Practicidad

No necesariamente tienen que tener las mismas propiedades, yo en este momento solo tengo en los TO las propiedades de los entity, porque al momento en el TO no necesito nada mas si después necesito cosas diferentes las añadiré, la razón fundamental es por respetar el MVC, no debería llevar el MODELO al CONTROLADOR, por lo que se necesita un transportador he hay el uso de los TO (Transfer Object's).

Es una buena practica porque así separas todo en capas.

Imagen de arterzatij

Bueno...

Ahi tambien estamos mezclando poco pero se hace, siempre lo estaremos realizando, ya que hay algo que tiene que conectar, lo que mas uso para esto es una interface, la parte del modelo uso la entidad y en el control realizo interfaces ... cada quien tiene su forma :) para respetar el modelo como comenta ' ingscjoshua'

Imagen de neko069

MVC

Creo que entonces, necesitamos poner en común conceptos.
Lo que yo entiendo por MVC es:

Modelo - DAO, clases que acceden a la base de datos y hacen el ABC correspondiente.
Vista - Swing, HTML, Javascript, creo que en ésta capa no hay pierde.
Controlador - O a veces le llaman capa de servicio, que es donde se hace todo lo que corresponda al negocio (aunque a veces el controlador es la capa que redirecciona entre peticiones y a la que hace la lógica, le llaman "de servicio" y es una capa extra).

Ahora, porqué digo ésto? creo que tu estás llamando a tus entidades "modelos" que son el reflejo de tablas de la base de datos. Espero estar entendiendo bien tu concepto.

Que la entidad(o modelo de una tabla) sea un transportador de datos es distinto a decir que es la capa de modelo, aclaro, por lo que yo entiendo que es el MVC.

Por éso la pregunta, porque como yo lo he visto (y trabajado, aclaro) es que los modelos sean, tanto entidades como objetos de transporte de datos.

A fin de cuentas, creo que ninguno de los dos estaría mal, es cuestión de enfoques, sólo contesto para aclarar el cómo veo yo las cosas.

Saludos.

Imagen de ingscjoshua

Si

Si pero ami personalmente me gusta tener separado es costumbre y creo que quien me enseño me enseño asi y me quede con esa costumbre a mi se me hace practico y en general se podria usar como tu comentas, pero ami particularmente me gusta separarlo, por como yo veo el MVC el modelo necesita un tranasporte y es ahi donde entran los TO que mueven los datos entre las capas tanto del MODELO al CONTROLADOR como del CONTROLADOR a la VISTA yo aprendi a usarlos asi y me quede con esa costumbre e idea de que asi se emplean, en otros lados donde he trabajado se usan de otras formas pero ami asi se me hace practico :)

El patrón "TO" (DTO, VO) se

El patrón "TO" (DTO, VO) se utiliza para facilitar la transferencia de objetos entre capas, entre canales, entre procesos, etc . Todo depende de la aplicación.

En aplicaciones distribuidas minimiza el tráfico en la red al agrupar varias propiedades en un solo objeto (es algo similar a enviar un solo archivo de 10 MB en vez de 10 de 1 MB, es más eficiente solo enviar un archivo).

Otro uso y quizá el más empleado es el de desacoplar capas y evitar que métodos y propiedades propias de la capa de persistencia lleguen a la capa de vista y viceversa.

Un TO debería solo de contar con propiedades(privadas) y los métodos de acceso y de modificación (Getters & Setters). No debería de contener reglas de negocio (más allá de lo imprescindible en los setters para garantizar el correcto estado del objeto)

Entendiendo lo anterior, un objeto TO no es aquel cuyo nombre termina en TO, aunque es una buena práctica.

Tener dos objetos con las mismas propiedades y métodos lejos de desacoplar capas, solo aumenta el numero de objetos a los que se les dará el mantenimiento y evita que errores en el nombre de las propiedades o la ausencia de propiedades se detecten en tiempo de compilación, pudiendo enmascarar errores y dificultando su detección. Por ejemplo, en el caso que muestras si en el entity la propiedad se llama newitem (puras minúsculas) y en el TO se llamara newItem (con la "i" en mayúsculas) el compilador no marcaría ningún error y al hacer la copia de propiedades simplemente las que no coinciden serían ignoradas. Al leer la propiedad de un lado siempre tendrías nulos y podrías perder mucho tiempo tratando de ver si es problema de base de datos, de vista, etc, , ,

Otro problema que tendrías es el performance en tu aplicación. Copiar propiedades no es gratuito y hacerlo con "reflection" agrega más gasto de recursos. Como desarrollador, utilizar métodos como el de " BeanUtils.copyProperties" es sumamente fácil y poderoso. Y se pasa por alto que para que eso funcione se tienen que leer todas las propiedades de ambos objetos, buscar coincidencias y copiar valores. Si tuvieras una lista con 100,000 objetos podría ser un verdadero problema.

Mi sugerencia es que las propiedades y los métodos de acceso y modificación solo se definan una vez. Y de ahí se herede para agregar lo necesario en cada tipo de objeto. En el libro "Core J2EE Patterns Best Practices and Design Strategies de Deepak Alur" sugieren que los objetos de entidad hereden de los objetos de transferencia y así evitar duplicidad de código. Aunque esto puede complicarse si utilizamos anotaciones en las entidades, ya que estas por lo general se ponen antes de cada propiedad o método. Ya que estos se heredan, las anotaciones de persistencia tendrían que ir en el TO. Para ello hay dos caminos, uno es evitar las anotaciones y en su lugar utilizar archivos XML para configurar las entidades, o agregar las anotaciones en el TO teniendo en cuenta que dichas anotaciones afectan como el motor de persistencia trata a la entidad y no modifica el comportamiento en sí del objeto en tiempo de ejecución ni le agrega tamaño en memoria o en la transferencia. Considero que estos problemas generan menos impacto en el desarrollo que el tener código duplicado y hacer uso intensivo de copia de objetos.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">