Классическая головоломка, но не особо изолированная для MVC.В ООП вы хотите повысить сплоченность внутри класса и уменьшить связь между классами.MVC поднимает этот же принцип до архитектурного уровня, каждый компонент отвечает за свою деятельность, но отделен от действий двух других.Это идеальная ситуация, но, как и в ООП, идеальный не подразумевает абсолютного разделения.Они совместно используют некоторые данные - контроллеры получают доступ к моделям объектов, конструируют модели представлений и интерпретируют ввод (обычно как модели в веб-интерфейсе MVC).Представления используют модели представлений и в Интернете являются источником входных данных.Модель, пожалуй, самая изолированная.
Реальность такова, что разделение - это не абсолют, а континуум.Вы более или менее разделены по сравнению с другими архитектурными образцами.MVC, как правило, находится на «более» разделительной стороне архитектурных шаблонов, но не все реализации MVC или даже экземпляры приложений в этих средах созданы равными в этом отношении.Как говорится, «вы можете писать на Фортране на любом языке», что означает, что вы можете, если захотите, нарушать шаблон проектирования в любой степени, в которой вы хотите, даже в той степени, в которой он искажает другой шаблон.
Это не всегда плохо.Вы должны быть прагматичными об этом.В конце концов, цель состоит не в том, чтобы добиться чисто архитектурной реализации.Цель состоит в том, чтобы выполнить бизнес приложения.В вашем случае у вас есть некоторые цели пользовательского интерфейса, которые требуют, чтобы представление имело доступ к некоторым сведениям о том, какой контроллер его отображает.ASP.NET MVC предоставляет это через свойство ViewContext, которое, в свою очередь, предоставляет ссылку на Controller, RouteData и HttpContext.
Вы можете использовать их для достижения своих бизнес-целей за счетНекоторое искажение архитектурного шаблона, то есть представление теперь обрабатывает некоторый «ввод» и принимает некоторые решения на основе этих значений напрямую.В качестве альтернативы вы также можете выбрать более четкое разделение, увеличив сложность моделей представлений, либо исходя из базовой модели, содержащей некоторые служебные свойства, либо в MVC используйте ViewBag в качестве расширения каждой модели для той же модели.цели.Это увеличивает связь с контроллером, поскольку теперь он должен знать, что представлению нужны эти служебные свойства для правильной визуализации.Опять же, это континуум - вы увеличиваете связь, а не создаете связь там, где ее не было.
Я отказался от идеи создания чистойMVC.Да, я хочу оставаться как можно ближе к парадигмам инфраструктуры MVC.С фреймворком работать легче, чем с ним.Однако, когда у меня есть цель, которая заставляет меня нарушать разделение интересов (после тщательного изучения, чтобы убедиться, что мне действительно нужно), я больше заинтересован в том, чтобы сделать это устойчивым и поддерживаемым способом, чем прыгать через архитектурные обручи ксделать что-то, для чего фреймворк не подходит или лучше всего сделать так, чтобы фреймворк не ожидал.