lo que es un buen patrón para la conversión entre entidades de hibernación y objetos de transferencia de datos?

Question

he tenido preguntas y preocupaciones similares en cuanto a cómo convertir entre entidades de Hibernate y transferencia de datos de objetos para ser devuelto por un servicio web como se discuten en esta pregunta:

está utilizando objetos de transferencia de datos en ejb3 considerado el mejor practicar

Uno de los factores mencionados aquí es que si los cambios en el modelo de dominio, un conjunto de dtos protegerá a los consumidores en el caso de un servicio web.

A pesar de que parece que va a añadir una cantidad sustancial de código para mi proyecto, este razonamiento parece sonido.

¿Hay un patrón de buen diseño que puedo utilizar para convertir una entidad de hibernación (que implementa una interfaz) a un DTO que implementa la misma interfaz?

Así que asumiendo ambos de los siguientes implementar 'libro', que iba a necesitar para convertir un BookEntity.class a un BookDTO.class para que pueda dejar JAXB serializar y retorno.

Una vez más, toda esta perspectiva parece dudosa para mí, pero si hay buenos patrones por ahí para ayudar a hacer frente a esta conversión, me gustaría obtener alguna información.

¿Hay acaso alguna manera interesante para convertir a través de la reflexión? O un patrón de 'constructor' que no estoy pensando?

¿Debo ignorar el patrón DTO y paso entidades alrededor?

Answer 1

¿Debo ignorar el patrón DTO y pasar alrededor de entidades?

Mi preferencia es por lo general "sí". No me gusta la idea de jerarquías paralelas creadas por el simple hecho de pureza arquitectónica o capa.

La razón original para el patrón DTO era chattiness excesivo en EJB 1.0 y 2.0 aplicaciones al pasar EJBs de entidad a la vista de nivel. La solución fue poner el estado bean de entidad en un DTO.

Otra razón que se da generalmente para la creación de dtos es prohibir la modificación de la capa de vista. DTO son objetos inmutables en ese caso, sin comportamiento. Lo hacen nada más que los datos de ferry a la capa de vista.

Yo diría que es un patrón DTO Core J2EE que se ha vuelto un anti-patrón.

Me doy cuenta de que algunas personas no estarían de acuerdo. Simplemente, estoy ofreciendo mi opinión. No es la única manera de hacerlo, ni necesariamente la forma "correcta". Es mi preferencia.

Answer 2

No tiene que ser una visión contraria entre todo el alegre patadas del DTO.

tl;. Dr - A veces es todavía útil

La ventaja de la DTO es que usted no tiene que añadir anotaciones trillón a sus clases de dominio.

Se comienza con @Entity. No es tan malo. Pero entonces usted necesita por lo JAXB se agrega @XMLElement etc - y entonces necesita JSON por lo que agregar cosas como @JsonManagedReference para Jackson a hacer lo correcto con relación a continuación, agregar etc etc etc hasta el infinito.

Muy pronto su POJO no es tan sencillo más. Lea sobre "Domain Driven Design" en algún momento.

Además se pueden "filtrar" algunas propiedades que no quiere la vista para saber acerca de.

Answer 3

No hay que olvidar que los objetos entidad no son fáciles de manejar cuando están en estado administrado. Esto hace que su paso a la interfaz gráfica de forma problemática. Para ser más precisos, los objetos secundarios se manejan con entusiasmo. Esto no se puede hacer fuera de sesión, cousing excepciones. Así que, o bien tienen que ser desalojado (individual) desde el gestor de la entidad de que tienen que ser convertidos a dtos apropiadas. A menos de cource hay un patrón, que no soy consciente de que estaría muy contento de saber.

Answer 4

Para crear rápidamente un "aspecto similar" DTO, sin un montón de duplicado get / juego de códigos, puede utilizar BeanUtils.copyProperties . Esa función ayudarle a copiar rápidamente los datos de DAO para la clase DTO. Sólo recuerde que hay más de uno bibliotecas comunes apoyan BeanUtils.copyProperties, pero su sintaxis no son los mismos.

Answer 5

Yo sé que esto es una vieja pregunta, pero pensé que iba a añadir una respuesta que ofrece un marco para ayudar en caso de que otra persona está abordando este problema.

Nuestro proyecto ha anotado JAXB POJOs que están separados de los POJOs JPA anotada. Nuestro equipo estaba debatiendo la mejor manera de mover datos entre los dos objetos (en realidad, estructuras de datos).

Esta es una opción para las personas a tener en cuenta:

Se han encontrado y están experimentando con bulldozer que maneja (1) mismo nombre, (2) el mapeo XML conversiones personalizadas y (3) como formas de copiar datos entre dos POJOs.

Ha sido muy fácil de usar hasta el momento.