خبرکاو:

فایل های مسیرهای لاراول می توانند بسیار شلوغ شوند. قبل از اینکه متوجه شوید، باید در فایل routes جستجو کنید تا هر چیزی را پیدا کنید. با این حال، چگونه با این موضوع مبارزه می کنید؟

بسته به اینکه ترجیح می‌دهید چگونه به آن برخورد کنید، می‌توانید به روش‌های مختلفی به این موضوع نزدیک شوید. در این آموزش، چند گزینه را که دیده‌ام مرور می‌کنم و سپس نحوه برخوردم با این موضوع و چرایی برخورد با آن را به پایان می‌رسانم.

من از یک مثال ساده استفاده می کنم، اما شما می توانید کمی از تخیل خود استفاده کنید! تصور کنید ما در حال ساخت یک برنامه API هستیم که به مشتریان اجازه می دهد به صورت آنلاین از یک کاتالوگ سفارش دهند و مشتریان خود را قادر می سازد تا محموله ها را ردیابی کنند.

ارائه دهنده خدمات مسیر

با استفاده از ارائه دهنده خدمات مسیر، می توانید به راحتی ورودی های مسیر اضافی را اضافه کنید. بیایید به یک مثال نگاه کنیم:

 کلاس RouteServiceProvider گسترش می یابد ارائه دهنده خدمات
 {
    عمومی تابع بوت () : خالی
 {
        $this -> configureRateLimiting ();
        $this -> routes ( تابع () : باطل {
            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/api.php' ));
 })؛
 }
 }

این شبیه به RouteServiceProvider پیش‌فرض است که در پروژه لاراول خود دریافت می‌کنید. بسته به سن درخواست شما ممکن است متفاوت باشد. چگونه می توانیم این را تمدید کنیم؟ ما می توانیم بارگذاری مسیر اضافی را در ارائه دهنده اضافه کنیم:

 کلاس RouteServiceProvider گسترش می یابد ارائه دهنده خدمات
 {
    عمومی تابع بوت () : خالی
 {
        $this -> configureRateLimiting ();
        $this -> routes ( تابع () : باطل {
            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/api.php' ));
دیگر اخبار
6 روش برتر برای پاک کردن پیشنهادات/تاریخچه جستجوی اینستاگرام
بیشتر بخوانید
رنگ‌های قهرمان سری گلکسی S23 تایید شد، سنسورهای تصویر S23 Ultra جزئیات بیشتری دارند


            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/resource/catalog.php' ));
            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/resource/orders.php' ));
            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/resource/payments.php' ));
            مسیر :: میان افزار ( "api" )
                -> گروه ( base_path ( 'routes/resource/deliveries.php' ));
 })؛
 }
 }

هدف این نیست که کاملاً دقیق باشد. من از این بیشتر به عنوان مثال با چند قطعه متحرک استفاده می کنم که احتمالاً حداقل 75 مسیر دارند. پس در اینجا ما این را در RouteServiceProvider مدیریت می کنیم، پس همه چیز در نحوه بارگیری مسیرها مهم است. بزرگترین مشکلی که با این رویکرد پیدا کردم این است که وقتی در یک فایل مسیرها هستید، باید بدانید چه چیز دیگری در حال بارگذاری است. من قبلاً روی یک برنامه بسیار بزرگ کار می کردم که از این روش استفاده می کرد و تلاش ذهنی زیادی لازم بود تا به عقب برگردید تا ببینید آیا مسیرها در حال بارگیری هستند و آیا نظمی دارند که می‌تواند باعث ایجاد مشکلاتی شود.

هنگام باز کردن یک پروژه لاراول برای اولین بار، به چند بخش کلیدی توجه می کنید: حالت های Eloquent، مسیرها و تست ها. شما فایل مسیرها را باز می‌کنید و مسیرهای ثبت‌شده را نگاه می‌کنید تا اندازه برنامه و نحوه چیدمان چیزها را درک کنید.

نیاز به فایل

اگر Laravel Breeze را نصب کنید، متوجه خواهید شد که موارد زیر را به فایل routes/web.php شما اضافه می کند:

 نیاز __DIR__ . '/auth.php' ;

