ASP.NET MVC: ViewModels против доменных сущностей
Я создаю концептуальное приложение с MVC 3, пытаясь изучить его способы. Ранее я делал несколько очень тяжелых приложений в WebForms, используя n-уровневый подход, обычно состоящий из объектов домена с хранилищами для хранения и служб для управления ими перед хранением.
Я пытаюсь примирить, как я делал вещи с "правильным" способом сделать это в MVC, если есть какой-то один такой способ. Сейчас я зацикливаюсь на том, когда использовать ViewModels, а не на том, когда используют мои доменные объекты, которые находятся в другом проекте. Валидация выполняется с помощью ViewModels, но, поскольку я пишу более специализированную валидацию бизнес-логики, кажется, что слишком скромная ответственность за скромную ViewModel, которая просто помогала мне перемещать данные перед их официальным хранением в базе данных через слой хранилища,
Я также устал от привязки данных ViewModel к "официальному" объекту домена, который репозиторий хранит и извлекает, но я чувствую, что не должен запятнать свои доменные объекты с атрибутами MVC для проверки.
Есть ли у вас какие-либо советы о том, где провести черту между объектами домена и простыми моделями представления? Или я усложняю вещи, и мои ViewModels должны фактически быть "официальными" моделями, которые хранит хранилище?
6 ответов
Обычно я по умолчанию использую модели представлений, хотя для представлений только для чтения мне известно, что я использую модель предметной области (нет причин проходить через накладные расходы, если я собираюсь только читать данные из нее).
Если вы решите использовать доменные модели, я бы никогда не позволил MVC связываться непосредственно с ними, потому что, если кто-то знает ваш домен достаточно хорошо, он может публиковать значения, которые привязываются к свойствам, которые вы не хотите, чтобы пользователь мог редактировать. Вы можете определить белый и черный список свойств того, что связыватель модели может и не может связывать, но используя это - что-то еще, что вам придется поддерживать, и то, о чем можно легко забыть.
Есть ли у вас какие-либо советы о том, где провести черту между объектами домена и простыми моделями представления?
Лично я всегда использую View Models. Вся логика проверки пользовательского интерфейса выполняется на моделях представления (обязательные поля,...) и бизнес-логика на моделях домена (имя пользователя уже существует,...). Я также использую AutoMapper, чтобы не уставать от сопоставления между моделями домена и моделями представления, которые передаются в представление.
Я думаю, что лучший подход - это всегда использовать модели представления. Они касаются вопросов представления и должны быть там, где выполняется базовая проверка входных данных. Доменные объекты не подходят для этого.
Я использую конкретные модели представлений для каждого представления и включаю только ту информацию, которая необходима в представлении, - сохраняя модели представления полностью ориентированными на вид, чтобы получить хорошие чистые виды.
Вы можете использовать Automapper, чтобы помочь избавиться от рутинной работы между моделями представлений и доменов.
Могу ли я рекомендовать ASP.NET MVC 2 в действии как отличную книгу для сильных шаблонов ASP.NET MVC. Это охватывает использование Automapper в деталях.
ViewModel хороши, но не забывайте, что атрибуты валидации не только ограничены проектами MVC, вы можете использовать их в любом проекте.net. Из-за этого может иметь смысл применять атрибуты проверки к объектам вашего домена, предпочтительно с использованием частичного класса и / или класса Validator http://weblogs.asp.net/scottgu/archive/2010/12/10/class-level-model-validation-with-ef-code-first-and-asp-net-mvc-3.aspx
Доменные модели и ViewModels будут очень похожи друг на друга. Однако ViewModels обычно содержат атрибуты и свойства логики представления. Также иногда тип данных может быть другим, например, вам может понадобиться определить свойство DateTime, так как строка просто заставит валидацию работать без каких-либо ошибок.
Я использую AutoMapper для преобразования из модели в ViewModels/ и наоборот.
Мой подход заключается в том, что модель ViewModel должна быть связана с одним представлением (или, по крайней мере, с набором связанных представлений) и обычно является подмножеством модели вашего домена. Я считаю ViewModel ответственным за проверку пользовательского интерфейса, а ваш домен отвечает за проверку бизнес-правил.
Что касается отображения между ними, настоятельно рекомендуем использовать Automapper, который может автоматически отображать свойства в соответствии с соглашениями, это значительно экономит время.