Использование модели представления + модели данных в ASP.NET MVC для поддержки типизированных представлений?

Question

Как большинство разработчиков обрабатывают типизированные представления в ASP.NET MVC при работе с большими приложениями? Мы рассматриваем размещение моделей для конкретных видов в папке «Модели», а затем помещаем все доменные объекты в отдельный проект. Таким образом, наши контроллеры могут легко добавить объект домена к типизированному представлению, при этом объекту домена не нужно знать сам макет представления.

Например, если у нас есть объект Employee с:

• Id
• Имя
• Фамилия
• Состояние

Тогда наше представление сотрудников может использовать объект ViewEmployeeModel с:

• Объект сотрудника
• Список для заполнения раскрывающегося списка Статус

Это разумный подход? Есть ли лучшие способы сделать то же самое? Это кажется немного странным, поскольку у меня есть две модели (одна для представления, другая для бизнес-объектов), но разве это не лучше, чем использование нетипизированных представлений?

Answer 1

Я делаю это почти как правило, потому что:

1. Позволяет разрабатывать представление приложения в первую очередь вместо DB-first, что удобно при работе с представителями клиентов.
2. Представления обычно имеют гораздо более «плоский» граф объектов, чем, скажем, модели Entity Framework. LINQ позволяет легко сопоставить их.
3. Представления и модель данных могут развиваться гораздо более независимо.
4. Как правило, проще связать модель с моделью плоского представления с, скажем, идентификаторами FK, чем с моделью объекта, которая ожидает полностью материализованные связанные объекты.
5. Вам не нужно беспокоиться о случайном раскрытии «секретных» свойств или свойств белого списка для обновлений.

Answer 2

Нет репутации комментировать, но Крейг прав. Это разновидность модели Model-View-ViewModel. Хорошая статья доступна по адресу Los Techies .

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

Answer 3

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

Answer 4

Я думаю, что это довольно разумный подход. Вам может помочь одна вещь: AutoMapper .