Приводит ли традиционное использование контроллера в MVC к нарушению принципа единой ответственности?

Question

Википедия описывает Принцип единой ответственности следующим образом:

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

Традиционное использование контроллера в MVC, похоже, ведет программиста к нарушению этого принципа. Возьмите простой контроллер гостевой книги и посмотрите. Контроллер может иметь два метода / действия: 1) Index () и 2) Submit (). Индекс () отображает форму. Submit () обрабатывает его. Представляют ли эти два метода две разные обязанности? Если да, то как в игру вступает Single Responsibility?

Answer 1

Да, это так.

И если вы хотите следовать SRP, вы дезагрегируете свой контроллер на диспетчер и действия; Dispatcher отправляет управление своим действиям, и во время компиляции (шаблоны C ++) или во время выполнения (Java XML, что угодно) вы составляете Dispatchers и действия.

Почему бы нам не увидеть это чаще? Поскольку контроллеры часто являются «специальными» реализациями, конкретные классы конечного уровня не обобщены и не предназначены для подклассов. Здесь этот класс используется больше для удобной группировки кода, действия почти наверняка являются непубличными (вероятно, частными, возможно, защищенными), «просто» внутренними деталями реализации.

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

Answer 2

Нет, это не так.

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

Пример, который вы изложили, представляет собой подмножество базовых форм поверх приложения данных, где контроллер просто обеспечивает операции CRUD для данной модели. Операции CRUD по своей природе довольно сплоченные, поэтому, как правило, это не является нарушением SRP. Когда наличие нескольких методов на одном контроллере начинает вызывать подозрение, это когда методы представляют различные поведенческие взаимодействия в домене.

Тем не менее, даже если кто-то, кто утверждает, что CRUD представляет четыре отдельных несвязных вопроса, нет ничего присущего шаблону MVC, который заставлял бы вас выполнять каждое из этих действий в одном контроллере.

Чтобы немного узнать о шаблоне MVC, а также обсудить его применение в веб-разработке, ознакомьтесь с Шаблоны интерактивной архитектуры приложений .