Estoy basando esta pregunta en Fowler PoEAA. Dado su conocimiento de este texto, ¿no son los ViewModels utilizados en ASP.NET MVC los mismos que los DTO? ¿Por qué o por qué no? Gracias.¿cuál es la diferencia entre un modelo de vista y un objeto de transferencia de datos?
Sirven para un propósito similar (encapsulando datos para otra capa de la aplicación) pero lo hacen de manera diferente y por diferentes razones.
El propósito de un DTO es reducir el número de llamadas entre los niveles de una aplicación, especialmente cuando esas llamadas son caros (por ejemplo, sistemas distribuidos). Los DTO son casi siempre trivialmente serializables, y casi nunca contienen ningún comportamiento.
Por ejemplo, está desarrollando un sitio de comercio electrónico. CreateCustomer y AddCustomerAddress son operaciones separadas a nivel de base de datos, pero es posible que por razones de rendimiento que desee agregar sus datos en un NewCustomerWithAddressDto para que su cliente sólo necesita hacer una ida y vuelta al servidor, y no necesita preocuparse de que la servidor podría estar haciendo muchas cosas diferentes con el paquete de datos.
El término "modelo de vista" significa cosas ligeramente diferentes en diferentes sabores de MV *, pero su propósito es principalmente la separación de preocupaciones. Su modelo se optimiza con frecuencia para algún fin que no sea la presentación, y es responsabilidad de ViewModel desacoplar su vista de los detalles de implementación del modelo. Además, la mayoría de los patrones de MV * aconsejan que sus Vistas sean lo más "tontas" posible, por lo que el ViewModel a veces asume la responsabilidad de la lógica de presentación.
Por ejemplo, en la misma aplicación de comercio electrónico, su CustomerModel es la "forma" incorrecta para la presentación en su vista de "Cliente nuevo". Para empezar, su Vista tiene dos campos de formulario para que su usuario ingrese y confirme su contraseña, ¡y su CustomerModel no contiene ningún campo de contraseña! Su NewCustomerViewModel contendrá esos campos y podría, dependiendo de su sabor de MV *, ser responsable de alguna lógica de presentación (por ejemplo, para mostrar u ocultar partes de la vista) y validación básica (por ejemplo, asegurarse de que coincidan ambos campos de contraseña).
El propósito es diferente:
Por lo tanto, normalmente ViewModels contiene los datos de presentación, que en muchos casos es similar a lo que está en un DTO, pero con algunas diferencias. Piense en la representación de enumeraciones, localización, moneda, formatos de fecha, .... Esto es porque normalmente no debería haber lógica en su vista.
dtos en MVVM y MVP son por lo general muy objetos mudos y son, básicamente, sólo un grupo de emisores de propiedad y los captadores. ViewModels por otro lado puede tener algún comportamiento.
Un efecto secundario positivo práctica de tener DTO es permitir la serialización más fácil. Si tiene un objeto bastante complejo, digamos C#, a menudo tendrá que apagar selectivamente las cosas que no desea serializar. Esto puede ser bastante feo y los DTO simplifican este proceso.
+1, la diferencia clave es que los DTO son estúpidos (y, por lo tanto, serializables trivialmente, que es su * trabajo *), y ViewModels puede contener lógica que de otra manera hubiera entrado en su vista (que es * su * trabajo). –
@Igor Zevaka ¿Puede explicar qué quiere decir con comportamiento? –
Un modelo de vista y un objeto de transferencia de datos tiene similitudes y diferencias.
similares: Transferencia de datos en un registro (instancia de objeto, tal vez con número de serie) a un receptor, ya sea una vista o un servicio
Diferencia: una vista de modelo está destinado a ser enviado a una vista, en donde se mostrará, con formato. Un modelo de vista también devuelve datos a un controlador. Un DTO generalmente no es para presentación. Está destinado a enviar datos brutos.
¡Esa es una excelente explicación! Hasta ahora, los únicos modelos de vista que había visto solo tenían getters y setters, así que era como: wow, eso es muy parecido a un DTO. Gracias por aclarar esto para mí. – mkelley33