Cómo modelar y manejar DTO de presentación para abstraer del modelo de dominio complicado?

Question

Hola, estoy desarrollando una aplicación que necesita trabajar con un modelo de dominio complejo utilizando Hibernate. Esta aplicación utiliza Spring MVC y el uso de los objetos de dominio en la capa de presentación es muy desordenado, así que creo que debería usar los DTO que van desde y hacia mi capa de servicio para que coincidan con lo que necesito en mis vistas. Ahora vamos a suponer que tengo una entidad CarLease cuyas propiedades son primitivos de Java no es sencillo pero está compuesta con otras entidades como marca, modelo, etc.

public class CarLease { 
     private Make make; 
     Private Model model; 
     . 
     . 
     . 
    } 

mayoría de las propiedades son de esta manera y que son seleccionables mediante desplegable selecciona en el jsp view, cada uno publicará una ID en el controlador.

Ahora teniendo en cuenta algunos casos de uso estándar: crear, editar, visualizar

Cómo haría usted para modelar la presentación de DTO para ser utilizados como objetos de forma de respaldo y la comunicación entre las capas de presentación y de servicio ??

¿Podrías crear un DTO diferente para cada caso (crear, editar, mostrar), harías DTO para los atributos complejos? en caso afirmativo, ¿dónde traducirías la identificación a la entidad?

cómo y dónde se manejaría la validación, montaje de DTO/Dominio, ¿qué devolvería de los métodos de la capa de servicio? (crear, editar, obtener)

Como puede ver, ahora me beneficiaré al separar mi vista de los objetos del dominio (muy compleja con muchas cosas que no necesito) pero estoy teniendo un momento difícil encontrar ejemplos del mundo real y las mejores prácticas para esto. Necesito una guía de arquitectura de arriba a abajo, tenga en cuenta que usaré Spring MVC en caso de que pueda aprovechar su impresora.

gracias de antemano.

Answer 1

