ASP.NET MVC - Asignación con Automapper

Question

Actualmente estoy tratando de averiguar cuándo usar ViewModels y cuándo no. Estoy usando AutoMapper para la tarea y en la actualidad tiene el siguiente código:

// AccountController.cs

[AuthWhereRole(Roles = AuthorizeRole.Developer)] 
public ActionResult List() 
{ 
    MembershipUserCollection users = _memberShipService.GetAllUsers(); 
    IEnumerable<ListUsersViewModel> viewModel = 
      Mapper.Map<IEnumerable<MembershipUser>, IEnumerable<ListUsersViewModel>>(users.Cast<MembershipUser>().AsEnumerable()); 

    return View("List", viewModel); 
} 

// ListUsersViewModel.cs

public class ListUsersViewModel 
{ 
    public Guid Id { get; set; } 
    public virtual string UserName { get; set; } 
    public string LastLogOn { get; set; } 
} 

// Bootstrapper.cs

public static void ConfigureAutoMapper() 
{ 
    Mapper.CreateMap<MembershipUser, ListUsersViewModel>() 
      .ForMember(x => x.UserName, o => o.MapFrom(s => s.UserName)) 
      .ForMember(x => x.Id, o => o.MapFrom(s => s.ProviderUserKey)) 
      .ForMember(x => x.LastLogOn, o => o.MapFrom(s => s.LastLoginDate)); 
} 

Me pregunto si es una mala práctica hacer un mapa como este solo para excluir algunas propiedades de t el modelo de dominio? - ¿Y debería usar siempre View Models, incluso cuando no los necesite?

Gracias de antemano.

Answer 1

En resumen, sí, siempre se debe usar un ViewModel.

Utilizamos AutoMapper en nuestro proyecto e inicialmente no proporcionamos modelos de vista separados para cada vista. Descubrimos que tuvimos algunos problemas de rendimiento que surgieron si los objetos tienen referencias entre sí (es decir, el usuario tiene inicios de sesión que tienen funciones que tienen usuarios). AutoMapper no sabía cuándo dejar de construir estas colecciones.

Si bien esto no fue un problema en páginas simples, como la de su ejemplo, decidimos crear un ViewModel para cada Vista que proporcionara solo las propiedades necesarias para ese ViewModel. Esto resolvió los problemas de permisos y también hace que sea muy fácil ver la información que requiere la Vista.

Jimmy Bogard habla acerca de seguir este método en un blog: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx

Answer 2

Esto es un gran artículo sobre AutoMapper y ViewModels
http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx

Algunos puntos clave.

Su pregunta should I always use View Models, even when not needed?

El comentario en la entrada del blog dice

objetos de dominio están diseñados para las necesidades de modelo de dominio y se representa el dominio de nuestras aplicaciones. Por otro lado, los objetos de View Model diseñados para nuestras necesidades de vistas.

Y aquí está cómo está describiendo el uso del automapper. Creo que la idea de AutoMapper es que mapeará lo que pueda basándose en los nombres de las propiedades.

[HttpPost] 
public ActionResult Create(ContactViewModel contactToCreate) { 

if (ModelState.IsValid) { 
    Contact newContact = new Contact(); 
    AutoMapper.Mapper.Map(contactToCreate, newContact); 
    contactRepository.CreateContact(contactToCreate.GroupId, newContact); 
} 
} 

Answer 3

En mi no tan extensa experiencia, la regla general es la siguiente:

• Para las vistas que muestran el dominio Modelar como es (como un registro antes de presionar el botón "editar"), entonces solo puedes usar tu modelo simple. Sin embargo, eso no le impide crear otra clase que simplemente amplíe su Modelo de Dominio, por lo que en el futuro no tendrá que tocar tanto el Controlador como la Vista.
• Para el resto de los casos: ViewModels.Aquí hay algunas razones por las cuales
  • Si tiene totales (como el número de estudiantes en una clase), en lugar de calcular eso en la vista, ViewModel debe tener un método propio.
  • Paginación. Por lo general, cuando se muestran muchos registros, tiene: AllRecords, o algunas cantidades de pilas de paginación (20, 50, 100, por ej.). El modelo de dominio simplemente debe servir a la lógica de negocios en general (y evitar que añadir que su número de teléfono es "pescado", por ejemplo), pero el modelo de vista es que se trate de manteniendo un estado de la vista

Así que supongo, sí, tipo de siempre