Al asignar campos de ViewModel, ¿los objetos de dominio se deben pasar directamente a los objetos de ViewModel que determinarán cómo presentar los datos o si otra clase, como un servicio, debe asignar datos del Modelo al ViewModel?¿Tiene un ViewModel su propia lógica?
también:
EDIT: ¿hay algún sentido en la división de un modelo de vista en el receptor y presentador? (En lugar de vincular solo ciertos campos en la actualización?)
Normalmente, la acción del controlador toma los objetos comerciales y coloca todo lo que necesita el modelo de vista.
Si tiene un objeto comercial que contiene los campos Nombre, Dirección, Id. Y la Vista solo debe mostrar el Nombre, entonces ViewModel solo tiene un campo "Nombre" y la acción del controlador lo rellena. El ViewModel no debe saber nada sobre sus Business Classes, solo debe conocer las cosas que necesita mostrar.
La lógica principal/única es entonces "Mostrar lógica", es decir, "si TotalAmount es negativo, muéstrelo con CSS Class negativeNumber".
¿Tiene algún sentido dividir un modelo de vista en receptor y presentador? – zsharp
Tengo casi ninguna experiencia con los patrones tipo MVP, pero no veo mucha necesidad. A medida que Controller Action crea ViewModel, la parte "Receiver" solo debe contener alguna validación de la luz, y la mayor parte de la lógica de Presenter es la página de visualización real (YourView.aspx si usa el motor de visualización de WebForms predeterminado). Si está haciendo una lógica condicional pesada dentro de la clase ViewModel, tal vez debería extraerla en una clase separada (si es compartida por múltiples ViewModels). Realmente, depende de la situación, pero por lo general los ViewModels son MUY livianos. –
¿Qué pasa si la lógica para mostrar el género a la vista. Digamos que guardas M y F en la base de datos, y cuando se muestra a la vista, la lógica 'if gender.Equals (" M ") devuelve" Male "; de lo contrario, "Mujer" debería colocarse en ViewModels, Repository o cuando lo asigne a ViewModels? – Willy
Según mi experiencia, he utilizado servicios para asignar el Modelo a ViewModel. No pongo lógica en mis ViewModels.
Como un lado, es probable que valga la pena echarle un vistazo AutoMapper para ayudarle con el mapeo. Definitivamente ayuda a reducir la escritura de lógica de mapeo repetitivo.
En aras de SoC, si esa lógica se relaciona con View, es seguro que estén en ViewModel o incluso en View, pero si se relacionan con Business o Program, colóquelos en Model and Controller respectivamente.
+1, mientras que ViewModels a menudo puede ser POCOs, agregando lógica de vista para ellos donde sea necesario, a diferencia de hacerlo en el controlador, mantiene las cosas SECAS. –
Piense en ViewModels como DTO: http: //en.wikipedia.org/wiki/Data_transfer_object – ali62b