احسان رضایی

روت‌ها/Routes در پروژه های بزرگ لاراولی ممکن هست زیاد و شلوغ بشن، خوانایی پایین بیاد و هنگام ویرایش دچار سردرگمی بشین. در این مطلب سه روش برای حل این مشکل رو توضیح میدم و شما میتونید با توجه به پروژه و ارزیابی خودتون یکی رو انتخاب کنید.

استفاده از RouteServiceProvider

این Provider مسیر های تعریف شده رو در routes/web.php و routes/api.php لود میکنه. میتونید روت‌ها رو به فایل‌های کوچک‌تر تبدیل و در RouteServiceProvider تعریفشون کنید. دقیقا مثل کاری که به طور پیشفرض با web.php و api.php انجام داده. در مثال زیر متد بوت RouteServiceProvider رو ویرایش و posts رو اضافه کردم. در routes/posts.php مسیر های مربوط به ماژول post من قرار داره.

    public function boot()
    {
        $this->configureRateLimiting();

        $this->routes(function () {
            Route::middleware('api')
                ->prefix('api')
                ->group(base_path('routes/api.php'));

            Route::middleware('web')
                ->group(base_path('routes/web.php'));

            // new routes.
            Route::middleware('api')
                ->group(base_path('routes/posts.php'));
        });
    }

به نظرم این روش پیچیدگی روت‌های زیاد رو حل میکنه اما یک پیچیدگی جدید به وجود میاره. شما و همکارانتون باید بدونید از یک روش و محل دیگه ای برای لود مسیرها استفاده کردین. در صورتی که توقع میره روت‌ها و تعریفشون در پوشه routes باشن.

لاراول اسکات / Laravel Scout ابزاری برای قابلیت جستجوی تمام متن(full-text search) در مدل هاست. از درایور هایی مانند Algolia، Meilisearch و خود database لاراول(در حال حاضر MySQL یا PostgreSQL) پشتیانی میکنه.

با یک مثال ساده نصب و استفاده از Scout رو ادامه میدم، فرض کنید جدولی به نام contents با فیلدهای id, title, abstract و text داریم که محتوای وبسایت شما رو در بر میگیره.

نصب لاراول اسکات / Laravel Scout

ابتدا با استفاده از کامپورز و دستور زیر لاراول اسکات رو نصب میکنیم.

composer require laravel/scout

سپس با artisan vendor:publish فایل پیکربندی اسکات رو به پوشه config اضافه میکنیم.

php artisan vendor:publish --provider="Laravel\Scout\ScoutServiceProvider"

فایل پیکربندی رو باز کنید. (config/scout.php)

همونطور که میبینید driver به طور پیشفرض algolia ست شده. در این مثال تصمیم دارم از PostgreSQL استفاده کنم پس داخل .env مقدار SCOUT_DRIVER رو database قرار میدم. تمام!

SCOUT_DRIVER=database

هنگام پیاده سازی API یکی از شیوه های بسیار کاربردی و مفیدی که میشه استفاده کرد API Resources هست. با استفاده از این روش به جای پاس دادن مدل یا آرایه ای از مدل ها به عنوان response، لایه ای بین Eloquent و خروجی JSON تعریف میشه. در این لایه که Resource/منبع نام داره دقیقا مشخص میکنیم چه دیتایی به عنوان JSON پاس بدیم. این کار باعث میشه response همون چیزی باشه که نیازش داریم، بدون اضافات. یا اینکه ممکن هست لازم بشه همیشه همراه با مدل، روابط خاصی رو هم داشته باشیم و یا در جاهای خاص، خروجی متفاوتی از یک مدل رو به نمایش بذاریم.

به عنوان مثال جدول کاربران شامل نام و نام خانوادگی، بیو، ایمیل، تاریخ ایجاد، بروزرسانی و حذف(deleted_at) رو در نظر بگیرید. برای سرویس لیست کاربران قرار نیست متن بیو رو نشون بدیم. deleted_at هم که برای soft delete هست و 99 درصد اوقات کلا نیازی به نمایش نداریم. پس همونطور که جلوتر پیاده سازیش رو توضیح میدم، دوتا Resource ایجاد میکنیم، یکی برای لیست کاربران که فیلدهای id, name, email  در اون تعریف میشه و یکی هم برای نمایش تکی کاربر که شامل تمام فیلدهاست.

شاید با خودتون فکر کنید بدون API Resources در لاراول هم میشه این کار رو انجام داد. بله اما تمیز نیست و قابلیت استفاده مجدد مثل Resources هم ندارید.

لاراول پاینت / laravel pint یه code style fixer بر پایه PHP-CS-Fixer هست که به طور خودکار اشتباهات خارج از سبک و اصول کدنویسی رو اصلاح میکنه. البته خود PHP-CS-Fixer قابلیت ادقام با اکثر editor و IDE های محبوب رو داره اما به نظرم آوردنش توی لاراول و استفاده ازش آسونتره.
لاراول پاینت / laravel pint موقع ادغام سورس کدهای خارجی/قدیمی یا زمانی که کد شما دچار بدهی فنی شده کاربرد داره.

لاراول پاینت / laravel pint به طور کلی چه کارهایی رو انجام میده؟

- مرتب کردن کامنت های چند خطی

- اصلاح سینتکس و مرتب کردن تو رفتگی آرایه‌ها(داخل کد های قدیمی آرایه رو با array() تعریف میکردیم اما سینتکس جدیدش به [] تغییر پیدا کرده.)

- خط خالی بعد از namespace و tag های php

- ترکیب isset و unset های متوالی

// before
if (isset($a) && isset($b)) {}

unset($a);
unset($b);

// after
if (isset($a, $b)) {}

unset($a, $b);

حتما چنین کدی رو قبلا دیدین:

    public function index() : JsonResponse
    {
        $cars = Car::with('facilities', 'type', 'color', 'rentalDetail')->all();
        return response()->json($cars, 200);
    }

هوم... . مورد بدی توش دیده نمیشه. یک سرویس ساده که لیست خودرو ها رو میده. اما منطق/logic توی کنترلر نوشته شده. هر چند به عقیده من آوردن منطق در کنترلر برای app های کوچک مشکلی به وجود نمیاره اما با رشد نرم افزار بیشتر و بیشتر نیاز به یک ساختار منسجم و متمرکز رو حس میکنید.

به عنوان یک روش جایگزین و بهتر میشه از الگوی طراحی مخزن یا بهتر هست بگیم Repository Design Pattern استفاده کرد. مثل همیشه ساده بگم، در این روش مسئولیت ارتباط و استخراج داده ها رو از روی دوش مدل برمیداریم و اون رو در کلاس های Repository پیاده میکنیم، داخل کنترلر هم فقط متد هاشون رو صدا میزنیم.

    public function index() : JsonResponse
    {
        $cars = $this->carRepository->get();
        return response()->json($cars, 200);
    }

این روش مزیت های زیادی داره از جمله:

- ایجاد ساختاری منسجم و متمرکز
- حذف کد های تکراری
- توسعه و نگهداری آسانتر
- کاهش خطا و خطایابی سریعتر
- از بین بردن وابستگی های بین مدل و کنترلر
- کد تمیز و واضحتر

خب به نظرم توضیحات تا همین اندازه کافی هست و بهتره بریم سراغ یک نمونه ساده از پیاده سازی این روش تا مزایایی که بهمون میده رو بیشتر درک کنید.