ViewModel и Domain Model: Границы ответственности

ASP.NET MVC завоевывает всё большую популярность среди .NET программистов. Вместе с тем с развитием сообщества и наработкой знаний за счет реализации проектов у разработчиков начали возникать вопросы. Что есть MVC, в чем суть каждой его части? Как избавиться от дублирования в коде контроллеров при реализации одинаковых операций? Как проще сделать валидацию? Где описывать валидацию? Как MVC сочетается с DDD? И многое другое.

Я бы хотел рассмотреть самый главный вопрос, который, как мне кажется, является основой для понимания шаблона проектирования MVC и его реализации в .NET Framework.

Вопрос в том, что же считать моделью (M-VC)? Есть разные мнения по этому поводу. Два основных заключаются в следующем:

• ViewModel == Domain Model - на View надо передавать доменные объекты
• ViewModel != Domain Model - На View надо передавать специально сформированные для этой View объекты.

Классы, которые формируются специально для View, я буду называть Model или ViewModel.

Я хочу рассмотреть оба варианта в разных сценариях использования системы. В конце сделаю выводы по выбору одного или другого решения.

ViewModel == Domain Model

Первый вариант, когда доменные объекты передаются сразу на View:

Сценарий использования

У нас есть страница с отображением деталей статьи. Пользователь вводит http://www.mysite.com/Post/Details/25. Мы запрашиваем статью с ID = 25, например, из PostRepository. Получаем доменный объект Post и передаем его на View, где в HTML отображаем все необходимые поля.

ViewModel != Domain Model

Второй вариант, когда на View передаются специальные объекты, которые являются моделью и описываются в границах MVC-приложения:

Сценарий использования

У нас есть страница с отображением деталей статьи. Пользователь вводит http://www.mysite.com/Post/Details/25. Мы запрашиваем статью с ID = 25, например, из PostRepository. Получаем доменный объект Post или DTO объект. Формируем объект PostViewModel и передаем его на View, где в HTML отображаем все необходимые поля.

Применение в реальной жизни

Комбинированная модель

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

Сценарий: пользователь зашел на список статей, где есть листалка по страницам. Во View нам надо передать не просто IEnumerable, а дополнительные данные PageIndex, PageCount, чтобы отобразить текущую страницу и общее кол-во страниц:

public class PostListViewModel
{
    public IEnumerable<Post> ItemsForPage { get; set; }
    public int PageIndex { get; set; }
    public int PageCount { get; set; }
}

Как видно, передать просто список доменных объектов уже не получается, поэтому мы начинаем идти по второму варианту - формируем специальный объект для View.

Сценарий: пользователь зашел на детали статьи, где кроме самой статьи отображается подробная информация об авторе. Суть в том, что нам нужно передавать уже не один доменный объект, а сразу несколько. В этом случае у нас нет выбора, мы создаем отдельный класс - Model - для View:

public class PostDetailsViewModel
{
    public Post Post { get; set; }
    public User User { get; set; }
}

Сценарий: пользователь зашел на детали статьи, если он является автором, то сможет удалять статью. Здесь нам надо передать на View некий атрибут, который является рассчитываемым. Важно заметить, что это поле не имеет значения в самом домене, оно важно только для отображения. Поэтому переносить подобные поля в домен не надо. Если изначально мы передавали в нашу View доменный объект Post, то теперь сделаем отдельную Model:

public class PostDetailsViewModel
{
    public Post Post { get; set; }
    public bool IsContextUserPostAuthor{ get; set; }
}

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

Что в этом случае представляет собой модель данных? Это будет объект, который содержит некоторые данные пользователей, некоторые данные ролей и некоторые данные о продуктах. Это может быть имя пользователя, причем для этого отображения имя берется, как логин + ID, кол-во продуктов, купленных пользователем в определенный период и т.д. Этот набор данных формируется, исходя из требований к модели для отображения данных.

