Почему так много веб-фреймворков MVC предпочитают группировать действия нескольких контроллеров в одном классе?
Мой опыт в основном ограничен PHP, но, насколько мне известно, и Rails, и ASP.NET MVC выбрали один и тот же путь.
Дело в том, что почти каждая веб-инфраструктура, с которой я когда-либо сталкивался, реализует действия контроллера как методы, например, create, edit, show и т. Д. Эти методы находятся в одном классе, например PostsController, но они почти никогда не разделяют состояние или зависимости, потому что во время всего запроса вызывается только один из них.
Вот почему этот подход кажется мне совершенно необоснованным, поскольку класс действует только как некое пространство имен. Просмотр примеров с большими кусками едва связанного кода действия контроллера, составляющего даже более крупные классы контроллера, также не помогает. Тем не менее, многие фреймворки делают именно это, и лишь немногие используют класс для каждого действия.
Итак, вопрос в том, почему это так? Возможно, это субъективно, но я считаю, что, возможно, я упустил важное преимущество этого подхода.
2 ответа
Я бы утверждал, что паттерн проектирования MVC в целом диктует такой подход к построению контроллеров. Основная цель контроллера - обеспечить соответствующую "проводку" между связанным представлением и моделями, с которыми оно должно взаимодействовать, вместе с любой бизнес-логикой, необходимой для обработки ввода от представления. Контроллеры должны быть лишь тонким слоем между этими другими компонентами. Например, Википедия описывает контроллер следующим образом:
Контроллер получает входные данные и инициирует ответ, делая вызовы на объекты модели. Контроллер принимает ввод от пользователя и инструктирует модели и области просмотра выполнять действия на основе этих данных.
Я согласен, что контроллеры в других, не веб-средах, поддерживают состояние, но причина отсутствия состояния в PHP, например, заключается в том, что HTTP - это протокол без состояния. Использование MVC в этой среде неизбежно приведет к контроллерам, которые не поддерживают состояние.
Почему многие веб-фреймворки MVC предпочитают группировать несколько действий контроллера в одном классе?
Это необходимо для объектно-ориентированного программирования, что приводит к правильно выстроенной архитектуре программного обеспечения, где объекты контроллера инкапсулируют всю ответственность за объекты домена (модель). Если есть PostModel, то должен быть и PostController, отвечающий за вызов нужных бизнес-методов на доменном api, чтобы удовлетворить запрос пользователя и вывести результаты в представление. Наличие класса контроллера для каждого возможного запроса приводит к процедурной структурированной архитектуре, на мой взгляд.
С другой стороны, если в классе контроллера у вас слишком много обязанностей, вам следует разделить эти обязанности на несколько контроллеров. Это зависит от конкретного приложения, универсального решения не существует. Каждый контроллер должен отвечать за целостную группу действий на уровне домена.