ASP.NET MVC - шаблон представления модели

Question

Я работаю с платформой MVC (ASP.NET MVC2 / 3 / Razor) уже несколько месяцев, и мне это очень нравится, однако мне трудно разобраться со стандартом для моделей представления.В моих проектах у меня есть папка Models (Содержит мои модели данных - Linq DBML, Repository [ies], Extension extension) и папка Models / ViewModels.Моими моделями представлений обычно являются классы многократного использования, которые обычно содержат простые свойства get / set для объектов LINQ или коллекций объектов, к которым мне нужно получить доступ для определенного представления.

Теперь проблема в том, чтобы выяснить, когдасоздать модель представленияМоя цель - как можно чаще использовать объект LINQ в качестве модели представления, особенно когда это действие Edit.Моя проблема в том, что если у меня есть другие биты данных, которые я мог бы использовать только для целей отображения?Я не люблю использовать коллекции ViewData / ViewBag, так как для доступа к их членам требуется знание ключа элемента коллекции (не так уж легко догадаться дизайнеру / фронтэнду).Мне также не нравится идея создания ViewModel для каждого View, так как это выглядит излишне грязным кодом.

Например, представьте, что у меня есть модель данных для сотрудника, и я хочу отобразить некоторую информацию, не связанную с этим сотрудником - скажем, статистику сайта, динамические меню и все, что вы можете себе представить, может быть получено избаза данных.Какую модель я должен пройти действие / Сотрудник / Изменить?Объект Employee с кучей ViewData [] для остальных или пользовательский EmployeeView?

Существует ли золотой стандарт?Что мне не хватает?Что ты делаешь иначе, что я должен посмотреть?Заранее спасибо!

Answer 1

Я никогда не использую свои классы сущностей напрямую в качестве моделей представления.Я всегда создаю модель для каждого вида, содержащую данные для этого вида.Я начал использовать AutoMapper для сопоставления моделей представления и моделей сущностей.Я передаю это через класс ModelMapper, который имеет метод ToViewModel<TEntity,TViewModel>() для обработки стандартных отображений (просто вызывает autopper) и специализированные методы отображения для пользовательских отображений, особенно для поддержки создания и обновления сущностей из моделей представления.

Answer 2

Вы назвали три вещи здесь:

• Статистика сайта
• Динамические меню
• Что бы еще ни [...] могло бы прийти из базы данных

Этот третий пункт - ловушка; просто то, что что-то есть в вашей базе данных, не означает, что это часть вашей доменной модели.

Навигация может основываться на базе данных. Это может также быть в карте сайта или жестко запрограммировано в приложении. На самом деле это не приложение data , это приложение configuration . Если вы храните его в базе данных приложения, это нормально (ну, не совсем), но это , а не часть самой модели.

Точно так же статистика сайта обычно хранится в базе данных, но она хранится в другой базе данных , в частности, в аналитической базе данных (и многие люди просто "передают" это в Google). Итак, еще раз, они вида данных, но они не ваша модель.

Если вы хотите, чтобы ваше приложение имело смысл, вам нужно разделить эти проблемы на концептуальном уровне. Навигация выполняется в вашей главной странице / макете, включая любой динамический код, необходимый для его работы. Это логика pure view - не позволяйте ей проникнуть в вашу модель. Вполне нормально и обычно предпочтительнее использовать ViewData / ViewBag для задач, которые связаны с реальной функцией, которая используется в настоящее время.

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

Когда я впервые начал работать с MVC, я также неохотно использовал модели представлений. Но после того, как я стал более привыкать к этой идее, я понял, что на самом деле это было подходящее решение only - особенно, когда ваша "модель" - это в основном тонкая оболочка над самой базой данных. Представления и данные меняются по-разному и с разной скоростью; если вы не хотите беспокоиться о постоянном потоке ошибок и регрессий, то вам нужна некоторая изоляция между ними. Создайте слой отображения и назовите его днем.

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

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

Answer 3

Если вы создаете страницу для редактирования сотрудника, но также отображаете упомянутые вами вещи (статистика сайта / меню), почему бы не поместить их в частичные представления или файлы макетов?