Как мы видим, даже если мы начинали передавать во View просто доменный объект, то в итоге, мы формируем специальные классы - ViewModel, которые не содержат в себе доменных объектов.

ORM, LazyLoad и генерация объектов

Вы используете ORM, которая генерирует объекты по БД? Если вы передаете эти объекты прямо во View, то возможно ли в отображении данных сделать:

// поле IsDirty генерируется ORM и является публичным в сущности
@post.IsDirty

// здесь произойдет запрос за счет LazyLoad
@post.Comments.Where(x => x.IsDeleted == false) 

В первом случае мы связываем себя с ORM так сильно, что придется потратить много времени на переход к другому способу сохранения данных. IsDirty - это только пример, многие ORM грешат генерацией "своих" полей в доменные объекты.

Ничего не мешает написать такой код, который во View подгрузит комментарии и выберет из них те, что не удалены. Теперь наше бизнес-правило "к статье относятся только не удаленные комментарии" начинает жить в отображении данных. Думаю, что не надо останавливаться на том, почему это плохо и чем грозит. Даже если LazyLoad не включен, то подобный код можно написать, размазав тем самым бизнес-логику по всему приложению.

ViewModel решают эту проблему, потому что содержат только те поля, которые нужно отобразить во View.

Валидация

Как мы делаем валидацию для отображения в ASP.NET MVC? Есть два самых распространенных способа.

Первый предлагается нам, когда мы создаем новый проект ASP.NET MVC в Visual Studio. На модель навешиваются атрибуты валидации, которые лежать в DataAnnotations. ASP.NET умеет подхватывать эти атрибуты и делать по ним клиентскую и серверную валидацию.

Если вы передаете во View доменный объект, то получается, что эти атрибуты валидации надо писать прямо в него? Т.е. ваши доменные объекты обрастут атрибутами для валидации из слоя UI. Что же делать, если для одного и того же поля в доменном объекте на разных View надо делать разную валидацию?

Второй способ - это описание метаданных для модели с помощью MvcExtensions. Здесь мы можем описывать метаданных не трогая модель в отдельном классе, который унаследован от ModelMetadataConfiguration.

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

Формирование ViewModel

ViewModel чаще всего формируются из доменных объектов, поэтому процесс сопоставления полей может быть очень утомительным. Если в Post и PostViewModel совпадают 5-6 полей, то придется вручную брать поля из Post и присваить их соответствующим полям из PostViewModel.

Для того, чтобы избавиться от рутины, лучше всего подойдет Automapper.

Выводы

Если подвести итог, то модель в MVC и доменная модель "играют за разные команды".

Передавать объекты, которые описывают ваш домен, напрямую в отображение можно только в очень простых CRUD приложения, которые никогда никто не будет развивать.

В корпоративных системах ASP.NET MVC обычно является одной из частей инфраструктуры. Общая схема взаимосвязи домена и приложений должна выглядеть так:

Сам домен не должен зависеть от любых периферийных приложений. Они не должны навязывать доменным объектам свои атрибуты, поля или методы.

С другой стороны никакое приложение не должно зависеть напрямую от домена. Это значительно упростит работу по рефакторингу и любым манипуляциям с доменом. Плюс сами приложения становятся более подвижны. Их, например, легко можно заменить сервисом или облаком.

Ниже я привел ссылки на источники, в которых эта тема рассматривается с разных точек зрения.

---

Обсуждения

DotNetConf: Model (M-VC) != Domain Model

StackOverflow: Why Two Classes, View Model and Domain Model?

StackOverflow: View and Domain model, where to perform calculation

StackOverflow: Bestpractice - Mixing View Model with Domain Model

StackOverflow: ASP.NET MVC: ViewModels versus Domain Entities

---

Ссылки

Separated Presentation, Martin Fowler

GUI Architectures, Martin Fowler

To Model Or ViewModel, That Is the Question, Jeffrey Palermo

Pros and Cons of Data Transfer Objects, Dino Esposito

How we do MVC – View models, Jimmy Bogard