online - DTO u objeto de modelo de dominio en la capa de vista?

modelo de dominio introduccion

Question

Sé que esta es probablemente una pregunta ancestral, pero ¿cuál es la mejor práctica? Usar un objeto de modelo de dominio en todas las capas de su aplicación, e incluso valores de enlace directamente a ellos en el JSP (estoy usando JSF). O convierta un objeto de modelo de dominio en un DTO en la capa DAO o Servicio y envíe un DTO liviano a la capa de presentación.

Me han dicho que no tiene sentido utilizar DTO porque los cambios en la base de datos darán lugar a cambios en todos sus DTO, mientras que el uso de objetos modelo en todas partes solo requerirá cambios en el objeto modelo afectado. Sin embargo, la facilidad de uso y la naturaleza liviana de los DTO parecen superar eso.

Debo señalar que mi aplicación utiliza Hibernate Model Objects AND usa sus propios objetos de modelo creados a medida (lo que significa que no están vinculados a ninguna sesión de DB, siempre separados). ¿Alguno de los escenarios anteriores es más beneficioso para un patrón de Objeto de Modelo estricto? El uso de Hibernate ha sido un gran PITA en lo que respecta a cosas como excepciones de inicialización diferida.

Estoy editando esta pregunta con la esperanza de continuar la discusión (no estoy seguro si estoy haciendo esto bien):

El problema que tengo con los objetos modelo es que no son flexibles en absoluto. Un comentario a continuación dice que la aplicación debe diseñarse de modo que los objetos modelo se puedan usar en todas las capas. ¿Por qué? Si un usuario quiere una pieza de funcionalidad ridícula, ¿se supone que debo decirles ''bueno, eso no funcionará con objetos modelo''?

Claro y simple, hay momentos en que los objetos modelo no funcionan. Puede tener:

public class Teacher {
    List<Student> students;
    [tons of other Teacher-related fields]
}
public class Student {
    double gpa;
   [tons of other Student-related fields]
}

pero tal vez no necesitas toda esa información. Solo necesita el apellido del maestro, la cantidad de alumnos que enseña este año y el promedio general de todos los alumnos combinados. ¿Qué harías en ese caso? Recupere la información completa del docente y las relaciones de los alumnos, y luego su código obtiene un recuento de la Lista de alumnos, y luego calcula el promedio total de todos los gpas. Parece mucho más esfuerzo que simplemente crear un DTO con ''String lastName'', ''int numStudents'' y ''double combinedGpa;

Puede sonar como que mi mente ha sido inventada en estos, pero todavía tengo que trabajar en una aplicación donde los objetos modelo se pueden usar completamente limpiamente en cada instancia. Las aplicaciones habituales en el mundo real con demandas de usuarios fuera de lo común simplemente no funcionan de esa manera.

Answer 1

Creo que lo que deberíamos considerar aquí en primer lugar es el costo de la introducción de nueva capa. Tome DTO por ejemplo; para eso necesitamos un mapeo. Como alguien dijo, la traducción es mala y debe evitarse siempre que sea posible.

Por otro lado, creo que hay muy pocas cosas que generalmente no debes hacer. Aquellos que dicen que todos los DTO son malvados están equivocados, ¡siempre depende del caso de uso! ¿Están realmente justificados?

Y, por último, personalmente creo que los objetos del dominio deben dejarse ir a la vista en sí. Imagine cómo es la integración del wicket. Pero tome Spring MVC, por ejemplo, el dominio se mantendría en la capa de aplicación probablemente ...

Answer 2

Creo que tener DTO no es generalmente un anti patrón. Hay muchas personas y sistemas que los utilizan y el beneficio que obtienes es la capa de vista desacoplada que se puede diseñar y modularizar independientemente del modelo de dominio. Aunque estoy de acuerdo en que debe usar objetos de dominio cuando sea posible, hay situaciones en las que puede tener problemas cuando vincula la capa de vista directamente con el modelo de dominio.

He hecho buenas experiencias con un modelo de vista que solo envuelve los objetos de dominio y les delega la mayoría de las operaciones. Esto desacopla la vista y la capa de dominio, permite una composición flexible de los objetos de dominio y aún no es mucho trabajo de implementar desde que los IDE admiten patrón de delegación.

Answer 3

DTO es ampliamente considerado un antipatrón en la actualidad, y el consejo suele ser "evitarlos a toda costa".

Una de las principales ventajas de un marco de ORM como Hibernate es que puede usar objetos de dominio en todos los niveles, y realmente no necesita DTO. La advertencia, por supuesto, es que tienes que dedicar algún tiempo a PIENSA en esas relaciones: cuándo utilizar la recuperación perezosa, cuándo usar ansioso, etc.

