Objeto DTO o modelo de dominio en la capa de vista?

Question

Sé que esto es probablemente una vieja pregunta, pero ¿cuál es la mejor práctica? El uso de un objeto de modelo de dominio a través de todas las capas de su aplicación, e incluso los valores uniéndose directamente a ellos en la JSP (estoy usando JSF). O convertir un objeto de modelo de dominio en un DTO en la capa DAO o servicio y enviar un DTO ligero para la capa de presentación.

Me han dicho que no tiene sentido a dtos uso debido a los cambios en la base de datos dará lugar a cambios en todas sus dtos mientras que utilizando el Modelo de objetos de todo el mundo se acaba de requerir cambios en el modelo de objetos afectada. Sin embargo, la facilidad de uso y la naturaleza ligera de dtos parece ser mayor que eso.

debe tener en cuenta que los objetos usos mi aplicación Hibernate modelo y utiliza sus propios objetos personalizados creados por el modelo (que significa no ligadas a ninguna sesión de base de datos, siempre separado). Es uno de los escenarios anteriores más beneficioso a un estricto patrón de modelo de objetos? Usando Hibernate ha sido un gran PITA con respecto a cosas como excepciones perezoso de inicialización.

Estoy editando esta pregunta con la esperanza de promover la discusión (no estoy seguro si estoy haciendo este derecho):

El problema que tengo con los objetos del modelo es que no son flexibles en absoluto. Un comentario más abajo dice que la aplicación debe estar diseñado de manera que los objetos del modelo se pueden utilizar en todos los estratos. ¿Por qué? Si un usuario quiere un pedazo de funcionalidad ridícula, se supone que voy a decir, 'así que no funcionarán con los objetos del modelo'?

Así de simple, hay veces cuando sólo los objetos del modelo no funcionará. Es posible que tenga:

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 usted no necesita toda esa información. Sólo se necesita el apellido del maestro, el número de estudiantes es que enseñan este año, y el puntaje promedio para todos los estudiantes combinados. ¿Qué haría usted en ese caso? Recuperar las relaciones llenas de información maestro y estudiante y luego su código obtiene un recuento en la lista de los estudiantes, a continuación, calcula un promedio total de todos los promedios en el interior? Eso parece como waaaay más esfuerzo que la simple creación de un DTO con 'Cadena lastName', 'numStudents int', y 'doble combinedGpa;

Puede sonar como mi mente se ha hecho sobre estos, pero todavía tengo que trabajar en una aplicación donde los objetos del modelo se pueden utilizar completamente limpia en todos los casos. aplicaciones del mundo real regulares con fuera de lo común de usuario demandas simplemente no funciona de esa manera.

Answer 1

En realidad depende de la complejidad de su aplicación. Mezcla de objetos de dominio en la capa de vista tiene dos implicaciones posibles:

1. tendrá la tentación de modificar su objeto de dominio para acomodar cosas que hay en la capa de vista
2. Su capa de la vista contendrá una complejidad adicional causada por una falta de correspondencia entre lo que sus objetos de dominio ofrecen y lo que realmente necesita su punto de vista. Puede que no seas capaz de obtener en torno a esta complejidad, pero es probable que no pertenecen a la capa de la vista.

Si los objetos de dominio son simples y sus vistas son pocos, omitiendo los dtos podría ser la cosa más simple.

Por otro lado, si su modelo de dominio es probable que evolucionar y llegar a ser complejos y si sus puntos de vista son propensos a ser numerosas y variadas, teniendo objetos vista específicos podrían ser una buena idea. En el mundo MVC, utilizando ViewModels es común y tiene mucho sentido para mí.

Answer 2

Otro voto para los objetos de dominio. En cuanto a dominio Driven Design se refiere al modelo de dominio es el rey y se debe utilizar siempre que sea posible. La aplicación debe ser diseñado de una manera donde la mayoría de las capas (capa de infraestructura bar) pueden utilizar objetos de dominio.

pienso en dtos como útil solamente donde los objetos tienen que ser serializado. Si no hay transferencia a través del cable o en una arquitectura incompatibles yo no los uso. patrón DTO es útil para mantener la serialización del objeto de dominio. Teniendo en cuenta que la interacción UI / dominio no necesita serialización, que sea sencillo y utilizar los objetos reales.

Answer 3

Creo que tener DTO no es generalmente un patrón contra. Hay una gran cantidad de personas y sistemas que utilizan ellos y el beneficio que se obtiene es la capa de vista desacoplado, que puede ser diseñado y en módulos de forma independiente a partir del modelo de dominio. Aunque estoy de acuerdo que se debe utilizar objetos de dominio que sea posible hay escenarios donde se puede obtener problemas cuando se ata la capa de vista directamente al modelo de dominio.

