ASP.NET MVC - отображение с помощью Automapper

Question

В настоящее время я пытаюсь выяснить, когда использовать ViewModels, а когда нет.Я использую Automapper для этой задачи и в настоящее время имею следующий код:

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

Мне интересно, является ли плохой практикой такое отображение, просто исключать некоторые свойства из модели предметной области?- И я должен всегда использовать View Models, даже когда он не нужен?

Заранее спасибо.

Answer 1

Короче говоря, да, вы всегда должны использовать ViewModel.

Мы используем AutoMapper в нашем проекте, и изначально мы не предоставляли отдельные ViewModel для каждого вида.Мы обнаружили, что у нас возникли некоторые проблемы с производительностью, которые возникли, если объекты имеют ссылки друг на друга (т. Е. У пользователя есть логины с ролями, у которых есть пользователи).AutoMapper не знал, когда прекратить создавать эти коллекции.

Хотя это не было проблемой на простых страницах, таких как в вашем примере, мы решили создать ViewModel для каждого View, который предоставил бы только свойства, необходимые этой ViewModel.Это решило проблемы с разрешениями, а также упростило просмотр информации, которая требуется представлению.

Джимми Богард говорит о том, как использовать этот метод в блоге: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx

Answer 2

Вот отличная статья об AutoMapper и ViewModels
http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx

Некоторые ключевые моменты.

Ваш вопрос should I always use View Models, even when not needed?

Комментарий к сообщению в блогеговорит

Доменные объекты разработаны для нужд доменной модели и представляют домен наших приложений.С другой стороны, объекты View Model, разработанные для наших нужд для представлений.

А вот как он описывает использование автомпера.Я думаю, что идея AutoMapper заключается в том, что он будет отображать то, что он может, основываясь на именах свойств.

[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

В моем не столь обширном опыте эмпирическое правило выглядит следующим образом:

• Для представлений, которые отображают модель домена как есть (например, запись перед нажатием кнопки «Изменить»).), чем вы можете просто использовать свою простую модель.Хотя это не мешает вам создавать другой класс, который просто расширяет вашу модель предметной области, поэтому в будущем вам не нужно прикасаться как к контроллеру, так и к представлению.
• В остальных случаях:ViewModels.Вот несколько причин, по которым
  • Если у вас есть итоги (например, количество учеников в классе), вместо того, чтобы вычислять их в представлении, у ViewModel должен быть собственный метод.
  • Разбиение на страницы,Обычно при отображении большого количества записей у вас есть: AllRecords или несколько стеков пагинации (например, 20, 50, 100).Модель предметной области должна просто служить бизнес-логике в целом (и не позволять вам добавлять, например, ваш номер телефона "Рыба"), но модель представления касается управления состоянием представления

Так что я думаю, да, вроде всегда