हमारी पिछली पोस्ट (लारवेल 11: हार्डकोडेड बाइंडिंग में भुगतान प्रोसेसिंग इंटरफेस कैसे जोड़ें और कार्यान्वित करें) में, हमने पेमेंटप्रोसेसरइंटरफेस के बीच बाइंडिंग को हार्डकोड करके भुगतान प्रोसेसर स्थापित करने के पहले चरण का पता लगाया। और एक विशिष्ट कार्यान्वयन, जैसे StripePaymentProcessor।

हालाँकि यह दृष्टिकोण छोटे अनुप्रयोगों के लिए सरल और प्रभावी है, लेकिन इसमें अधिक जटिल परिदृश्यों के लिए लचीलेपन का अभाव है जहाँ आपको कई भुगतान गेटवे को संभालने की आवश्यकता हो सकती है, लेकिन एक इंटरफ़ेस का उपयोग करके, हमें कोड को अलग करने की अनुमति दी गई ताकि हम इसे और बढ़ा सकें। खुले बंद सिद्धांत के अनुसार, उचित कार्यक्षमता को इंजेक्ट करने के लिए:

• संकलन समय पर प्रासंगिक बाइंडिंग, लारवेल सर्विस कंटेनर तंत्र का उपयोग करते हुए।
• फ़ैक्टरी पैटर्न का उपयोग करके रनटाइम पर आवश्यक कक्षाओं को तुरंत चालू करना।

इस दूसरे भाग में, हम प्रासंगिक बाइंडिंग में उतरेंगे, लारवेल के सर्विस कंटेनर में एक और अधिक उन्नत तकनीक जो आपको विशिष्ट संदर्भ के आधार पर इंटरफ़ेस के विभिन्न कार्यान्वयन को इंजेक्ट करने की अनुमति देती है। यह तब उपयोगी होता है जब भुगतान प्रोसेसर का चुनाव एप्लिकेशन स्थिति पर निर्भर करता है, जैसे कि कौन सा नियंत्रक अनुरोध को संभाल रहा है।

चरण 1: प्रासंगिक बंधन को समझना

लारवेल में प्रासंगिक बाइंडिंग सेवा कंटेनर को अनुरोध करने वाले वर्ग या संदर्भ के आधार पर इंटरफ़ेस के विभिन्न कार्यान्वयन को इंजेक्ट करने की अनुमति देता है। एकल, हार्डकोडेड कार्यान्वयन पर भरोसा करने के बजाय, हम नियंत्रक या किसी अन्य प्रासंगिक कारक के आधार पर विभिन्न भुगतान प्रोसेसर को हल करने के लिए प्रासंगिक बाइंडिंग का उपयोग कर सकते हैं।

चरण 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(): यह लारवेल को एक इंटरफ़ेस के एक विशेष कार्यान्वयन को बांधने के लिए कहता है जब एक विशिष्ट वर्ग (इस मामले में, एक नियंत्रक) को इसकी आवश्यकता होती है।
• .needs(): यह निर्दिष्ट करता है कि क्लास (StripePaymentController या PayPalPaymentController) को PaymentProcessorInterface के एक उदाहरण की आवश्यकता है।
• .give(): यह निर्धारित करता है कि कौन सा ठोस कार्यान्वयन प्रदान करना है। उदाहरण के लिए, StripePaymentController को StripePaymentProcessor मिलता है, और PayPalPaymentController को PayPalPaymentProcessor मिलता है। यह बाइंडिंग आपको सही भुगतान प्रोसेसर को गतिशील रूप से हल करने की अनुमति देती है, जो इस पर निर्भर करता है कि कौन सा नियंत्रक अनुरोध को संभाल रहा है।

चरण 3: प्रत्येक भुगतान विधि के लिए अलग नियंत्रक

प्रासंगिक बाइंडिंग के साथ, प्रत्येक नियंत्रक अब अपने समर्पित भुगतान प्रोसेसर को स्वचालित रूप से इंजेक्ट कर सकता है। यहां बताया गया है कि आप अपने नियंत्रक कैसे सेट कर सकते हैं:

उदाहरण: स्ट्राइपपेमेंटकंट्रोलर

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...
}

दोनों उदाहरणों में, लारवेल नियंत्रक संदर्भ के आधार पर स्वचालित रूप से सही भुगतान प्रोसेसर को इंजेक्ट करता है। यह AppServiceProvider में स्थापित प्रासंगिक बाइंडिंग के लिए धन्यवाद है।

प्रासंगिक बाइंडिंग का उपयोग क्यों करें?

प्रासंगिक बाइंडिंग विशेष रूप से तब उपयोगी होती है जब आप जानते हैं कि नियंत्रकों जैसे विशिष्ट वर्गों या संदर्भों के आधार पर इंटरफ़ेस के किस कार्यान्वयन का उपयोग करना है। यह आपके कोड को साफ और प्रबंधनीय बनाए रखने में मदद करता है, खासकर जब कई भुगतान गेटवे से निपटते समय, प्रत्येक का अपना नियंत्रक होता है।

निष्कर्ष

इस पोस्ट में, हमने यह पता लगाया है कि भुगतान प्रसंस्करण के लिए लारवेल 11 में प्रासंगिक बाइंडिंग को कैसे लागू किया जाए। यहां इस दृष्टिकोण के लाभों का एक त्वरित सारांश दिया गया है:

• क्लीनर कोड: विभिन्न भुगतान प्रोसेसरों के बीच चयन करने के लिए मैन्युअल तर्क की कोई आवश्यकता नहीं है।
• स्वचालित इंजेक्शन: लारवेल स्वचालित रूप से संदर्भ (नियंत्रक) के आधार पर सही प्रोसेसर को इंजेक्ट करता है।
• लचीलापन: आप इस दृष्टिकोण को अपने एप्लिकेशन के अन्य हिस्सों, जैसे विभिन्न सेवाओं या अन्य संदर्भों तक आसानी से बढ़ा सकते हैं। फ़ैक्टरी पैटर्न बनाम प्रासंगिक बाइंडिंग का उपयोग कब करें
• प्रासंगिक बाइंडिंग: आदर्श जब प्रोसेसर को विशिष्ट वर्गों (जैसे विभिन्न नियंत्रक) या ज्ञात संदर्भों के आधार पर चुना जा सकता है। यह उस कोड को सरल बनाता है जहां संकलन के समय संदर्भ ज्ञात होता है।
• फ़ैक्टरी पैटर्न: यदि आप रनटाइम डेटा (जैसे, उपयोगकर्ता इनपुट, एपीआई अनुरोध) के आधार पर गतिशील रूप से भुगतान प्रोसेसर का चयन करना चाहते हैं तो फ़ैक्टरी पैटर्न का उपयोग करें। यह दृष्टिकोण रनटाइम पर, डेटा के आधार पर भुगतान प्रोसेसर का चयन करने के लिए अधिक लचीलापन प्रदान करता है जो अनुरोध संसाधित होने तक ज्ञात नहीं हो सकता है।

अगली पोस्ट में, हम फ़ैक्टरी पैटर्न का पता लगाएंगे, जो रनटाइम पर भुगतान प्रोसेसर के गतिशील चयन की अनुमति देता है, जटिल अनुप्रयोगों के लिए और भी अधिक लचीलापन प्रदान करता है।

अगले भाग के लिए बने रहें, जहां हम बताएंगे कि लारवेल 11 में भुगतान प्रसंस्करण के लिए कारखानों का उपयोग कैसे करें!