Как мутировать editmodel/postmodel для модели домена

Question

В проекте ASP.NET MVC мы используем AutoMapper для сопоставления из модели домена в viewmodel, а иногда и при выравнивании иерархии. Это работает как шарм и делает логику рендеринга наших взглядов очень скудной и простой.

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

1. мы должны unflat уплощенной иерархии
2. всех свойств на модели предметной области должен быть изменяемыми/у государственных сеттера
3. вызваны изменения исходя из представления, не всегда просто плоские свойства отображаются обратно в домен, но иногда нужно вызывать методы типа «ChangeManagerForEmployee()» или аналогичные.

Это также описано в статье Джимми Bogards: The case for two-way mapping in AutoMapper, но решение этой проблемы не описано подробно, только что они идут:

От EditModel к CommandMessages - происходит от loosely- напечатано EditModel для строго типизированных, разбитых сообщений. Один EditModel может генерировать полдюжины сообщений.

В подобном SO question есть ответ на Mark Seeman, где он упоминает, что

Мы используем абстрактные картограф и услуги для отображения PostModel в объект домена

но детали - концептуальная и техническая реализация - не учитывается.

Наша идея сейчас заключается в следующем:

1. ПОЛУЧИТЕ FormCollection в методе действия контроллера
2. Получить оригинальную модель домена и придавить его viewModelOriginal и viewModelUpdated
3. сливая FormCollection в viewModelUpdated с помощью UpdateModel()
4. Используйте некоторый общий вспомогательный метод для сравнения viewModelOriginal с viewModelUpdated
5. Либо A) Создать CommandMessages а-ля Джимми Богард или B) мутировать различия непосредственно в модели предметной области с помощью свойств и методов (возможно, отображающих 1-1 свойства непосредственно через AutoMapper)

Может кто-нибудь привести несколько примеров того, как они происходят из FormCollection через editmodel/postmodel для модели домена? «CommandMessages» или «абстрактные карты и службы»?

Answer 1

Я использую следующий шаблон:

[HttpPost] 
public ActionResult Update(UpdateProductViewModel viewModel) 
{ 
    // fetch the domain model that we want to update 
    Product product = repository.Get(viewModel.Id); 

    // Use AutoMapper to update only the properties of this domain model 
    // that are also part of the view model and leave the other properties unchanged 
    AutoMapper.Map<UpdateProductViewModel, Product>(viewModel, product); 

    // Pass the domain model with updated properties to the DAL 
    repository.Update(product); 

    return RedirectToAction("Success"); 
} 

Answer 2

Вы могли бы хотеть рассмотреть CQRS (Command Query Ответственность Сегрегация - Я думаю, что это может быть концепция вы отсутствовали), возможно, даже с Event Sourcing.

Практически разделение логики чтения из источника данных и запись на источник данных может означать наличие разных моделей данных для чтения и записи.

Это может быть хорошим местом для начала: http://abdullin.com/cqrs/

Answer 3

Вариант C: Положите все это в действии контроллера. Затем, если это становится волосатым, разложитесь на службы (абстрактные mappers) или messages-as-methods (путь сообщения команд).

Command путь сообщение:

public ActionResult Save(FooSaveModel model) { 
    MessageBroker.Process(model); 

    return RedirectToAction("List"); 
} 

И процессор:

public class FooSaveModelProcessor : IMessageHandler<FooSaveModel> { 

    public void Process(FooSaveModel message) { 
     // Message handling logic here 
    } 

} 

Это действительно просто о переносе «обработки» формы из действия контроллера и в отдельных, специализированных обработчиков ,

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

Answer 4

Здесь есть некоторые сходства с тем, что я делал. Моя иерархия моделей взглядов несколько сглажена из ее эквивалентов объектов домена, но мне приходится иметь дело с вызовом явных методов обслуживания для сохранения, чтобы делать такие вещи, как добавление в дочерние коллекции, изменение важных значений и т. Д., А не просто обратное сопоставление. Мне также приходится сравнивать до и после моментальных снимков.

Мое сохранение Ajax отправлено как JSON в действие MVC и вводит это действие, магически связанное с структурой модели представления MVC. Затем я использую AutoMapper, чтобы преобразовать модель представления верхнего уровня и ее потомков обратно в свою эквивалентную структуру домена. Я определил ряд пользовательских AutoMapper ITypeConverters для тех случаев, когда новый клиентский элемент был добавлен на клиенте (я использую Knockout.js), и мне нужно вызвать явный метод службы. Что-то вроде:

  foreach (ChildViewModel childVM in viewModel.Children) 
     { 
      ChildDomainObject childDO = domainObject.Children.Where(cdo => cdo.ID.Equals(childVM.ID))).SingleOrDefault(); 
      if (childDO != null) 
      { 
       Mapper.Map<ChildViewModel, ChildDomainObject>(childVM, childDO); 
      } 
      else 
      { 
       MyService.CreateChildDO(someData, domainObject); // Supplying parent 
      } 
     } 

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

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