Лучший способ CustomViewData? - PullRequest
       14

Лучший способ CustomViewData?

1 голос
/ 17 апреля 2009

Какой самый практичный способ добавить пользовательские свойства в широкий ViewDataDictionary?

Давайте предположим простой случай:

public ActionResult Index()
{
  // ViewData["Title"] = "Home";
  ViewData.Title = "Home";
  return View();
}

Первое, что приходит на ум, это пользовательский класс и использование «new» в базовом контроллере приложения:

public class CustomDataDictionary : ViewDataDictionary
{
  public string Title { get; set; }
}

public class ApplicationController : Controller
{
    public new CustomDataDictionary ViewData { get; set;} 
}

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

Второе, что приходит на ум, - это создать класс ViewDataDictionaryExtensions.

В-третьих, используйте «Просмотреть модель». Моя претензия к моделям представления заключается в том, что создание ее всегда и передача ее в представление выглядит как повторение снова и снова в коде контроллера, по крайней мере по сравнению с двумя предыдущими вариантами.

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

Все три метода выполняют свою работу. Что сделали другие?

Ответы [ 3 ]

0 голосов
/ 03 мая 2009

Все они звучат так, как будто они будут работать. Я думаю, какой из них вы выберете, зависит от ваших требований. (Действительно уникальный и информативный ответ, да?)

Ваш вопрос был "Что сделали другие?" хоть. Итак, если вы опрашиваете, I недавно использовал метод констант для небольших приложений. Я еще не сделал корпоративное приложение MVC, но думаю, что я, вероятно, создам базовый класс, который наследует Controller и определяет эти дополнительные свойства. И если бы я хотел передать их последовательно в представление, у меня также был бы базовый класс для моих моделей. Тем не менее, это должно быть использовано разумно - даже если вы введете их формально, они все равно будут действовать как глобальные переменные. Поэтому вы должны быть осторожны, конечно.

0 голосов
/ 04 мая 2009

В конце концов, по крайней мере для этого приложения, у меня был базовый класс AppViewModel. Controller.OnActionExecute / ed выглядит так, чтобы ViewData.Model был установлен, а если нет, то на его место помещается экземпляр AppViewModel, поэтому все страницы имеют согласованную модель для работы (Model.Title, Model.IsAuthenticated, Model .Пользователь и т. Д.)

Тогда более подробные действия контроллера имеют подкласс AppModelView, для которого устанавливается значение ViewData.Model либо вручную в самом действии, либо в OnExecute / ed через атрибут.

Совсем немного кода, но он не позволяет повторять один и тот же старый код создания / установки во всех действиях контроллера. И для меня это сохраняет представление данных как пакет, а не загромождает API контроллера.

0 голосов
/ 17 апреля 2009

Проблема с ошибками в именах - вот для чего нужны константы.

Чтобы правильно набрать ViewData, вам нужно наследовать и т. Д .; поэтому к тому времени, когда вы это сделаете, я думаю, что вы не могли бы так же легко добавить какой-нибудь общий код в контроллер, который устанавливает ключ.

Использование ключа кажется мне, по крайней мере, наименее сложным ответом - он также работает в самом широком числе случаев (то есть, когда определенный код знает только о базовом IDictionary<string,object>).

Вас также может заинтересовать этот связанный вопрос .

...