ASP.NET MVC: ViewModels против доменных объектов

Я создаю концептуальное приложение с MVC 3, пытаясь узнать его способы. Я ранее делал некоторые очень тяжелые приложения в WebForms, используя подход n-уровня, обычно состоящий из объектов домена с хранилищами для хранения и сервисами для управления ими перед хранением.

Я пытаюсь примирить, как я делал что-то с помощью "правильного" способа сделать это в MVC, если таковой существует. То, что я сейчас повесил, - это когда использовать ViewModels против того, когда использовать объекты моего домена, которые находятся в целом другом проекте. Проверка выполняется с помощью ViewModels, но по мере того, как я пишу более персонализированную проверку бизнес-логики, кажется, что это слишком большая ответственность за низкую ViewModel, которая была там, чтобы помочь мне перемещать данные, прежде чем официально сохранять их в базе данных через уровень репозитория.

Я также устал от сопоставления данных ViewModel с "официальным" объектом домена, который хранит и извлекает репозиторий, но я чувствую, что не должен очернять мои объекты домена с помощью атрибутов MVC для проверки.

Есть ли у вас какой-либо совет, где можно провести линию между объектами домена и просто ViewModels? Или я усложняю вещи, и мои ViewModels действительно должны быть "официальными" моделями, которые хранит репозиторий?

Ответ 1

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

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

Ответ 2

Есть ли у вас какой-либо совет, где можно провести линию между объектами домена и простоми ViewModels?

Лично я всегда использую View Models. Вся логика проверки UI выполняется на моделях просмотра (обязательные поля,...) и бизнес-логике на моделях домена (имя пользователя уже существует,...). Я также использую AutoMapper, чтобы не уставать от сопоставления между моделями домена и моделями представления, которые передаются в представление.

Ответ 3

Я думаю, что лучший подход - использовать модели просмотра ВСЕГДА. Речь идет о проблемах с представлением и должно быть, где обрабатывается базовая входная проверка. Объекты домена не подходят для этого.

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

Вы можете использовать Automapper, чтобы устранить трудность перемещения между режимами просмотра и домена.

Могу ли я рекомендовать ASP.NET MVC 2 в действии как отличную книгу для сильных шаблонов ASP.NET MVC. Это подробно описывает Automapper.

Ответ 4

Модели доменов и ViewModels будут очень похожи друг на друга. Однако ViewModels обычно содержат атрибуты и свойства логики просмотра. Также иногда тип данных может быть другим, например, вам может потребоваться определить свойство DateTime, поскольку строка просто обрабатывает валидацию без возникновения каких-либо ошибок.

Я использую AutoMapper для преобразования из модели в ViewModels/наоборот.

Ответ 5

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

Ответ 6

Мой подход заключается в том, что модель ViewModel должна быть связана с одним представлением (или, как минимум, с набором связанных представлений) и обычно является подмножеством вашей модели домена. Я вижу, что ViewModel отвечает за проверку UI, когда объект домена отвечает за проверку бизнес-правил.

Что касается сопоставления между ними, настоятельно рекомендуем использовать Automapper, который может автоматически отображать свойства на основе условностей, это огромная экономия времени.