Традиционное использование контроллера в MVC приводят к нарушению Единственного Принципа Ответственности?
Википедия описывает Единственный Принцип Ответственности этот путь:
Единственный Принцип Ответственности указывает, что каждый объект должен нести единственную ответственность, и что ответственность должна полностью инкапсулироваться классом. Все его сервисы должны быть исключительно выровненные той ответственности.
Традиционное использование контроллера в MVC, кажется, приводит программиста к нарушению этого принципа. Возьмите простой контроллер гостевой книги и представление. Контроллер мог бы иметь два метода/действия: 1) Индекс () и 2) Отправляет (). Индекс () отображает форму. Отправление () обрабатывает его. Эти два метода представляют две отличных обязанности? Если так, как Единственная Ответственность входит для проигрывания?
2 ответа
Да, это так.
И если вы хотите следовать SRP, вы разделяете свой Контроллер на Диспетчер и Действия; Диспетчер передает управление своим действиям, и во время компиляции (шаблоны C ++) или во время выполнения (Java XML, что угодно) вы должны составить Диспетчеры и Действия.
Почему мы не видим это чаще? Поскольку контроллеры часто представляют собой «специальные» реализации, конкретные классы конечного уровня, которые не являются обобщенными и не предназначены для создания подклассов. Здесь класс используется для более удобной группировки кода, действия почти наверняка не являются общедоступными (скорее всего, частными, возможно, защищенными), «просто» внутренними деталями реализации.
Выбор того, как решить, какое действие выполнять, количество и разнообразие возможных действий велик, а диспетчеризация и действие тесно связаны. Так что на практике часто проще просто собрать код в одном месте.
Нет, это не так.
В паттерне MVC или его вариациях нет ничего, что привело бы к нарушению принципа единой ответственности. Нарушает ли реализация контроллера SRP или нет, зависит от того, есть ли у инкапсулированного поведения более чем одна причина для изменения (как и у любого другого класса), а не из-за какого-либо предполагаемого предписывающего использования паттерна.
Пример, который вы привели, является подмножеством базового приложения форм над данными, где контроллер просто предоставляет операции CRUD для данной модели. Операции CRUD достаточно целостны по своей природе, поэтому это обычно не является нарушением SRP. Когда наличие нескольких методов на одном контроллере начинает вызывать подозрения, это когда методы представляют различные поведенческие взаимодействия в домене.
При этом, даже если кто-то будет утверждать, что CRUD представляет собой четыре отдельных несвязных задачи, в паттерне MVC нет ничего такого, что заставляло бы вас облегчать каждое из этих действий в рамках одного контроллера.
Для небольшой истории паттерна MVC, а также обсуждения его применения в веб-разработке, ознакомьтесь с Паттернами архитектуры интерактивных приложений.