ASP.NET MVC: такие разные модели

Как известно, ASP.NET MVC основан на паттерне Model-View-Controller. Первым компонентом этого паттерна является модель, которую я бы и хотел рассмотреть сегодня поподробнее.

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

В ASP.NET MVC же модель - это несколько более широкое понятие, так как различных моделей в ASP.NET MVC не одна, а целых две. То, что мы рассмотрели выше, называется моделью предметной области, или доменной моделью (Domain Model). Однако есть еще одна модель - т.н. модель представления (View Model). Что же это такое?

View Model - это реализация одноименного подхода (или паттерна) к передаче данных в представление, который используется не только в ASP.NET MVC, но и в других местах, например, в Silverlight или WPF. View Model отличается от Domain Model тем, что он предназначен не для представления предметной области, а лишь для передачи данных из контроллера в представление в удобной форме. Ведь не всегда вашему представлению нужны все данные сущности, а иногда, наоборот, нужны данные в каком-нибудь специфическом аггрегированном формате, или просто набор этих данных, не связанный между собой ничем, кроме того факта, что он будет отображен на одной и той же странице. То есть, по сути, View Model - это некая проекция данных Domain Model, которая необходима конкретному представлению.

Например, у нас есть страница, которая показывает категории продуктов слева в меню, и список продуктов конкретной категории в области контента. Для отрисовки этой страницы (представления) ей необходимо получить от контроллера список категорий, выбранную категорию и список продуктов этой категории. Самый простой способ - передать эти данные через dictionary ViewData. Но это как-то не по-ковбойски :) Никакой безопасности типов + возможность ошибиться в строке ключа. Тогда остается лишь передавать данные через типизацию класса ViewPage<Type>, где Type - это тип передаваемого объекта, который будет доступен через свойство Model в представлении. Однако, у нас в Domain Model нет такого типа, который бы содержал две необходимые нам коллекции и одну сущность. Поэтому нужно его создать и назвать, например, ProductsListViewModel. Данный тип будет вспомогательным, его единственное назначение - это послужить контейнером для передачи данных из контроллера в представление.

Что это нам дает? Во-первых, теперь мы можем обращаться к переданной таким образом коллекции категорий следующим образом:

<%= Model.Categories %>

Во-вторых, если мы когда-то решим, что нам бы не помешало создать Partial View (ascx-контрол, по-русски) для показа списка категорий, нам будет достаточно подключить его на страницу при помощи следующего вызова:

<% Html.RenderPartial("CategoriesList", Model.Categories); %>

И даже если мы когда-нибудь захотим еще и подсвечивать выбранную категорию, то мы легко можем создать CategoriesListViewModel, который будет содержать коллекцию категории и ссылку на выбранную категорию, а потом использовать эту новую модель в ProductsListViewModel. При этом наш контрол будет наследоваться от ViewUserControl<CategoriesListViewModel>. Красота, все разложено по полочкам, предельно просто и понятно.

Пара слов о том, где хранить созданные классы View Model. Как вы уже поняли, их может быть довольно много, в зависимости от количества представлений и их сложности. Я предложил бы хранить их в замечательной папочке Models, которую Visual Studio вам заботливо генерирует при создании проекта ASP.NET MVC. Классы Domain Model вы там все равно, скорее всего, хранить не будете (по крайней мере, я бы советовал для них создавать отдельную сборку). А если даже и будете, то никто не мешате создать две папки Model/DomainModel и Model/ViewModel.

Самые внимательные уже наверно увидели сходство паттерна View Model с DTO (Data Transfer Object). И сходство действительно есть, причем значительное. И там, и там - проекции данных для передачи куда-то. Только, в отличие от DTO, которые могут передаваться как угодно далеко, хоть на деревню дедушке, View Model объекты передаются всего лишь по соседству в представление. Так что можете пользоваться этой аналогией, если вам так будет проще понять смысл View Model и его назначение.

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

Model:

Stephen Walther: Understanding Models

View Model:

DataModel and ViewModel
DataModel-View-ViewModel pattern series