Файлы маршрутов Laravels могут быть довольно заняты. Прежде чем вы это узнаете, вы должны выполнить поиск в файле маршрутов, чтобы найти что-либо. Но как с этим бороться?
Вы можете подойти к этому по-разному, в зависимости от того, как вы предпочитаете подходить к этому. В этом уроке я пройдусь по нескольким вариантам, которые я видел, а затем закончу о том, как я подхожу к этому и почему я подхожу к этому таким образом.
Я буду использовать простой пример, но вы можете немного использовать свою фантазию! Представьте, что мы создаем приложение API, которое позволяет клиентам заказывать онлайн из каталога и позволяет своим клиентам отслеживать поставки.
Поставщик услуг
маршрутизации С помощью поставщика услуг маршрутизации можно легко добавить дополнительные записи маршрута. Давайте посмотрим на пример:
class RouteServiceProvider extends ServiceProvider
{
public function boot(): void
{
$this->configureRateLimiting();
$this->routes(function (): void {
Route::middleware('api')
->group(base_path('routes/api.php'));
});
}
}Это похоже на RouteServiceProvider по умолчанию, который вы получаете в своем проекте Laravel. Ваш может отличаться в зависимости от возраста вашего приложения. Как мы можем расширить это? Мы можем добавить дополнительную загрузку маршрута в провайдере
class RouteServiceProvider extends ServiceProvider
{
public function boot(): void
{
$this->configureRateLimiting();
$this->routes(function (): void {
Route::middleware('api')
->group(base_path('routes/api.php'));
Route::middleware('api')
->group(base_path('routes/resource/catalog.php'));
Route::middleware('api')
->group(base_path('routes/resource/orders.php'));
Route::middleware('api')
->group(base_path('routes/resource/payments.php'));
Route::middleware('api')
->group(base_path('routes/resource/deliveries.php'));
});
}
}: Это не предназначено для того, чтобы быть абсолютно точным. Я использую это больше в качестве примера с несколькими движущимися частями, которые, вероятно, будут иметь не менее 75+ маршрутов. Итак, здесь мы управляем этим в RouteServiceProvider, поэтому все занимает центральное место в том, как мы загружаем маршруты. Самая большая проблема, которую я обнаружил с этим подходом, заключается в том, что в файле маршрутов вам нужно знать, что еще загружается. Ранее я работал над очень большим приложением, которое использовало этот подход, и потребовалось много умственных усилий, чтобы постоянно возвращаться, чтобы увидеть, загружаются ли маршруты и находятся ли они в порядке, который может вызвать проблемы.
Открывая проект Laravel в первый раз, вы обращаете внимание на несколько ключевых областей: Красноречивые режимы, Маршруты и Тесты. Вы открываете файл маршрутов и просматриваете зарегистрированные маршруты, чтобы понять размер приложения и то, как все собрано.
Если
вы устанавливаете Laravel Breeze, вы заметите, что он добавляет следующее в ваш файл routes/web.php:
equire __DIR__ . '/auth.php';
Это загружается в маршруты аутентификации, которые поставляются с пакетом, позволяя вам свести к минимуму вашего поставщика услуг и понять, сколько дополнительных файлов необходимо проверить для просмотра всех маршрутов. Давайте возьмем наш приведенный выше пример и добавим маршруты в этом подходе:
// The rest of your `routes/api.php` file
require __DIR__ . '/resource/catalog.php';
require __DIR__ . '/resource/orders.php';
require __DIR__ . '/resource/payments.php';
require __DIR__ . '/resource/deliveries.php';
Для меня это улучшение подхода поставщика услуг, поскольку вы, вероятно, будете иметь лучшую видимость в своем приложении при просмотре файлов маршрутов. Тем не менее, требование файлов - это то, что я ненавижу видеть. Это просто кажется грязным и ленивым.
Преимущества заключаются в том, что вы можете видеть вещи, необходимые для загрузки на всех маршрутах, в одном простом месте, где вы ожидаете увидеть маршруты. Недостатком, однако, является то, что это просто обязательный метод, который загружает файл при выполнении этого скрипта.
Для меня это может быть улучшено совсем немного. Здесь нет информации, говорящей о том, какой может быть структура URL-адресов или какое-либо дополнительное промежуточное ПО, которое, как вы знаете, применяется ко всем маршрутам.
Группы маршрутов
Это мой предпочтительный подход. Мы видим, что они используются в RouteServiceProvider, откуда я получил идею. Основной принцип здесь заключается в том, что в вашем основном файле маршрутов (routes/api.php в нашем случае) мы строим наши группы маршрутов, как если бы мы добавляли наши маршруты вручную, а затем сообщаем этой группе, что она должна использовать отдельный файл.
// The rest of your `routes/api.php` file
Route::prefix('catalog')->as('catalog:')->middleware(['auth:sanctum'])->group(
base_path('routes/resources/catalog.php'),
);
Route::prefix('orders')->as('orders:')->middleware(['auth:sanctum'])->group(
base_path('routes/resources/orders.php'),
);
Route::prefix('payments')->as('payments:')->middleware(['auth:sanctum'])->group(
base_path('routes/resources/payments.php'),
);
Route::prefix('deliveries')->as('deliveries:')->middleware(['auth:sanctum'])->group(
base_path('routes/resources/deliveries.php'),
);Как вы можете видеть из вышесказанного, мы просто используем base_path вспомогательную функцию для загрузки маршрутов в нужное место. Глядя на файл маршрутов, мы можем видеть, как группы создают ваше приложение, но оно не захватывает файл - даже если вы в конечном итоге получите 20-30 групп, он все равно довольно читабельный.
Отсюда мы можем управлять «ресурсами» и «подресурсами» в выделенном файле маршрутов, что означает меньшее количество классов имен классов во время импорта и наличие выделенных файлов, которые вы можете легко понять изолированно или в содержимом всего приложения.
Как вы боретесь с когнитивной нагрузкой обширного файла маршрутов? Вы нашли интересный способ, которым вы хотели бы поделиться? Сообщите нам об этом в Твиттере.
