Маршруты против контроллеров… бой!

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

На вопрос, почему, я получил странный ответ: «Я не знал, что больше подходит, поэтому выбрал оба варианта».

Итак, давайте четко обозначим, почему вы должны объявлять промежуточное ПО на контроллерах и когда использовать маршруты.

Когда это имеет смысл на контроллерах?

Предпочтительный способ установки промежуточного ПО — на контроллерах, если действия требуют полноценной работы промежуточного ПО. У такого подхода есть три явных преимущества:

  • Это делает ваше объявление маршрутов более чистым и простым в обслуживании.
  • Промежуточное ПО влияет на все действия контроллера, не более того.
  • Вы можете использовать only() и except() для выборочного применения промежуточного ПО на заданных маршрутах.

Например, мы должны использовать наше специальное промежуточное ПО admin для контроллера, который управляет блокировкой, например блокировкой пользователя с сайта. Это промежуточное программное обеспечение проверяет, что только администраторы могут выполнять эти действия.

С другой стороны, если у нас есть промежуточное ПО, которое меняет цвет сайта

Когда это имеет смысл на маршрутах

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

Например, у нас есть промежуточное ПО под названием colorize, которое применяет стиль CSS на основе категории сообщений. Если мы его не объявим, все посты будут выглядеть одинаково, но это никак не нарушит работу сайта.

Мы можем не только назначить его только одному маршруту, но и сгруппировать несколько маршрутов с одним и тем же промежуточным ПО.

Допустим, мы хотим применить промежуточное ПО colorize к записям и разделу комментариев.

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

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

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