ASP.NET MVC - шаблон представления модели
Я работаю с фреймворком MVC (ASP.NET MVC2/3/Razor) уже несколько месяцев, и мне это очень нравится, однако мне трудно найти стандарт для моделей представления. В моих проектах у меня есть папка Models (Содержит мои модели данных - Linq DBML, Repository[ies], Extension extension) и папка Models/View Models. Моими моделями представления обычно являются классы многократного использования, которые обычно содержат простые свойства get/set для объектов LINQ или наборов объектов, к которым мне нужно получить доступ для определенного представления.
Теперь у меня проблема с выяснением, когда создавать модель представления. Моя цель - как можно чаще использовать объект LINQ в качестве модели представления, особенно когда это действие Edit. Моя проблема в том, что если у меня есть другие биты данных, которые я мог бы использовать только для целей отображения? Я не люблю использовать коллекции ViewData/ViewBag, так как для доступа к их членам требуется знание ключа элемента коллекции (не так-то просто догадаться дизайнеру / фронтэнду). Мне также не нравится идея создания View Model для каждого View, так как это выглядит излишне грязным кодом.
Например, представьте, что у меня есть модель данных для сотрудника, и я хочу отобразить некоторую информацию, не связанную с этим сотрудником - скажем, статистику сайта, динамические меню и все, что вы можете себе представить, может исходить из базы данных. Какую модель я должен передать действие / Сотрудник / Изменить? Объект Employee с кучей ViewData[] для остальных или пользовательский EmployeeView?
Есть ли золотой стандарт? Что мне не хватает? Что ты делаешь иначе, что я должен посмотреть? Заранее спасибо!
3 ответа
Вы назвали три вещи здесь:
- Статистика сайта
- Динамические меню
- Все, что [...] может поступить из базы данных
Этот третий пункт - ловушка; то, что что-то есть в вашей базе данных, не означает, что это часть вашей доменной модели.
Навигация может быть основана на базе данных. Это может также быть в карте сайта или жестко запрограммировано в приложении. На самом деле это не данные приложения, а конфигурация приложения. Если вы храните его в базе данных приложения, это нормально (ну, не совсем), но это не является частью самой модели.
Точно так же статистика сайта обычно хранится в базе данных, но она хранится в другой базе данных, в частности, в аналитической базе данных (и многие люди просто "передают" это в Google). Опять же, они являются своего рода данными, но они не ваша модель.
Если вы хотите, чтобы ваше приложение имело смысл, вам нужно разделить эти проблемы на концептуальном уровне. Навигация выполняется в вашей главной странице / макете, включая любой динамический код, необходимый для его работы. Это логика чистого представления - не позволяйте ей проникнуть в вашу модель. Это вполне нормально и обычно предпочтительнее использовать ViewData/ViewBag для проблем, которые связаны с реальной функцией, которая используется в настоящее время.
Теперь, если предположить, что существуют другие виды данных представлений, которые на самом деле являются данными приложений: в принципе, верно, что представления должны быть напрямую связаны с моделями - это, в конце концов, означает "MVC", но на практике это просто повторное реализация непродуманной идеи "канонической модели данных". Домен и представление являются отдельными проблемами, и, как таковые, подразумевают разные контекстные модели - в последнем случае это модель представления.
Когда я впервые начал заниматься MVC, я неохотно использовал и модели представлений. Но после того, как я стал более привыкать к этой идее, я понял, что это действительно единственное надежное решение, особенно когда ваша "модель" в основном представляет собой тонкую оболочку над самой базой данных. Представления и данные меняются по-разному и с разной скоростью; если вы не хотите беспокоиться о постоянном потоке ошибок и регрессий, тогда вам нужна некоторая изоляция между ними. Создайте слой отображения и назовите его днем.
На этом этапе я занялся созданием разных моделей представлений для каждого представления, независимо от того, думаю мне это или нет. Вначале это может быть не что иное, как точная копия класса модели, но это означает, что я могу настроить его в любое время и любым способом, не прибегая к базовой модели - и наоборот. Как говорит телеканал, первоначальную модель представления легко создать с помощью AutoMapper, и она может занять около 30 секунд вашего времени.
Просто используйте модели представлений и надейтесь, что в конечном итоге инструменты будут поддерживать автогенерацию моделей представлений.
Я никогда не использую свои классы сущностей напрямую в качестве моделей представления. Я всегда создаю модель для каждого вида, содержащую данные для этого вида. Я начал использовать AutoMapper для сопоставления моделей представления и моделей сущностей. Я опосредую это через класс ModelMapper, который имеет ToViewModel<TEntity,TViewModel>() метод для обработки стандартных отображений (просто вызывает autopper) и специализированных методов отображения для пользовательских отображений, особенно для поддержки создания и обновления сущностей из моделей представлений.
Если Вы создаете страницу для редактирования сотрудника, но Вы также отображаете вещи, которые Вы упомянули (статистика / меню сайта), почему бы не поместить их в частичные представления или файлы макетов?