"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > تنفيذ الربط السياقي في وقت الترجمة لمعالجة الدفع في Laravel 11

تنفيذ الربط السياقي في وقت الترجمة لمعالجة الدفع في Laravel 11

تم النشر بتاريخ 2024-11-09
تصفح:107

Implementing Contextual Binding at Compile Time for Payment Processing in Laravel 11

في منشورنا السابق (كيفية إضافة وتنفيذ واجهات معالجة الدفع في Laravel 11: الربط المشفر)، استكشفنا الخطوة الأولى في إعداد معالجات الدفع عن طريق تشفير الارتباط بين واجهة PaymentProcessorInterface. وتنفيذ محدد، مثل StripePaymentProcessor.

على الرغم من أن هذا الأسلوب بسيط وفعال للتطبيقات الصغيرة، إلا أنه يفتقر إلى المرونة في السيناريوهات الأكثر تعقيدًا حيث قد تحتاج إلى التعامل مع بوابات دفع متعددة، ولكن باستخدام واجهة، سمح لنا بفصل الكود حتى نتمكن من توسيعه بشكل أكبر، وفقًا لمبدأ الإغلاق المفتوح، لحقن الوظيفة المناسبة:

  • الربط السياقي في وقت الترجمة، باستخدام آلية حاوية خدمة Laravel.
  • استخدام نمط المصنع لإنشاء مثيل للفئات المطلوبة في وقت التشغيل.

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

الخطوة 1: فهم الربط السياقي

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

الخطوة 2: الربط السياقي في AppServiceProvider

لنبدأ بتكوين الارتباطات السياقية في AppServiceProvider. سنقوم بربط معالجات الدفع المختلفة بناءً على وحدة التحكم التي تطلبها. على سبيل المثال، ستستخدم StripePaymentController StripePaymentProcessor، وستستخدم PayPalPaymentController PayPalPaymentProcessor.

إليك كيفية القيام بذلك:

use App\Contracts\PaymentProcessorInterface;
use App\Services\StripePaymentProcessor;
use App\Services\PayPalPaymentProcessor;

public function register()
{
    $this->app->when(StripePaymentController::class)
              ->needs(PaymentProcessorInterface::class)
              ->give(StripePaymentProcessor::class);

    $this->app->when(PayPalPaymentController::class)
              ->needs(PaymentProcessorInterface::class)
              ->give(PayPalPaymentProcessor::class);
}

ماذا يحدث هنا؟

  • $this->app->when(): هذا يخبر Laravel بربط تنفيذ معين للواجهة عندما يحتاجها فئة معينة (في هذه الحالة، وحدة التحكم).
  • .needs(): يحدد هذا أن الفئة (StripePaymentController أو PayPalPaymentController) تحتاج إلى مثيل لـ PaymentProcessorInterface.
  • .give(): هذا يحدد التنفيذ الملموس الذي يجب توفيره. على سبيل المثال، يحصل StripePaymentController على StripePaymentProcessor، ويحصل PayPalPaymentController على PayPalPaymentProcessor. يتيح لك هذا الربط حل معالج الدفع الصحيح ديناميكيًا اعتمادًا على وحدة التحكم التي تتعامل مع الطلب.

الخطوة 3: وحدات تحكم منفصلة لكل طريقة دفع

مع وجود الربط السياقي، يمكن الآن لكل وحدة تحكم أن يتم حقن معالج الدفع المخصص لها تلقائيًا. إليك كيفية إعداد وحدات التحكم الخاصة بك:

مثال: StripePaymentController

use App\Contracts\PaymentProcessorInterface;

class StripePaymentController extends Controller
{
    protected $paymentProcessor;

    public function __construct(PaymentProcessorInterface $paymentProcessor)
    {
        $this->paymentProcessor = $paymentProcessor;
    }

    // Methods to handle Stripe-specific payments...
}

مثال: PayPalPaymentController

use App\Contracts\PaymentProcessorInterface;

class PayPalPaymentController extends Controller
{
    protected $paymentProcessor;

    public function __construct(PaymentProcessorInterface $paymentProcessor)
    {
        $this->paymentProcessor = $paymentProcessor;
    }

    // Methods to handle PayPal-specific payments...
}

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

لماذا استخدام الربط السياقي؟

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

خاتمة

في هذا المنشور، اكتشفنا كيفية تنفيذ الربط السياقي في Laravel 11 لمعالجة الدفع. فيما يلي ملخص سريع لفوائد هذا النهج:

  • رمز المنظف: لا حاجة للمنطق اليدوي للاختيار بين معالجات الدفع المختلفة.
  • الحقن التلقائي: يقوم Laravel تلقائيًا بإدخال المعالج الصحيح بناءً على السياق (وحدة التحكم).
  • المرونة: يمكنك بسهولة توسيع هذا النهج ليشمل أجزاء أخرى من تطبيقك، مثل الخدمات المختلفة أو السياقات الأخرى. متى يتم استخدام الربط السياقي مقابل نمط المصنع
  • الربط السياقي: مثالي عندما يمكن تحديد المعالج بناءً على فئات محددة (مثل وحدات التحكم المختلفة) أو السياقات المعروفة. إنه يبسط الكود حيث يكون السياق معروفًا في وقت الترجمة.
  • نمط المصنع: استخدم نمط المصنع إذا كنت تريد تحديد معالج الدفع ديناميكيًا بناءً على بيانات وقت التشغيل (على سبيل المثال، إدخال المستخدم، طلب واجهة برمجة التطبيقات). يوفر هذا الأسلوب المزيد من المرونة لاختيار معالج الدفع، في وقت التشغيل، بناءً على البيانات التي قد لا تكون معروفة حتى تتم معالجة الطلب.

في المقالة التالية، سنستكشف نمط المصنع، الذي يسمح بالاختيار الديناميكي لمعالجات الدفع في وقت التشغيل، مما يوفر المزيد من المرونة للتطبيقات المعقدة.

ترقبوا الجزء التالي، حيث سنغطي كيفية استخدام المصانع لمعالجة الدفع في Laravel 11!

بيان الافراج تم إعادة نشر هذه المقالة على: https://dev.to/websilvercraft/implementing-contextual-binding-at-compile-time-for-Payment-processing-in-laravel-11-3h9g?1 إذا كان هناك أي انتهاك، من فضلك اتصل بـ [email protected]
أحدث البرنامج التعليمي أكثر>

تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.

Copyright© 2022 湘ICP备2022001581号-3