يا هلا بيك يا باشمهندس في عالم تطوير الويب (Web Development). تعال نتكلم في موضوع بيحصل قدامنا كلنا واحنا شغالين بمبدأ تطوير الويب الشامل (Full Stack Development) وبالخصوص واحنا بنبني تطبيقات باستخدام إطار العمل القوي لارافيل (Laravel Framework).

تخيل معايا كده، فاتح ملف الـ Controller بتاع الـ Users مثلاً، ورايح تكتب دالة تخزين مستخدم جديد (Store Method). وفجأة تلاقي نفسك كاتب عشرين سطر للصلاحيات (Authorization)، وبعدهم خمسين سطر للتحقق من البيانات (Validation)، وشوية حاجات تانية خاصة بقاعدة البيانات (Database Queries). تلاقي ملف الكنترولر بقى شبه "صندوق العجب"، حجمه عدى الـ 300 سطر، وكل ما تحب تعدل حاجة، تلاقي نفسك بتلخبط الدنيا!

الوجع ده يا صاحبي بيحصل لما بنكسر أهم مبدأ في هندسة البرمجيات (Software Engineering)، وهو مبدأ المسؤولية الفردية أو المسؤولية الواحدة (Single Responsibility Principle - SRP). المبدأ ده باختصار بيقولك: "خلي لكل كลาส شغلة واحدة بس يعملها وبيعملها صح". ومن هنا بتظهر الحاجة الملحة لاستخدام طلبات النماذج أو ما يُعرف بـ (Form Requests).

إيه هي الـ Form Requests وازاي بتنقذ الكود بتاعك؟

الـ Form Requests في لارافيل هي باختصار عبارة عن كلاسات (Classes) مستقلة بذاتها، شغلتها الوحيدة في الحياة إنها تستقبل الطلب القادم من المستخدم (HTTP Request)، وتتأكد إن البيانات دي سليمة ومطابقة للشروط (Validation)، وهل المستخدم ده من أصله مسموح له يعمل الطلب ده ولا لأ (Authorization).

لما بنستخدم الـ Form Requests، إحنا بنطبق مبدأ الفصل بين الاهتمامات (Separation of Concerns). الـ Controller بتاعك بيرتاح، وبيتركز شغله الأساسي في إنه يستلم البيانات الجاهزة والنظيفة والمؤمنة، ويوجهها للمكان الصح (زي الـ Models أو Services)، وبعدين يرجع الرد للمستخدم.

إزاي تنشئ وتشغل Form Request باحترافية؟

عشان نبسط الموضوع، تعال نتخيل إننا بنعمل نظام لتسجيل المستخدمين (User Registration). بدل ما نكتب الشغل كله جوه الـ UserController، هنعمل كลาส منفصل مسؤول عن القصة دي باستخدام سطر كود بسيط في الـ Terminal:

php artisan make:request StoreUserRequest

الأمر ده هيخلق لك ملف جديد جوه مسار app/Http/Requests/StoreUserRequest.php. لو فتحت الملف ده هتلاقي فيه دالتين أساسيتين:

• دالة authorize(): ودي المسؤولة عن الصلاحيات (Authorization)، بترجع true لو المستخدم يقدر يعمل الطلب، أو false لو ممنوع.
• دالة rules(): ودي اللي بتحط فيها قواعد التحقق (Validation Rules) زي الإيميل والباسورد وغيرهم.

شرح عملي: الكود قبل وبعد الـ Form Requests

تعال نشوف شكل الكود السيء (Anti-pattern) اللي كلنا بنحاول نبعد عنه في الـ Controllers، وبعدين نشوف إزاي بيتحول لتحفة فنية نظيفة.

الكود القديم والزحمة (داخل الـ Controller):

public function store(Request $request)
{
    // شروط التحقق زاحمة الدنيا هنا
    $request->validate([
        'name' => 'required|string|max:255',
        'email' => 'required|email|unique:users',
        'password' => 'required|min:8',
    ]);

    // تحقق من الصلاحيات بطريقة مش منظمة
    if (!auth()->user()->isAdmin()) {
        abort(403);
    }

    // حفظ البيانات
    User::create($request->all());

    return response()->json(['message' => 'تم إنشاء المستخدم بنجاح']);
}

شايف المنظر؟ الكنترولر بيعمل حاجات كتيرة قوي مالوش دعوة بيها. تعال بقى نشوف الشكل النظيف والمحترف بعد استخدام الـ Form Requests:

أولاً: كلاس الـ Form Request (المنظف والمخصص):

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StoreUserRequest extends FormRequest
{
    public function authorize(): bool
    {
        // هنا ممكن تحط لوجيك الصلاحيات الحقيقي بتاعك
        return true; 
    }

    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'email', 'unique:users,email'],
            'password' => ['required', 'string', 'min:8'],
        ];
    }
}

ثانياً: الـ Controller بعد التنظيف والجمال:

use App\Http\Requests\StoreUserRequest;

public function store(StoreUserRequest $request)
{
    // الكنترولر هنا مطمن ومرتاح! البيانات وصلت جاهزة وصحيحة 100%
    
    $user = User::create($request->validated());

    return response()->json([
        'message' => 'تم إنشاء المستخدم بنجاح',
        'data' => $user
    ]);
}

لاحظ إننا استخدمنا $request->validated() عشان نجيب البيانات اللي عدت من اختبارات التحقق بس، وده بيدينا أمان إضافي وبيمنع أي بيانات خبيثة إنها تدخل على قاعدة البيانات.

ليه لازم تعتمد على الـ Form Requests في مشاريعك؟

فيه أسباب كتير بتخلي استخدام الطريقة دي ضرورة مش رفاهية:

• إمكانية إعادة الاستخدام (Reusability): لو عندك نفس الويب فอร์م أو الـ API Endpoint بيستخدم نفس قواعد التحقق في كذا مكان، مش هتعيد كتابة الكود، هتعمل استدعاء لنفس الـ Form Request.
• سهولة الصيانة (Maintainability): لو حبّ العملاء يطلبوا تعديل في شروط كلمة المرور، هترروح لملف واحد بس تعدل فيه، بدل ما تدور جوه عشرات الـ Controllers.
• كود نظيف (Clean Code): بتخلي زمايلك في الفريق (أو أنت نفسك بعد 6 شهور) تفتح الكود وتفهمه في ثواني معدودة.

خاتمة ونصيحة من أخ

يا صاحبي، البرمجة مش بس كود بيشتغل، البرمجة كود نضيف، مقروء، وسهل التعديل عليه. ماتستصعبش أبداً إنك تعمل كلاسات زيادة في مشروعك؛ لأن الزيادة دي هي اللي بتحمي مشروعك من الكارثة لما يكبر ويتحول لـ Legacy Code معقد. عود نفسك من النهارده إن أي Request جاي فيه Validation أو Authorization، مكانه الطبيعي مش الكنترولر، مكانه Form Request مستقل. بالتوفيق، ودايماً اكتب كود تفتخر بيه!