He hecho buenas experiencias con un modelo de vista que sólo se envuelve alrededor de los objetos de dominio y delega la mayor parte de las operaciones a them.This desacopla ver y capa de dominio, permite la composición flexible de los objetos de dominio y todavía no hay mucho trabajo para poner en práctica desde entornos de desarrollo compatibles con patrón de delegación.

Answer 4

Escenarios cuando el objeto de dominio son problemáticos para ser enviada:

1. es posible que necesite información agregada u otros tipos de campos calculados '' enviado a la capa de interfaz de usuario (en el ejemplo Flex / GWT) y no desea ensuciar el objeto de dominio
2. Es posible que encuentre una necesidad de serialización de gráfico de objetos cíclico (en su ejemplo, si el estudiante tenía relación con la lista), algunos protocolos tienen problemas con eso
3. Hibernate LazyInitializationException cuando se trata de los serializadores marco (blazeds para GWT serializador / flex)

No estoy seguro de que es una respuesta clara en aquellos cirumcstances

Answer 5

En mi opinión, no hay problema en absoluto con el uso de los objetos del modelo de dominio en cada capa. Usted ha dicho que usted no necesita toda la información. Cuando estás en las JSP, utilice sólo los datos que necesitan. Nadie te está obligando a buscar todas las propiedades. También ha dicho que es necesario hacer cálculos relacionados con las propiedades del objeto con el fin de obtener el GPA, # de estudiantes, etc Usted tiene 3 opciones: crear propiedades sintéticas en el objeto del modelo de dominio que devuelven los datos correctos para usted, envuelto agradable y ordenada; hacer los cálculos, ya sea en la capa del controlador o servicio, y exponerlos a través de los captadores apropiados; o manejar todo el interior de su JSP. Es necesario para recuperar / compilación / disputa la MODOS datos, ¿por qué añadir más complejidad con un DTO.

Además, con cada DTO, que está creando a.) Una clase extra que ahora tienen que mantener, y b.) Al menos 1 Método de alguna parte adicional de alguna clase que construye y puebla el método DTO (DAO, fábrica, etc.). Más mantenimiento = desarrollador infeliz 6 meses más tarde.

Por lo tanto, hay argumentos en contra de mis dtos. Hago uso de ellos, pero sólo en ciertos escenarios, como cuando realmente necesita para optimizar para la velocidad y / o el uso de memoria, y el costo de la hidratación de un objeto de modelo de dominio completo es demasiado. Los servicios web son un buen ejemplo de cuando yo prefiero dtos uso.

Answer 6

El comportamiento de una clase, o sus métodos internos no deben ser expuestos a las capas no se ocupan de su comportamiento. Transferir datos, no de comportamiento. Usar objetos de dominio dentro del dominio. La web no es un dominio controlado, y los desarrolladores de interfaz de usuario no tiene que estar preocupado con el comportamiento de dominio, los datos sólo.

El dominio tiene que ser encapsulados y protegidos frente a posibles modificaciones por alguien que no se ocupa de la salud del dominio.

La fuga comportamiento no es el mejor hábito.

Si se trata de un proyecto pequeño, construido con Principes correctas también. De esta manera siempre tenemos en mente por qué hacemos lo que hacemos, y no sólo la forma.

Answer 7

Creo que lo que debemos considerar aquí, en primer lugar es el costo de introducir nueva capa. Tome por ejemplo DTO - haciendo que necesitamos un mapeo. Como alguien dijo, la traducción es malo y debe evitarse siempre que sea posible.

Por otro lado creo que hay muy pocas cosas que por lo general no debe hacer. Los que dicen que todos son malos dtos están equivocados - que siempre depende del caso de uso! ¿Están realmente justificadas?

Y, por último, yo personalmente creo que los objetos de dominio deben dejar ir a la vista en sí. Imagínese lo que la integración portillo es entonces como. Pero tomar Spring MVC, por ejemplo - de dominio se quedaría entonces en la capa de aplicación, probablemente, ...

Answer 8

DTO es ampliamente considerado como un anti-patrón de hoy en día, y el consejo es por lo general "evitar a toda costa".

Una de las principales ventajas de un marco ORM como Hibernate, es que se puede utilizar objetos de dominio en todos los niveles, y hacer dtos realmente no necesita. La advertencia, por supuesto, es que usted tiene que dedicar algún tiempo a pensar sobre esas relaciones:. Cuándo utilizar la recuperación perezosa, cuándo usar ansiosos, etc.