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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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