DTO = ViewModel?

Question

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

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

Mi pregunta: ¿Son los objetos de transferencia de datos y ViewModels lo mismo? ¿O es ViewModel un tipo de subpatrón de un DTO?

Answer 1

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

ViewModels es el modelo de la vista. ViewModels normalmente son 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 se mueven elementos de vista, etc. ...). Puede ver el modelo de vista como todos los datos para una vista más comportamientos. ViewModels puede o no correlacionar uno a uno con objetos comerciales o DTO.

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

Answer 2

Para algunas vistas simples, usaré mi DTO como mis modelos, pero a medida que Views se vuelva más complejo, crearé ViewModels.

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

Answer 3

DTO! = ViewModel

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

Answer 4

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

Generalmente DTO se utilizan para enviar datos de una capa a otra capa a través de limites de proceso ya que las llamadas a un servicio remoto pueden ser costosas así que todos los datos necesarios se transfieren al cliente en un pedazo (grano grueso))

Sin embargo, algunas personas usan la noción de DTO enlazados a la pantalla (nada que ver con los límites del proceso de cruce). De nuevo, 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 sencillos como ya se ha indicado esta DTO se puede utilizar para la unión a la vista, pero en casos más complejos que requeriría la creación de un modelo de vista y descarga de datos de DTO a ViewModel que es obviamente más trabajo (al aplicar el patrón MVVM).

Así que de nuevo como se ha dicho DTO! = ViewModel

y

DTO y ViewModel tienen diferentes propósitos en la vida

Answer 5

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

Answer 6

En primer lugar, la principal diferencia es que ViewModel puede tener un comportamiento o métodos que DTO no debe tener !!!

En segundo lugar, el uso de DTO como un modelo de vista en ASP.NET MVC hace que su aplicación se conecte estrechamente a DTO y ese es exactamente el propósito opuesto de usar DTO. Si lo hace, ¿cuál es la diferencia al usar su modelo de dominio o DTO, más complejidad para obtener un antipatrón?

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

El mismo DTO puede tener diferentes Asignaciones de ViewModels, y One ViewModel se puede componer desde diferentes DTO (siempre con mapeo de objetos sin composición). porque creo que es aún peor si tienes 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 el servicio, el dto y las capas de presentación son suyas).

Finalmente, si hace esta separación limpia, los desarrolladores pueden trabajar juntos con facilidad. La persona que diseña ViewModels, Views y Controllers no tiene que preocuparse por la capa de servicio o la implementación de DTO porque hará la asignación cuando los otros desarrolladores terminen su implementación ... Incluso puede usar la herramienta de burla o burla manual para llenar la capa de presentación con datos para prueba.

Answer 7

si va a utilizar DTO como ViewModel, eso significa que está haciendo depender mucho de DTO debido a alguna razón por la que está cambiando DTO, entonces podría afectar a ViewModel.

Mejor uso DTO & convertir en viewmodel.