Buscar
Social
Ofertas laborales ES

Foro sobre Java EE > ¿Realmente es necesario crear una capa de VO o DTO?

Estoy empezando un nuevo desarrollo en el cual utilizaré JSF, el framework me permite llevar un Entity hasta la capa de presentación.

Mi crisis existencial es si creo o no una capa de VO, (yo entiendo que DTO y VO es lo mismo). Anteriormente he trabajado con Flex, Struts y GWT y esos frameworks me obligan a crear una y a veces 2 capas de VO.

Y en caso ya sea por buenas practicas y el uso del Patrón DTO sea recomendable ¿Cual es la mejor forma de implementarlo?
- Mapear Entity - VO
- Mapear Response/Request de Servicio - VO

Estuve leyendo por Internet y me encontré con este articulo, donde lo interesante esta en los comentarios. https://unpocodejava.wordpress.com/2010/03/29/patrones-que-odio-dto/

¿Vale la pena hacer el parsing desde Entity a VO?
¿Como afecta en la performance de la aplicación?

Saludos.

octubre 2, 2012 | Registered Commenterpedrodonte

He abierto un post sobre lo mismo.
aqui

En mi caso si que notaba retrasos, por la librería que comento en el hilo "dozerMapping". EL problema de automatizar este tipo de conversiones es que acabas teniendo una invocación en forma de árbol (de tiempo exponencial si analizas el algoritmo), si tienes orms por medio que se traen entidades relacionadas.

A mi me hacen dudar cada vez más de este tipo de patrones... pero tampoco me atrevo a eliminarlo de una aplicación de mi empresa...

A ver que opina el resto.

octubre 3, 2012 | Unregistered CommenterMayantigo

Investigando un poco más, vale la pena también preguntarse,
¿Deseas que la persona quien te diseña la GUI conozca tu modelo de datos?
¿Perfomance v/s Seguridad?

Bueno el problema sobre mantener los VO en caso de modificaciones en el modelo de datos, los solucione, eso si tuve que programar otra aplicación donde pones el paquete donde estan las entities y se generan automaticamente los VO y el helper que hace el parsing entre ambas.

leyendo por ahí, concluí para la GUI la capa de servicios debe ser como una caja negra, y su impacto al modificarse el modelo de datos debe ser el menor posible.

Saludos.

octubre 8, 2012 | Unregistered CommenterPedrodonte

Ahí si tienes razón. Pero eso tampoco va a poder darse siempre.

Imagina (caso muy típico, al menos en mi trabajo) un CRUD sobre una entidad. El cliente pide que además de los datos, se guarde un campo nuevo para (lo que sea). Tienes que modificar la tabla, la entidad, el VO y la vista.

Y casi cualquier cambio en el modelo de datos, acabaría afectando de todas formas a los VO (habrá algunos casos en los que no, me imagino).

En cuanto a la caja negra... bueno, no se. A mi no me parece un crimen que quien diseñe la GUI conozca tu modelo. Al fin y al cabo, él verá los "objetos", y no tiene porque saber si están mapeados en una BD o son VOs, a él le va a dar igual.

Bueno, supongo que tendrá su utilidad, y separa una capa de otra. Pero es un cúmulo de código que se va generando sin sentido, que hace perder mucho tiempo y es un verdadero coñazo, jeje.

Bueno el problema sobre mantener los VO en caso de modificaciones en el modelo de datos, los solucione, eso si tuve que programar otra aplicación donde pones el paquete donde estan las entities y se generan automaticamente los VO y el helper que hace el parsing entre ambas.

Por cierto, esa aplicación que dices sería una buena aportación a la comunidad :P, ¿has pensado en liberarla?.

Un saludo.

octubre 11, 2012 | Unregistered CommenterMayantigo

Dame un rato para pulir el código, ya que en este momento me avergüenza la codificación, pero funciona.

octubre 17, 2012 | Unregistered CommenterPedrodonte

buenas yo, siempre pensé que no era necesario, pero siempre se encuentran defensores, yo lo veo como replicar y crear clases que hacen el código menos legible

Victor Trapiello Fernández
http://www.trapiello.net

octubre 21, 2012 | Unregistered CommenterVictor Trapiello Fernandez