Answer 4

El comportamiento de una clase o sus métodos internos no deben exponerse a capas que no se preocupen por su comportamiento. Transfiere datos, no comportamiento. Use objetos de dominio dentro del dominio. La web no es un dominio controlado, y los desarrolladores de UI no necesitan preocuparse por el comportamiento del dominio, solo los datos.

El dominio debe estar encapsulado y protegido de modificaciones por parte de alguien que no se preocupe por el estado del dominio.

El comportamiento de fuga no es el mejor hábito.

Si es un proyecto pequeño, también lo construyó con los principios correctos. De esa manera siempre tenemos en cuenta por qué hacemos lo que hacemos, y no solo cómo.

Answer 5

En mi opinión, no hay ningún problema con el uso de objetos del modelo de dominio en cada capa. Usted dijo que no necesita toda la información. Cuando esté en sus JSP, use solo los datos que necesita. Nadie te está forzando a buscar todas las propiedades. También dijiste que necesitas hacer cálculos relacionados con las propiedades del objeto para obtener GPA, # de estudiantes, etc. Tienes 3 opciones: crea propiedades sintéticas en tu objeto de modelo de dominio que te devuelven los datos correctos, envueltos agradablemente y ordenado; hacer los cálculos en el controlador o capa de servicio, y exponerlos a través de los getters apropiados; o manejarlo todo dentro de su JSP. Necesita recuperar / compilar / disputar los datos DE CUALQUIER FORMA, entonces, ¿por qué agregar más complejidad con un DTO?

Además, con cada DTO, estás creando una.) Una clase extra que ahora tienes que mantener, y b) al MENOS 1 método extra en alguna clase de alguna clase que construye y rellena el DTO (DAO, método de fábrica, etc.) . Más mantenimiento = desarrollador infeliz 6 meses después.

Entonces, están mis argumentos en contra de los DTO. Los uso, pero solo en ciertos escenarios, como cuando realmente necesito optimizar la velocidad y / o el uso de memoria, y el costo de hidratar un objeto de modelo de dominio completo es demasiado. Los servicios web son un buen ejemplo de cuándo prefiero usar DTOs.

Answer 6

Escenarios cuando el objeto de dominio es problemático para ser enviado:

1. es posible que necesite información agregada u otros tipos de ''campos calculados'' enviados a la capa de la interfaz de usuario (en el ejemplo Flex / GWT) y no quiere entrometerse en el objeto de dominio
2. puede encontrar una necesidad de serializar un gráfico de objeto cíclico (en su ejemplo, si el Estudiante tiene una relación de Lista), algunos protocolos tienen problemas con eso
3. Hibernate LazyInitializationException cuando se trata de los serializadores de framework (blazeDS para el serializador flex / GWT)

No estoy seguro de que sea una respuesta clara en esas circonstancias

Answer 7

Otro voto para objetos de dominio. En lo que se refiere al Diseño Dirigido por Dominio, el modelo de dominio es el rey y debería usarse siempre que sea posible. La aplicación debe diseñarse de manera tal que la mayoría de las capas (barra Capa de infraestructura) puedan usar objetos de dominio.

Considero que los DTO son útiles solo cuando los objetos necesitan ser serializados. Si no hay transferencia a través del cable o en una arquitectura incompatible, no los usaría. El patrón DTO es útil para mantener la serialización fuera del objeto de dominio. Teniendo en cuenta que la interacción UI / Dominio no necesita serialización, manténgala simple y use los objetos reales.

Answer 8

Realmente depende de la complejidad de tu aplicación. La combinación de objetos de dominio en la capa de vista tiene dos posibles implicaciones:

1. Tendrá la tentación de modificar su objeto de dominio para acomodar las cosas que necesita en la capa de visualización
2. Su capa de Vista contendrá una complejidad adicional causada por una falta de correspondencia entre lo que ofrecen los objetos de su dominio y lo que realmente necesita su vista. Es posible que no pueda evitar esta complejidad, pero probablemente no pertenezca a la capa Ver.

Si los objetos de su dominio son simples y sus puntos de vista son pocos, omitir los DTO podría ser lo más simple.

Por otro lado, si es probable que su modelo de dominio evolucione y se vuelva complejo y si sus puntos de vista son numerosos y variados, tener una vista de objetos específicos podría ser una buena idea. En el mundo de MVC, el uso de ViewModels es común y tiene mucho sentido para mí.