asp.net - pages - view mvc asp net

Patrón ASP.NET MVC ViewModel

Question

EDITAR: Hice algo mucho mejor para llenar y leer datos de una vista usando ViewModels , llamado ValueInjecter . http://valueinjecter.codeplex.com/

es usado por http://prodinner.codeplex.com - una aplicación de muestra MVC de ASP.net

puede ver la mejor forma de usar ViewModels en prodinner

usar ViewModel para almacenar la lógica de mapeo no fue una buena idea porque hubo repetición y violación de SRP, pero ahora con ValueInjecter tengo ViewModels limpios y código de mapeo en seco

Eso es lo viejo, no lo uses:
Hice un patrón de ViewModel para editar cosas en asp.net mvc. Este patrón es útil cuando tienes que crear un formulario para editar una entidad y debes colocar en el formulario algunas listas desplegables para que el usuario elija algunos valores.

    public class OrganisationBadViewModel
    {
        //paramterless constructor required, cuz we are gonna get an OrganisationViewModel object from the form in the post save method
        public OrganisationViewModel() : this(new Organisation()) {}
        public OrganisationViewModel(Organisation o)
        {
            Organisation = o;
            Country = new SelectList(LookupFacade.Country.GetAll(), "ID", "Description", CountryKey);  
        }       
        //that''s the Type for whom i create the viewmodel
        public Organisation Organisation { get; set; }
...     

    }

Answer 1

Comenzamos a hacer esto, pero nuestros controladores comenzaron a volverse monstruosos (ya que nuestros Modelos de Vista no estaban necesariamente mapeados 1: 1 en nuestra base de datos). Para aliviar esto, creamos clases de Mapper que crean ViewModel y luego hacemos un mapa de regreso a datos vinculados a la base de datos. El controlador simplemente llama a los métodos de la clase Mapper. Parece que funciona bien.

Answer 2

En general, creo que se ve bien, y generalmente es una buena idea crear viewmodels para sus objetos de dominio.

No he analizado todas las líneas de código, pero una cosa que me llamó la atención fueron los constructores de OrganisationViewModel. Lo reescribiría usando:

public OrganisationViewModel() : this(new Organisation()) { }

public OrganisationViewModel(Organisation o)
{
  Organisation = o;
  InitCollections();
}

Esto elimina algún código duplicado, ya que no tiene que llamar a InitCollections() en ambos constructores. Por supuesto, esto es solo un detalle menor, y no tiene nada que ver con la idea general.

Answer 3

Esto se ve muy similar a la práctica recomendada en el libro Wrox Professional ASP.NET MVC , cuyo primer capítulo está disponible de forma gratuita desde la URL anterior.

A partir de la página 100 tienen una sección en ViewData y ViewModels .

Cuando una clase de controlador decide presentar una respuesta HTML a un cliente, es responsable de pasar explícitamente a la plantilla de vista todos los datos necesarios para procesar la respuesta. Las plantillas de vista nunca deben realizar ninguna recuperación de datos o lógica de aplicación, y en su lugar deben limitarse a tener solo un código de representación que sea expulsado del modelo / datos que le haya pasado el controlador.

[...]

Al utilizar [el modelo "ViewModel"], creamos clases fuertemente tipadas que están optimizadas para nuestros escenarios de vista específicos, y que exponen propiedades para los valores / contenido dinámico que necesitan nuestras plantillas de vista. Nuestras clases de controlador pueden llenar y pasar estas clases optimizadas para visualización a nuestra plantilla de vista para usar. Esto permite la seguridad de tipos, la verificación en tiempo de compilación y el editor intellisense en las plantillas de visualización.

Tomado de "Capítulo 1" Nerd Dinner "de Professional ASP.NET MVC 1.0 escrito por Rob Connery y otros publicado por Wrox". El original está disponible en http://tinyurl.com/aspnetmvc

Answer 4

Hay un par de cosas que me molestan.

1. La terminología. ViewModel es este caso es una simple vista de datos que se llena y más tarde se consume por el controlador. La vista no sabe nada sobre el controlador ya que la infraestructura ASP.NET MVC es responsable de seleccionar los controladores y las acciones apropiadas. El controlador maneja la interacción del usuario. Creo que se parece más a una vista pasiva que a un modelo de vista (supongo que con ViewModel te refieres al modelo Model-View-ViewModel).

2. Los detalles. El controlador que llena los datos de vista no debe saber los detalles de cómo se implementa la vista. Sin embargo, OrganisationViewModel.Country revela detalles innecesarios (SelectListItem es puro detalle de implementación de vistas). Por lo tanto, hacer que el controlador dependa de los detalles de implementación de vista. Creo que debería cambiarse para evitarlo. Considere usar algún objeto que contenga los datos de un país.

Espero que esto ayude.