Подавление ссылок меню является обязанностью просмотра или контроллера?

Question

В ASP.NET MVC я создаю сайт с требованием, чтобы главное меню (появляющееся на каждой странице) удаляло гиперссылку для записи (оставляя только текст), если текущая страница является той, на которую ссылается.

Меню html определено на главной странице сайта, но в настоящее время заполняется данными ViewData, переданными контроллером. Это настроено так, что базовый контроллер определяет словарь объектов ссылок, затем действия на контроллерах извлекают соответствующую запись из словаря, устанавливают адрес пустым. Базовый контроллер затем передает его в виде IEnumerable<>.

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

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

(Последнее разъяснение моей проблемы: ссылки в главном меню относятся к «целевым страницам» различных областей сайта (в основном, к действию «Индекс» всех контроллеров), и как только вы перейдете в эту область и с целевой страницы, все записи в меню будут связаны)

Answer 1

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

Однако на самом деле большинство представлений (безусловно, все примеры ASP.NET-MVC, которые я видел) в приложениях воплощает значительную логику приложения в том, что это представление, которое диктует, как пользователь может перемещаться по приложению. Если бы не представление, включая код для создания кликабельных ссылок, изображений и кнопок, у нас не было бы много приложений.

Следовательно, представление, имеющее меню, которое оно контролирует, не противоречит духу разделения интересов. OTH, контроллер, предоставляющий некоторые из списка для превращения в меню, также приемлем. В этом случае вы ожидаете, что контроллер будет определять, какие элементы меню должны быть доступны для щелчка, роль представлений в этом сценарии будет заключаться в выполнении желаний контроллера.

Answer 2

Я согласен с AWJones, что это немного серая область, но imho, если представление должно отвечать за то, как что-то представлено, а контроллер за то, что это что-то, то содержимое меню находится в домене контроллера.

Я чувствую, что «подавление» частей меню должно быть полностью скрыто от представления (и конечного пользователя) - представление должно получить то, что ему нужно и не более .

Answer 3

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

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

Кроме того, передача достаточно важных данных в представление может упростить тестирование приложения.