𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 𝗶𝗻 𝗟𝗮𝗿𝗮𝘃𝗲𝗹

Your Laravel controllers often become dumping grounds for business logic.

You start with a simple registration flow. Soon, you add email notifications, Slack alerts, audit logs, and API calls to one single method. This creates a fat controller.

Fat controllers make your code fragile. They are hard to test. They break the Single Responsibility Principle.

You do not need complex tools like RabbitMQ to fix this. Laravel has a built-in event system that works for most needs.

The problem with tight coupling: If a newsletter API is slow, your user registration slows down. If a mail service fails, the entire request fails.

The solution: Event-Driven Architecture.

Events act as a middle layer. Your controller announces an action. Listeners react to that action independently.

A lean controller looks like this:

public function register(RegisterRequest $request) { $user = User::create($request->validated());

UserRegistered::dispatch($user);

return response()->json(['message' => 'Success'], 201);

}

The controller now only handles data persistence. It does not care about side effects.

You gain three major benefits:

• Performance: Users get a response immediately. Heavy tasks run in the background using the ShouldQueue interface.
• Resilience: If a service is down, the listener can retry the task without breaking the main application.
• Extensibility: You can add new features, like push notifications, by adding a new listener. You do not touch the original controller.

Best practices to follow:

• Focus on side effects: Use events for post-processing. Do not use them for core logic that must happen instantly.
• Use descriptive names: Use past-tense names like OrderPlaced or UserRegistered. This shows the action already happened.
• Avoid over-abstraction: If a piece of code is simple and used in one place, a function call is better than an event.

Use Eloquent Observers for database changes. Use Events for business actions.

Refactoring to events is about durability. It makes your code easier to debug and faster to test.

Pick one noisy side effect in your controller and move it to a listener today.

Try this sandbox example: https://onlinephp.io/c/1f7b2

ما وراء المتحكمات الضخمة: إتقان فك الارتباط القائم على الأحداث في Laravel

في عالم تطوير Laravel، جميعنا مررنا بهذا الموقف. تبدأ بمتحكم (Controller) بسيط، بضعة أسطر من الكود لمعالجة الطلب، وكل شيء يسير على ما يرام. ولكن مع نمو التطبيق، يبدأ هذا المتحكم في التضخم. يصبح مسؤولاً عن التحقق من البيانات (Validation)، ومنطق قاعدة البيانات، وإرسال رسائل البريد الإلكتروني، والتفاعل مع واجهات برمجة التطبيقات (APIs) الخارجية، والمزيد. هذا ما نسميه "المتحكم الضخم" (Fat Controller).

مشكلة المتحكمات الضخمة

تعتبر المتحكمات الضخمة كابوساً لعدة أسباب:

1. انتهاك مبدأ المسؤولية الواحدة (Single Responsibility Principle - SRP): يجب أن يكون المتحكم مسؤولاً فقط عن استقبال الطلب وإرجاع الاستجابة. عندما يبدأ في القيام بكل شيء آخر، يصبح من الصعب صيانته.
2. صعوبة الاختبار: اختبار متحكم يقوم بكل شيء هو أمر مرهق. ستحتاج إلى محاكاة (Mock) كل شيء، من قاعدة البيانات إلى مرسل البريد.
3. ضعف قابلية إعادة الاستخدام: إذا كنت بحاجة إلى تشغيل نفس المنطق من أمر CLI أو وظيفة (Job)، فلا يمكنك إعادة استخدام الكود الموجود داخل المتحكم بسهولة.
4. تكرار الكود: قد تجد نفسك تقوم بنسخ ولصق المنطق عبر متحكمات مختلفة.

الحل: البنية القائمة على الأحداث (Event-Driven Architecture)

بدلاً من جعل المتحكم يقوم بكل شيء، يمكننا استخدام نظام الأحداث (Events) والمستمعين (Listeners) المدمج في Laravel لفك الارتباط (Decoupling) في منطقنا.

كيف يعمل الأمر

1. الحدث (Event): الحدث هو فئة (Class) بسيطة تمثل شيئاً حدث في تطبيقك (مثل OrderPlaced).
2. المستمع (Listener): المستمع هو فئة "تستمع" لحدث معين وتنفذ إجراءً عند وقوعه (مثل SendOrderConfirmationEmail).

عند حدوث إجراء ما، تقوم بـ "إرسال" (Dispatch) حدث. بعد ذلك، يبحث Laravel عن جميع المستمعين المسجلين لهذا الحدث ويقوم بتنفيذهم.

تنفيذ الأحداث والمستمعين

لنفترض أن لدينا StoreOrderController. بدلاً من إرسال بريد إلكتروني مباشرة في المتحكم، سنقوم بإرسال حدث.

الخطوة 1: إنشاء الحدث

php artisan make:event OrderPlaced

الخطوة 2: إنشاء المستمع

php artisan make:listener SendOrderConfirmationEmail --event=OrderPlaced

الخطوة 3: إرسال الحدث في المتحكم

public function store(Request $request)
{
    // ... منطق إنشاء الطلب ...
    $order = Order::create($request->all());

    // إرسال الحدث
    event(new OrderPlaced($order));

    return response()->json(['message' => 'Order placed successfully!'], 201);
}

الخطوة 4: تنفيذ منطق المستمع

في app/Listeners/SendOrderConfirmationEmail.php:

public function handle(OrderPlaced $event)
{
    // الوصول إلى الطلب عبر $event->order
    Mail::to($event->order->user->email)->send(new OrderConfirmationMail($event->order));
}

فوائد فك الارتباط

• متحكمات نظيفة: تظل متحكماتك رشيقة ومركزة على وظيفتها الأساسية.
• القابلية للتوسع: يمكنك بسهولة إضافة المزيد من المستمعين لنفس الحدث دون تغيير المتحكم. على سبيل المثال، يمكنك إضافة مستمع UpdateInventory.
• المعالجة غير المتزامنة (Asynchronous Processing): يتيح لك Laravel تنفيذ المستمعين كمهام مجدولة (Queued Jobs)، مما يعني أن المستخدم لن يضطر للانتظار حتى يتم إرسال البريد الإلكتروني قبل تلقي الاستجابة.
• اختبار أفضل: يمكنك اختبار إرسال الحدث والمستمعين الفرديين بشكل منعزل.

الخاتمة

الابتعاد عن المتحكمات الضخمة والتوجه نحو بنية قائمة على الأحداث يجعل تطبيقات Laravel الخاصة بك أكثر قوة، وقابلية للصيانة، وقابلية للتوسع. إنه نمط أساسي يجب على كل مطور Laravel محترف إتقانه.