Когда правильно использовать ViewData вместо ViewModels?
Принятие Вас хотело разработать Ваши Контроллеры так, чтобы Вы использовали ViewModel для содержания данных для Представлений, которые Вы представляете, все данные должны содержаться в ViewModel? Какие условия было бы нормально обходить ViewModel?
Причина, которую я спрашиваю, я в состоянии, где часть кода использует ViewData, и некоторые используют ViewModel. Я хочу распределить ряд инструкций в команде на том, когда правильно использовать ViewData, и когда это просто срезает путь. Я хотел бы мнения от других разработчиков, которые имели дело с этим так, чтобы я знал, что мои инструкции не просто я смещаемый.
4 ответа
Просто в продолжение комментария Фабиана; вы можете явно гарантировать, что данные просмотра никогда не будут использоваться, выполнив действия, описанные в этой статье . На самом деле нет никакого оправдания не использованию моделей для всего.
Если у вас нет другого выбора, кроме как использовать ViewData (скажем, в существующем проекте); по крайней мере используйте строковые константы для разрешения имен, чтобы избежать использования «волшебных строк». Что-то вроде: ViewData [ViewDataKeys.MyKey] = myvalue; На самом деле, я использую это практически для всего, что должно быть «на основе строк» (ключи сеанса, ключи кеша, ключи кэша вывода VaryByCustom , и т.д).
Я лично никогда не использую ViewData, все проходит через модель, кроме случаев, когда я что-то тестирую, и мне нужно быстро увидеть значение в представлении. Strongtyping!
С точки зрения ASP.NET MVC 2, шаблон ViewModel является предпочтительным подходом. Подход полностью использует преимущества проверки статического типа во время компиляции. Это в сочетании с компиляцией mvc views сделает ваш рабочий процесс разработки намного более быстрым и продуктивным, поскольку ошибки обнаруживаются во время сборки / компиляции, а не во время выполнения.
Один из подходов, который вы можете рассмотреть по мере того, как ваши представления становятся более сложными, - это зарезервировать использование моделей для полей ввода и использовать ViewData для поддержки всего остального, что необходимо для визуализации View.
Есть по крайней мере пара аргументов в поддержку этого:
У вас есть главная страница, для которой требуются некоторые данные (например, что-то вроде информации о пользователе StackOverflow в заголовке). Применение ActionFilter для всего сайта позволяет легко заполнять эту информацию в ViewData после каждого действия. Чтобы поместить его в модель, потребуется, чтобы все остальные модели на сайте унаследовали от базовой модели (поначалу это может показаться неплохим, но может быстро усложниться).
Когда вы проверяете опубликованную форму, если есть ошибки проверки, вы, вероятно, захотите повторно привязать модель (с недопустимыми полями) обратно к представлению и отобразить сообщения проверки. Это нормально, поскольку данные в полях ввода отправляются обратно и будут привязаны к модели, но как насчет любых других данных, которые требуется вашему представлению для повторного заполнения? (например, значения раскрывающегося списка, информационные сообщения и т. д.). Они не будут отправлены обратно, и повторное заполнение их в модели «вокруг» отправленных обратно входных значений может стать беспорядочным. Часто бывает проще иметь метод, который заполняет ViewData данными..view.
По своему опыту я обнаружил, что этот подход работает хорошо.
А в MVC3 динамические модели просмотра означают, что больше не будет индексирования строк!