DTO = ViewModel?

Estoy usando NHibernate para conservar los objetos de mi dominio. Para simplificar las cosas, estoy usando un proyecto ASP.NET MVC como capa de presentación y capa de servicio.

Quiero devolver mis objetos de dominio en XML desde mis clases de controlador. Después de leer algunas publicaciones aquí en Stack Overflow, creo que los DTO son el camino a seguir. Sin embargo, también me he encontrado con publicaciones que hablan sobre ViewModel.

Mi pregunta: ¿Los objetos de transferencia de datos y los modelos de vista son lo mismo? ¿O es un ViewModel una especie de subpatrón de un DTO?

La definición canónica de un DTO es la forma de datos de un objeto sin ningún comportamiento.

ViewModels son el modelo de la vista. Los ViewModels suelen ser datos completos o parciales de uno o más objetos (o DTO) más cualquier miembro adicional específico del comportamiento de la vista (métodos que la vista puede ejecutar, propiedades para indicar cómo alternar los elementos de la vista, etc.). Puede ver el modelo de vista como todos los datos de una vista más comportamientos. ViewModels puede o no mapear uno a uno a objetos comerciales o DTO.

Por cierto, las proyecciones de NHibernate son útiles si un determinado modelo de vista necesita un subconjunto de los datos de un objeto persistente.

La práctica ViewModel en ASP.NET MVC es la misma que en DTO, sin embargo, ViewModel en el patrón MVVM es diferente de DTO porque ViewModel en MVVM tiene comportamientos pero DTO no.

DTO! = ViewModel

En el patrón MVVM , ViewModel se usa para aislar el modelo de la vista. Para representar el modelo, puede usar clases DTO simples , que nuevamente se asignan a una base de datos a través de, por ejemplo, NHibernate. Pero nunca he visto una clase ViewModel que esté modelada como un DTO. Las clases ViewModel en su mayoría tienen comportamiento, que los DTO no tienen.

DTO: los objetos de transferencia de datos son exactamente como dice, contenedores para transferir datos. No tienen comportamiento, sino simplemente un grupo de setters y getters. Algunas personas los hacen inmutables y simplemente crean nuevos cuando es necesario en lugar de actualizar los existentes. Deben ser serializables para permitir la transferencia a través del cable.

Generalmente, los DTO se utilizan para enviar datos de una capa a otra a través de los límites del proceso, ya que las llamadas a un servicio remoto pueden ser costosas, por lo que todos los datos necesarios se envían a un DTO y se transfieren al cliente en un solo fragmento (granulado grueso).

Sin embargo, algunas personas usan la noción de DTO vinculados a la pantalla (nada que ver con cruzar los límites del proceso). Nuevamente, estos se completan con los datos requeridos (generalmente los datos requeridos para una pantalla en particular y podrían ser una agregación de datos de varias fuentes) y se envían al cliente.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

En casos simples, como ya se ha dicho, este DTO se puede usar para enlazar a la vista, pero en casos más complejos requeriría la creación de un ViewModel y la descarga de datos de DTO a ViewModel, lo que obviamente es más trabajo (cuando se aplica el patrón MVVM) .

Así que de nuevo como ya se dijo DTO! = ViewModel

y

DTO y ViewModel tienen diferentes propósitos en la vida

Primero, la principal diferencia es que ViewModel puede tener comportamientos o métodos que DTO no debe.

En segundo lugar, el uso de DTO como ViewModel en ASP.NET MVC hace que su aplicación esté estrechamente acoplada a DTO y ese es exactamente el propósito opuesto al uso de DTO. Si lo hace, ¿cuál es la diferencia usando su modelo de dominio o DTO, más complejidad para obtener un anti-patrón?

También ViewModel en ASP.NET puede usar DataAnnotations para la validación.

El mismo DTO puede tener diferentes ViewModels Mapping, y One ViewModel puede estar compuesto de diferentes DTO (siempre con mapeo de objetos, no composición). porque creo que es aún peor si tiene un ViewModel que contiene un DTO, tendremos el mismo problema.

Desde su capa de presentación, piense en DTO como un contrato, recibirá un objeto que debe considerar como extraño para su aplicación y no tiene ningún control sobre él (incluso si tiene ex el servicio, el dto y las capas de presentación son tuyos).

Finalmente, si realiza esta separación limpia, los desarrolladores pueden trabajar juntos con facilidad. La persona que diseña ViewModels, Vistas y Controladores no tiene que preocuparse por la capa de servicio o la implementación de DTO porque hará el mapeo cuando los demás desarrolladores terminen su implementación ... Incluso puede usar la herramienta Mocking o la simulación manual para completar la capa de presentación con datos para prueba.

Para algunas vistas simples, usaré mi DTO como mis modelos, pero a medida que las Vistas se vuelvan más complejas, crearé ViewModels.

Para mí es un equilibrio entre rapidez (usando DTO, ya que ya los tengo) y flexibilidad (crear ViewModels significa más separación de preocupaciones).

Si va a utilizar DTO como ViewModel, eso significa que está haciendo una gran dependencia de DTO debido a alguna razón por la que está cambiando DTO, entonces podría afectar a ViewModel.

Mejor use DTO y conviértalo en modelo de vista.

Podemos usar DTOigual que la clase Model y podemos usar viewmodel cuando necesitamos mostrar / usar múltiples datos / propiedades de modelos en una sola vista. Ejemplo: primero creo un modelo usando la base de datos del marco de la entidad. Entonces, ahora todo el modelo se genera en función de la base de datos. y ahora necesitamos la anotación de datos, para esa anotación de datos podemos crear una carpeta con el nombre DTO. En esta carpeta DTO, podemos mantener exactos todos los modelos que ya generan y agregar anotaciones de datos encima de la propiedad. Entonces podemos usar cualquier operación (usar controlador, vistas) usando estas clases DTO. Y cuando necesitamos una vista compleja, me refiero a que cuando necesitamos datos de varias clases en una vista, podemos usar viewmodel. Para viewmodel podemos crear un nombre de carpeta viewmodel, luego crear una clase personalizada y mantener esa propiedad que necesitamos. Traté de aclararme. Cualquier sugerencia muy apreciada.