Как вы заполняете/проверяете свои ViewModels?

Мне любопытно, как люди создают свои модели ViewModels и почему они выбирают этот метод.

Я могу придумать несколько способов:

-1. Injected repository - контроллер загружает модель и карты в ViewModel. Здесь конструктор ViewModel может принимать различные коллекции для интерполяции для ex. в списке выбора, например:


public CustomerController(ISomeRepository repository)
{
   _repository = repository;
}

public ActionResult Create()
{
  CustomerCreateViewModel model = new CustomerCreateViewModel(_repository.GetShipTypes, 
                                                                _repository.GetStates);
..
..
}

-2. ViewModelBuilder - Либо вводится, либо инстанцируется в контроллере с экземпляром вложенного репозитория. Вызывается через что-то вроде

>var orderViewModel = orderViewModelBuilder.WithStates().Build(orderId);

или,

var orderViewModel = orderViewModelBuilder.WithStates().Build(orderId);

-3. Непосредственно в контроллере (не требуется код - его беспорядок)

-4. Некоторая другая услуга (введенная или нет), которая возвращает модель домена, которую контроллер затем сопоставляет, или ViewModel (кто делает это, чтобы вернуть модель представления, которая специально не названа/отмечена как класс Builder ViewModel?)


public JobCreateViewModel BuildJobCreateViewModel(int parentId)
{
   JobCreateViewModel model = new JobCreateViewModel();
   model.JobStatus = _unitOfWork.JobRepository.GetJobStatuses();
   model.States=_unitOfWork.StateRepository.GetAll();
   return model;
}

Теперь на обратном пути - относительно проверки ваших моделей просмотра - вы наследуете от базового класса ViewModel для стандартных проверок или копируете ваши проверки (например, атрибуты аннотации данных) между всеми вашими ViewModels или просто полагаетесь на серверную сторону валидация, чтобы все это можно было проверить снова на ваш объект домена?

Любые другие? Что-нибудь лучше? Почему?

ИЗМЕНИТЬ Основываясь на ссылке ниже, я нашел хорошую статью от Джимми Богарда по архитектуре ViewModels. В то время как он не затрагивает непосредственно вопрос, это отличная ссылка для любого, кто приходит сюда для информации ViewModel. http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

Ответ 1

Я ввожу службу в контроллер, а не в репозиторий, а затем AutoMapper, чтобы преобразовать его в модель представления. Преимущество уровня сервиса в этом случае состоит в том, что он может объединять несколько простых операций из одного или нескольких хранилищ в одну операцию, разоблачая модель домена. Пример:

private readonly ICustomerService _service;
public CustomerController(ICustomerService service)
{
    _service = service;
}

[AutoMap(typeof(Customer), typeof(CustomerViewModel))]
public ActionResult Create(int id)
{
    Customer customer = _service.GetCustomer(id);
    return View(customer);
}

в этом примере AutoMap - это настраиваемый фильтр действий, который я могу записать, который выполняется после действия контроллера, проверяет возвращаемый объект и использует определенные сопоставления AutoMapper для сопоставления его с указанным типом адресата. Таким образом, представление получает соответствующий тип CustomerViewModel в качестве типа модели. Было бы эквивалентно:

public ActionResult Create(int id)
{
    Customer customer = _service.GetCustomer(id);
    CustomerViewModel vm = Mapper.Map<Customer, CustomerViewModel>(customer);
    return View(vm);
}

это просто то, что это слишком много сантехнического и повторяющегося кода, который может быть централизован.

Я также порекомендую вам смотреть размещение ваших контроллеров на диетическом видео от Джимми Богарда.

Ответ 2

Я только что закончил проект, где мы сделали вариацию на # 4. У нас был класс обслуживания, введенный в контроллер. Класс сервиса содержит зависимости от репозитория и класс построителя модели (мы назвали его моделью factory).

Контроллер вызван в класс службы, который обрабатывает логику проверки бизнеса, а затем извлекает модели просмотра из соответствующего factory. Сами модели полагались на аннотации данных для проверки ввода.

Это хорошо работало для нашей команды. Было достаточно разделения проблем, чтобы позволить разработчикам выполнять свою работу, не затрагивая друг друга, но это было достаточно управляемо, чтобы понять, что происходит.

Это первый раз, когда мы попробовали его, и мы будем придерживаться его. Мне интересно посмотреть, как другие реагируют.

Ответ 3

Наш метод заключается в том, чтобы вставить репозиторий в контроллер и сопоставить его с ViewModel с помощью Automapper http://automapper.org/. В наших моделях ViewModels есть атрибуты аннотации данных, позволяющие выполнять проверку на клиенте.

Мы вызываем методы в репозитории, которые возвращают объекты Domain (Entity Framework). Объекты домена отображаются в ViewModel. Мы склонны использовать один и тот же ViewModel для редактирования и добавляет, поэтому аннотации данных необходимы один раз. В простейшей форме он выглядит следующим образом:

    public ActionResult List(int custId, int projId)
    {
        var users = _userRepository.GetByCustomerId(custId);
        var userList = Mapper.Map<IEnumerable<CMUser>, IEnumerable<UserListViewModel>>(users);
        return View(userList);
    }

Ответ 4

Я использую сервисный уровень, который скрывает модель домена от контроллера, возвращающего ViewModels из методов службы. Это позволяет мне вносить изменения в модель домена, не влияя на клиента.