این در مسیرهای احراز هویت همراه با بسته بارگیری می‌شود و به شما این امکان را می‌دهد که ارائه‌دهنده خدمات خود را به حداقل برسانید و بفهمید که چه تعداد فایل اضافی برای مشاهده همه مسیرها باید تحلیل شوند. بیایید مثال بالا را در نظر بگیریم و مسیرها را در این رویکرد اضافه کنیم:

 // بقیه فایل 'routes/api.php' شما
 نیاز __DIR__ . '/resource/catalog.php' ;
 نیاز __DIR__ . '/resource/orders.php' ;
 نیاز __DIR__ . '/resource/payments.php' ;
 نیاز __DIR__ . '/resource/deliveries.php' ;

به نظر من، این یک پیشرفت در رویکرد ارائه دهنده خدمات است، زیرا به احتمال زیاد هنگام مرور فایل های مسیر، دید بهتری در برنامه خود خواهید داشت. با این حال، نیاز به فایل ها چیزی است که من از دیدن آن متنفرم. فقط احساس کثیف و تنبلی می کند.

مزایا این است که می‌توانید موارد مورد نیاز برای بارگیری در همه مسیرها را در یک مکان ساده که انتظار دارید مسیرها را ببینید، مشاهده کنید. اما نکته منفی این است که فقط یک روش ضروری است که فایل را هنگام اجرای این اسکریپت بارگیری می کند.

برای من، این را می توان تا حدودی بهبود بخشید. هیچ اطلاعاتی در اینجا وجود ندارد که بگوید ساختار URL چگونه ممکن است باشد یا هر میان افزار اضافی که می دانید در همه مسیرها اعمال می شود.

گروه های مسیر

این رویکرد ترجیحی من است. ما می بینیم که آنها در RouteServiceProvider استفاده می شوند، جایی که من ایده را از آنجا گرفتم. اصل اساسی در اینجا این است که در فایل مسیرهای اصلی شما (در مورد ما routes/api.php )، گروه‌های مسیر خود را مانند زمانی که مسیرهای خود را به صورت دستی اضافه می‌کردیم می‌سازیم و سپس به آن گروه می‌گوییم که باید از یک فایل جداگانه استفاده کند.

 // بقیه فایل 'routes/api.php' شما
 Route :: prefix ( 'catalog' ) -> as ( 'catalog:' ) -> middleware ([ 'auth:sanctum' ]) -> group (
    base_path ( 'routes/resources/catalog.php' )،
 )
 مسیر :: پیشوند ( 'سفارش ها' ) -> به عنوان ( 'سفارش ها:' ) -> میان افزار ([ 'auth:sanctum' ]) -> گروه (
    base_path ( 'routes/resources/orders.php' )،
 )
 مسیر :: پیشوند ( 'پرداخت ها' ) -> به عنوان ( 'پرداخت ها:' ) -> میان افزار ([ 'auth:sanctum' ]) -> گروه (
    base_path ( 'routes/resources/payments.php' )،
 )
 مسیر :: پیشوند ( 'تحویل' ) -> به عنوان ( 'تحویل:' ) -> میان افزار ([ 'auth:sanctum' ]) -> گروه (
    base_path ( 'routes/resources/deliveries.php' )،
 )

همانطور که در بالا می بینید، ما فقط از تابع helper base_path برای بارگذاری مسیرها در مکان مناسب استفاده می کنیم. با نگاهی به فایل مسیرها، می‌توانیم گروه‌ها را ببینیم که برنامه شما را ایجاد می‌کنند، اما این فایل را در اختیار نمی‌گیرد - حتی اگر در نهایت 20 تا 30 گروه داشته باشید، باز هم بسیار قابل خواندن است.

از اینجا می‌توانیم «منابع» و «منابع فرعی» را در فایل مسیرهای اختصاصی مدیریت کنیم، یعنی کلاس‌های نام کلاس کمتری در حین واردات و داشتن فایل‌های اختصاصی که به‌راحتی می‌توانید به‌صورت مجزا یا در محتوای کل برنامه‌تان درک کنید.

چگونه با بار شناختی یک فایل مسیرهای گسترده مبارزه می کنید؟ آیا راه جالبی پیدا کرده اید که می خواهید به اشتراک بگذارید؟ در توییتر به ما اطلاع دهید.

خبرکاو