Использование базового контроллера для получения Common ViewData

Question

Я работаю над приложением ASP.NET MVC, которое содержит заголовок и меню на каждой странице. Меню и заголовок являются динамическими. Другими словами, пункты меню и информация заголовка определяются во время выполнения.

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

Итак, я пытаюсь определить наилучшую практику для создания такой функциональности. Кроме того, если это рекомендуемый подход, какой метод следует переопределить (я предполагаю, что Выполнить) при получении данных для вставки в ViewData.

Я уверен, что это распространенный сценарий, поэтому любые советы / лучшие практики приветствуются! Заранее спасибо!

EDIT: После публикации (конечно) я нашел следующие ресурсы, но любые дополнительные анекдоты были бы замечательными!

http://www.singingeels.com/Blogs/Nullable/2008/08/14/How_to_Handle_Side_Content_in_ASPNET_MVC.aspx

Как вы используете usercontrols в asp.net mvc, которые отображают «островок» данных?

Answer 1

Зависит от того, откуда поступает ваша информация. У нас есть стандартные данные представления, которые мы используем для генерации некоторой информации, которую мы имеем на экране, которую мы создаем именно таким образом. Работает хорошо и легко поддерживается. Мы переопределяем метод View для реализации строго типизированных имен представлений и используем эту информацию для извлечения некоторых данных, которые также требуются для главной страницы.

Answer 2

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

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

Следует иметь в виду, что если вы использовали атрибут обработки ошибок ASP.NET MVC по умолчанию [HandleError], а ваша страница ошибок использует ту же главную страницу, которая пытается прочитать ViewData, вы скоро узнаете что вы не можете получить доступ к ViewData со своей страницы ошибок, и это вызовет исключение. В зависимости от того, нужен ли вам ViewData для сценариев сбоев, жизнеспособное решение - использовать отдельную главную страницу или сделать следующее: Как передать ViewData в представление HandleError?

Answer 3

Используйте базовый класс контроллера для реализации методов фильтра Generell. Класс контроллера реализует некоторые интерфейсы фильтров IActionFilter, IAuthorizationFilter, IExceptionFilter и IResultFilter, которые полезны для реализации общего поведения всех контроллеров.

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

Answer 4

Вы можете написать вспомогательное расширение для отображения заголовка / меню Таким образом, вы можете показывать его в разных местах вида, если вам нужно, но только в одном месте для обслуживания.

public static HtmlString MainMenu(this HtmlHelper helper)

Answer 5

Я отвечу на ваш вопрос другим вопросом. Нужно ли базовому контроллеру определять, какой это тип на самом деле, чтобы генерировать правильные данные меню? Если это так, то вы побеждаете цель полиморфизма, и код для генерации данных должен идти в каждом контроллере, возможно, в OnActionExecuting, если меню одинаково для всех действий. Передача его обратно в родительский класс, вероятно, в конечном итоге приведет к тому, что какой-то оператор switch в родительском классе сделает то, о чем действительно должен заботиться каждый производный контроллер.