Почему так много веб-фреймворков MVC предпочитают группировать действия нескольких контроллеров в одном классе?

Question

Мой опыт в основном ограничен PHP, но, насколько мне известно, и Rails, и ASP.NET MVC выбрали один и тот же путь.

Дело в том, что почти каждая веб-инфраструктура, с которой я когда-либо сталкивался, реализует действия контроллера как методы, например, create, edit, show и т. Д. Эти методы находятся в одном классе, например PostsController, но они почти никогда не разделяют состояние или зависимости, поскольку во время всего запроса вызывается только один из них.

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

Итак, вопрос в том, почему это так? Возможно, это субъективно, но я считаю, что, возможно, я упустил важное преимущество этого подхода.

Answer 1

Я бы сказал, что шаблон проектирования MVC в целом диктует этот подход к созданию контроллеров. Основная цель контроллера - обеспечить соответствующую «разводку» между ассоциированным представлением и моделями, с которыми он должен взаимодействовать, наряду с любой бизнес-логикой, необходимой для обработки ввода из представления. Контроллеры должны быть просто тонким слоем между этими другими компонентами. Например, Википедия описывает контроллер следующим образом:

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

Я согласен, что контроллеры в других, не веб-средах поддерживают состояние, но причина отсутствия состояния в PHP, например, заключается просто в том, что HTTP является протоколом без сохранения состояния. Использование MVC в этой среде неизбежно приведет к тому, что контроллеры не будут поддерживать состояние.

Answer 2

Почему так много веб-фреймворков MVC предпочитают группировать несколько действий контроллера в одном классе?

Это важно для объектно-ориентированного программирования, что приводит к должной многоуровневой архитектуре программного обеспечения, где объекты контроллераинкапсулировать все обязанности по объектам домена (модель).Если есть PostModel, то должен быть PostController, ответственный за вызов правильных бизнес-методов в домене api для удовлетворения запроса пользователя и вывода результатов в представление.По моему мнению, наличие класса контроллера для каждого возможного запроса приводит к процедурно-структурированной архитектуре.

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