Question

I’m currently trying to figure out when to use ViewModels and when not to. I’m using Automapper for the task and currently have the following code:

// 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));
}

I’m wondering whether its bad practice to map like this just to exclude some properties from the domain model? – And should I always use View Models, even when not needed?

Thanks in advance.

Answer 1

In short, yes you should always use a ViewModel.

We use AutoMapper on our project and initially we did not provide separate ViewModels for each view. We found that we had some performance issues that cropped up if objects have references to each other (i.e. User has Logins which have Roles which have Users). AutoMapper didn’t know when to stop building up these collections.

While this was not a problem on simple pages, such as the one in your example, we decided to create a ViewModel for each View that provided only the properties neede by that ViewModel. This resolved the permissions issues and also makes it very easy to see the information the View requires.

Jimmy Bogard talks about following this method in a blog post: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx