Objetos de transferencia de datos y métodos de servicios transaccionales

Question

¿Hay alguna forma verdaderamente práctica para evitar el uso de dtos, al pasar los datos a través de métodos de servicios transaccionales respaldados por Hibernate? En otras palabras, son dtos la única solución no hacky para evitar problemas de inicialización perezosa?

Creo que las dos alternativas populares a las OTD y las razones por las que no me gusta de ellos son:

1. Open Session en el patrón de Vista. Esto no me gusta como me gustaría seguir los métodos de servicio verdaderamente transaccional (es decir, la sesión de Hibernate está comprometida y se cierra al salir del método). Esto es principalmente porque me gustaría no tener que preocuparse acerca de las transacciones si, por ejemplo, necesidad de publicar el servicio como un servicio web más adelante.

2. Al pasar objetos de dominio / negocio a través de métodos de servicio en lugar de dtos y con ganas ir a buscar los atributos / propiedades necesarias. Esto es algo mejor. Sin embargo, en una jerarquía de objetos de dominio no trivial con relaciones complicadas entidad la recuperación temprana tiene que parar en algún lugar. Y cuando lo hace, no puedo ver cómo esto no se volvería muy rápidamente en un hackaton completa sustitución de las entidades con referencia a los identificadores de todo el lugar.

Me estoy perdiendo algo o está dtos de hecho el único enfoque sólido desde el punto de vista del mantenimiento?

Answer 1

La única forma de utilizar realmente las entidades de extremo a extremo es usar algo un poco más sofisticado que OpenSessionInView. En mi experiencia que vas a tener que administrar la sesión de hibernación manualmente a nivel de aplicación. OpenSessionInView sólo le dará la misma sesión por una petición. Después de eso tendrá que ser constantemente volver a colocarlo en la sesión actual. Echar un vistazo a la costura y las conversaciones, o poner en práctica su propia gestión Session de Hibernate. Actualmente administramos manualmente nuestras sesiones basado en cuando un asistente se inicia y termina y utilizan primavera AOP para fijar las sesiones a las roscas derecha justo a tiempo (sesiones no es seguro para subprocesos, no es una buena mezcla con AJAX)

Servicios Web, por otra parte sin duda van a necesitar algún tipo de DTO. No veo una forma de evitar eso. Las entidades pueden parecen POJOs pero no son realmente, la serialización de ellos puede variar de difícil casi imposible. Basta con crear dtos que se ajustan con el objetivo del método de servicio y hacerse con él.

En lo personal no creo que el patrón DTO es terrible, si acaba de hacer un sitio web que es posible ir de extremo a extremo con entidades e incluso puede que comprar un poco de rendimiento, pero si quieres una arquitectura más flexible , seguir con dtos.

Answer 2

Los repositorios, servicios y controladores deberían ser los lugares que se ocupan de su núcleo aplicación (Session de Hibernate puede ciertamente ser utilizados como la totalidad de su capa de repositorio, si lo desea).

No se supone

Vistas a estar tratando con el núcleo de la aplicación, el modelo de dominio. No se les debe tratar con los objetos vivos, pero con un no-vivo, una representación adaptada de los objetos vivos. Las vistas se supone que deben ser entregados sólo los datos que necesitan, en el formato particular que lo necesiten. Debe contar con dtos para sus puntos de vista. Este patrón también se conoce como Modelo Vista, para contrastar con el modelo de dominio.

Para hacer la vida más fácil, puede haber bibliotecas o marcos, que puede auto-mapa de su modelo de objetos de dominio a los objetos de vista del modelo, y la espalda. En .NET, existe un marco de código abierto llamado AutoMapper actualmente en desarrollo; No estoy seguro de lo que hay para Java.

Answer 3

Si se relaja el requisito de cerrar la sesión, puede seguir utilizando la sesión abierta en la vista y apenas cometer todo en sus transacciones de servicios. La sesión seguirá estando disponible para perezosos fetch pero todas sus transacciones será completa. Pero si vas a cambiar a un servicio web, entonces usted tendría que carga ansiosa todas las entidades de todos modos. DTO simplemente le obligan a conscientemente la carga ansiosa y prevenir la pereza accidental.

Así que, en resumen, si usted tiene cuidado, puede saltarse los dtos en ambos entornos, pero probablemente se quedaría con la sesión abierta en la vista y se preocupan por los servicios web, cuando en realidad se convierten en un requisito.

Answer 4

Me encanta la idea de dtos, pero siempre sentí que no fueron muy bien aceptados o del agrado de otros desarrolladores desde la implementación de este enfoque adecuadamente todo el camino a la base de datos por lo general requiere mucho esfuerzo. Es por esto que he creado Blaze-Persistencia Entidad Vistas que permiten DTO modelo como interfaces que se correlacionan con el modelo entidad JPA de una manera eficiente. Se puede aplicar una vista entidad para una consulta y la consulta se adaptará de manera que sólo se ha podido recuperar el estado que realmente se requiere, en lugar de todo el estado y el mapa que en Java.

Mediante el uso de vistas entidad no necesita la sesión abierta en la vista contra el patrón, debido a que la estructura deseada se carga con impaciencia. Puesto que no hay entidad objetos involucrados, también habrá ningún problema de carga diferida.

Dado que el modelo de entidad menudo es tan similar al modelo DTO en etapas tempranas de desarrollo, a menudo veo a los desarrolladores simplemente omitir la creación de un modelo DTO separada en su intento de evitar la molestia. Tan pronto como las preocupaciones transversales como la auditoría, estadística o denormalizations tierra en el modelo entidad o la cantidad de datos en el modelo de entidad crece mucho más grande que lo que realmente necesitan para los casos de uso de la entidad, los desarrolladores tienen problemas.

¡sin duda como un blog publicar en el caso que escribí hace algún tiempo.