Por lo que vale (estoy desarrollando en C# .net - pero los principios deberían seguir siendo útiles) He definido un montón de tipos (DTO) que utilizo para intercambiar datos entre la empresa y niveles de datos; y tengo más de un tipo por objeto/entidad de dominio. Estos se definen como clases simples.

Cada una de ellas está construida con una tarea específica en mente, por ejemplo:

• que tienen un tipo de peso ligero diseñado para llenar las vistas de lista (un montón de "filas", pero no muchos "columnas") . También tengo un tipo de colección correspondiente que contiene cualquier cantidad de estos.
• Tengo una copia "grande" que normalmente tiene todas las propiedades de la entidad en cuestión, pero solo para una instancia de la misma. Puedo tener más de uno de estos dependiendo del tamaño y la complejidad de la entidad frente a los casos de uso; y también dependiendo de si desea devolver todos los datos asociados con una instancia de la entidad de inmediato, o cargar algunos de forma lenta en las solicitudes posteriores.
• También suelo tener tipos de "guardar" (nuevo) y "actualizar" por separado para la entidad.

Cada tipo está diseñado para contener sólo la información relevante para una tarea determinada. Por ejemplo, el "grande" devolverá la fecha de la última modificación, pero no espero eso en mis tipos de guardar y actualizar porque los rellene en la capa de acceso a datos.

Además, para mi aplicación, estos tipos existen en un conjunto común, por lo que se pueden reutilizar entre cualquier nivel, no solo entre los niveles comerciales y de datos.

arquitectónico Fit

No hay nada particularmente especial acerca de este enfoque, que tiene sus pros y contras propios; exactamente qué son y cómo te afectan dependerá de muchas cosas, supongo que tu kilometraje variará, pero desde luego me ha sido útil durante varios años.

Las personas a menudo hacen un escándalo por la "separación de preocupaciones", y ese es un paso realmente inteligente; esto se relaciona con DTO en el sentido de que se intercambian entre capas (y servicios, componentes, etc.) por lo que siempre puede existir cierta ambigüedad sobre dónde exactamente dibujar la línea.

que toma el enfoque que si un bit de información es apto para ser intercambiados entre a niveles que probablemente es apto para ser intercambiados entre cualquier número de niveles - ¿por qué no lo hacen accesible a todos? También ahorra tener que volver a transmitir información si solo la está pasando.

En cuanto a la complejidad va - hay dos maneras de manejar que:

1. utilizar una convención verbosa/legible nomenclatura para todos; los tipos para que sepas qué son las cosas; no importa cuántos hay, para eso sirve el intelli-sense (& documentos). Cuanto más intuitivo, mejor.
2. BESO - mantenga las cosas simples si puede; tendrá que equilibrar la reutilización sensible y el Principio de Responsabilidad Individual (SRP).

crearía un DTO de un complejo propiedad de una entidad principal?

me he encontrado haciendo DTO para una de 2 razones:

1. Hay datos Sé que necesito para exponer (push), y el diseño de la DTO es una obviedad: es conducido por los datos que quiero exponer
2. Pull: el consumidor sabe lo que quiere, y el DTO está diseñado para satisfacer esas necesidades.

Dado que todos están definidos en un conjunto común, ningún componente "lo posee", lo ayuda a forzarlo a pensar desde una perspectiva de "dominio" en lugar de uno centrado en componentes; en cierta medida, esto influirá en el diseño de los DTO (balanceo de reutilización vs SRP).

En ambos casos, las DTO pueden ser silenciosas específicas para una necesidad particular, o genéricas; Por ejemplo, una DTO que tiene solo un int y una cadena no es poco común, es el tipo de cosa que usaría para enviar a listas desplegables.

La mayoría de las colecciones de DTO que envío (de DAL a BL) son específicas de un concepto, no genérico. Implico reglas muy muy básicas sobre estos a través de los constructores que ofrezco: se requiere cada arg. No estoy seguro de si esto responde a su pregunta "¿Cómo se gestiona el montaje y la validación?".

Answer 2

La idea de que la capa de servicio debe devolver objetos DTO en lugar de objetos EJB es principalmente una idea anterior a la era EJB3/JPA. Durante CRUD realmente ganas mucho trabajando directamente con los objetos modelo (entidades a.k.a.).

Sin embargo, puede beneficiarse del uso de DTO cuando se utiliza para optimizar el rendimiento, por ejemplo, cuando los objetos del modelo son demasiado voluminosos o cuando se obtiene el uso de algunas combinaciones inteligentes para agregar datos del modelo.

Así que a menos que esté bajo la ingeniería SOA, que no recomendaría trabajar con DTO para las operaciones CRUD.

Answer 3

¿Ha considerado una consulta de comandos separación de responsabilidad (CQRS) principio? En pocas palabras, es un principio arquitectónico que aboga por el uso de componentes separados para operaciones de lectura y modificación.

Las modificaciones se realizaron utilizando comandos enviados al modelo de dominio. Su NewCarLeaseDTO se parece a un comando - CreateNewCarLeaseCommand. Contienen todos los datos necesarios para una operación en particular.

Por otro lado, se lee (ya sea por lista o detalle compite) se realizan directamente en el almacén de datos subyacente (base de datos SQL). Aquí hay muchas posibilidades, que van desde tener el mismo almacén de datos para respaldar las partes de lectura y escritura hasta tener dos almacenes de datos independientes conectados mediante la infraestructura de publicación/suscripción.

Cuando se utiliza el enfoque de este último (dos tiendas) para leer lado, muchos (como Udi Dahan) abogar utilizando los llamados puntos de vista persistentes. Significa almacenar datos directamente en el formulario consumible según sus vistas. La transformación (desnormalización) se realiza al sincronizar después de la actualización del modelo.

Si desea obtener más información sobre CQRS, recomiendo la lectura de Udi Dahan y Greg Young.