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

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

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

Ответ 1

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

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

Ответ 2

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

Есть несколько аргументов для поддержки этого:

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

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

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

Ответ 3

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

Ответ 4

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