Когда правильно использовать ViewData вместо ViewModels?

Question

Предполагая, что вы хотите разработать свои контроллеры так, чтобы вы использовали ViewModel для хранения данных для представлений, которые вы отображаете, должны ли все данные содержаться в ViewModel? В каких условиях было бы нормально обойти ViewModel?

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

Answer 1

Просто для дальнейшего комментария Фабиана;вы можете явно убедиться, что viewdata никогда не используется, выполнив шаги, описанные в этой статье .На самом деле нет оправдания , а не , чтобы использовать модели для всего.

Если у вас нет выбора, кроме как использовать ViewData (скажем, в существующем проекте);по крайней мере используйте строковые константы для разрешения имен, чтобы избежать использования «волшебных строк».Что-то вроде: ViewData[ViewDataKeys.MyKey] = myvalue; Infact, я использую это практически для всего, что должно быть «на основе строк» ​​(Session Keys, Cache Keys, VaryByCustom ключи кеширования вывода и т. Д.).

Answer 2

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

Существует как минимум пара аргументов в поддержку этого:

1. У вас есть главная страница, на которой требуются некоторые данные (например, что-то вроде пользователя StackOverflowинформация в шапке).Применение ActionFilter для всего сайта упрощает заполнение этой информации в ViewData после каждого действия.Чтобы поместить его в модель, потребуется, чтобы каждая другая модель на сайте потом наследовала от базовой модели (поначалу это может показаться неплохим, но может быстро усложниться).

2. Когда выпроверяют опубликованную форму, если есть ошибки проверки, вы, вероятно, захотите перепривязать модель (с недопустимыми полями) обратно к просмотру и отображению сообщений проверки.Это нормально, поскольку данные в полях ввода публикуются обратно и будут привязаны к модели, но как быть с любыми другими данными, требующими повторного заполнения вашего представления?(например, значения раскрывающегося списка, информационные сообщения и т. д.) Они не будут отправлены обратно, и это может стать грязным, если они будут перенесены на модель "вокруг" введенных значений обратной записи.Часто проще иметь метод, который заполняет ViewData данными..view.

По моему опыту, этот подход хорошо работает.

А в MVC3 динамические ViewModels означают, что индексирование строк больше не будет!

Answer 3

Лично я никогда не использую ViewData, все проходит через Модель, кроме случаев, когда я что-то тестирую, и мне быстро нужно увидеть значение в представлении.Strongtyping!

Answer 4

С точки зрения ASP.NET MVC 2, шаблон ViewModel является предпочтительным подходом. Этот подход в полной мере использует статическую проверку типов во время компиляции. Это в сочетании с компиляцией представлений mvc сделает процесс разработки более быстрым и продуктивным, поскольку ошибки обнаруживаются во время сборки / компиляции, а не во время выполнения.