asp.net-mvc - son - dto or viewmodel
DTO=ViewModel? (7)
DTO! = ViewModel
En el patrón MVVM , ViewModel se usa para aislar el Modelo de la Vista. Para representar el Modelo puede usar clases de DTO simples, que de nuevo se asignan a una base de datos a través de, por ejemplo, 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.
Estoy usando NHibernate para persistir en 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 los modelos de vista lo mismo? ¿O es ViewModel un tipo de subpatrón de un DTO?
DTO: los 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.
En general, los DTO se utilizan para enviar datos de una capa a otra capa a través de límites de proceso ya que las llamadas a un servicio remoto pueden ser costosas, de modo que todos los datos requeridos se transfieren al DTO en un solo bloque (grano grueso).
Sin embargo, algunas personas usan la noción de DTO enlazados a la pantalla (nada que ver con 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 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 (al aplicar el patrón MVVM) .
De nuevo, como ya se dijo DTO! = ViewModel
y
DTO y ViewModel tienen diferentes propósitos en la vida
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 ViewModel en ASP.NET MVC hace que su aplicación se conecte estrechamente con 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 validación.
El mismo DTO puede tener diferentes asignaciones de ViewModels, y One ViewModel se puede componer a partir de diferentes DTO (siempre con mapeo de objetos, no de 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 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 haces 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.
La definición canónica de un DTO es la forma de datos de un objeto sin ningún 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, las projections NHibernate son útiles si un cierto modelo de vista necesita un subconjunto de los datos de un objeto persistente.
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 rapidez (usando DTO, ya que los tengo) y flexibilidad (la creación de ViewModels significa más separación de preocupaciones).
ViewModel en la práctica ASP.NET MVC es lo mismo que DTO, sin embargo, ViewModel en el patrón MVVM es diferente de DTO porque ViewModel en MVVM tiene comportamientos pero DTO no tiene.
si va a utilizar DTO como ViewModel, eso significa que depende mucho de DTO debido a alguna razón por la que está cambiando DTO, entonces podría afectar a ViewModel.
Es mejor usar DTO y convertirlo a viewmodel.