In unserem vorherigen Beitrag (So fügen Sie Zahlungsverarbeitungsschnittstellen in Laravel 11 hinzu und implementieren sie: Fest codierte Bindung) haben wir den ersten Schritt beim Einrichten von Zahlungsabwicklern durch die Festcodierung der Bindung zwischen der PaymentProcessorInterface untersucht und eine spezifische Implementierung, wie StripePaymentProcessor.

Während dieser Ansatz für kleine Anwendungen einfach und effektiv ist, mangelt es ihm an Flexibilität für komplexere Szenarien, in denen Sie möglicherweise mehrere Zahlungsgateways verwalten müssen. Durch die Verwendung einer Schnittstelle konnten wir den Code jedoch entkoppeln, sodass wir ihn weiter erweitern können. in Übereinstimmung mit dem Öffnen-Schließen-Prinzip, um die richtige Funktionalität einzufügen:

• Kontextbindung zur Kompilierungszeit unter Verwendung des Laravel Service Container-Mechanismus.
• Verwendung eines Factory-Musters, das die erforderlichen Klassen zur Laufzeit instanziiert.

In diesem zweiten Teil werden wir uns mit der kontextuellen Bindung befassen, einer fortgeschritteneren Technik im Service-Container von Laravel, die es Ihnen ermöglicht, verschiedene Implementierungen einer Schnittstelle basierend auf dem spezifischen Kontext einzufügen. Dies ist nützlich, wenn die Wahl eines Zahlungsabwicklers vom Anwendungsstatus abhängt, beispielsweise davon, welcher Controller die Anfrage bearbeitet.

Schritt 1: Kontextuelle Bindung verstehen

Kontextbindung in Laravel ermöglicht es dem Servicecontainer, je nach anfordernder Klasse oder Kontext unterschiedliche Implementierungen einer Schnittstelle einzufügen. Anstatt uns auf eine einzelne, fest codierte Implementierung zu verlassen, können wir kontextbezogene Bindung verwenden, um verschiedene Zahlungsabwickler basierend auf dem Controller oder einem anderen kontextbezogenen Faktor aufzulösen.

Schritt 2: Kontextuelle Bindung im AppServiceProvider

Beginnen wir mit der Konfiguration kontextbezogener Bindungen im AppServiceProvider. Wir werden verschiedene Zahlungsabwickler binden, je nachdem, welcher Verantwortliche sie anfordert. Beispielsweise verwendet der StripePaymentController StripePaymentProcessor und der PayPalPaymentController verwendet PayPalPaymentProcessor.

So können Sie es tun:

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);
}

Was passiert hier?

• $this->app->when(): Dies weist Laravel an, eine bestimmte Implementierung einer Schnittstelle zu binden, wenn eine bestimmte Klasse (in diesem Fall ein Controller) sie benötigt.
• .needs(): Dies gibt an, dass die Klasse (StripePaymentController oder PayPalPaymentController) eine Instanz von PaymentProcessorInterface benötigt.
• .give(): Dies bestimmt, welche konkrete Implementierung bereitgestellt werden soll. Beispielsweise erhält StripePaymentController den StripePaymentProcessor und PayPalPaymentController den PayPalPaymentProcessor. Mit dieser Bindung können Sie den richtigen Zahlungsprozessor dynamisch auflösen, je nachdem, welcher Controller die Anfrage bearbeitet.

Schritt 3: Separate Controller für jede Zahlungsmethode

Mit der kontextuellen Bindung kann nun jeder Controller seinen dedizierten Zahlungsprozessor automatisch einbinden lassen. So können Sie Ihre Controller einrichten:

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

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

In beiden Beispielen fügt Laravel basierend auf dem Controller-Kontext automatisch den richtigen Zahlungsprozessor ein. Dies ist der im AppServiceProvider eingerichteten Kontextbindung zu verdanken.

Warum kontextbezogene Bindung verwenden?

Kontextbindung ist besonders nützlich, wenn Sie wissen, welche Implementierung einer Schnittstelle basierend auf bestimmten Klassen oder Kontexten, z. B. Controllern, verwendet werden soll. Es trägt dazu bei, dass Ihr Code sauber und verwaltbar bleibt, insbesondere wenn Sie mit mehreren Zahlungsgateways arbeiten, von denen jedes über einen eigenen Controller verfügt.

Abschluss

In diesem Beitrag haben wir untersucht, wie man kontextbezogene Bindung in Laravel 11 für die Zahlungsabwicklung implementiert. Hier ist eine kurze Zusammenfassung der Vorteile dieses Ansatzes:

• Saubererer Code: Keine manuelle Logik erforderlich, um zwischen verschiedenen Zahlungsabwicklern zu wählen.
• Automatische Injektion: Laravel injiziert automatisch den richtigen Prozessor basierend auf dem Kontext (Controller).
• Flexibilität: Sie können diesen Ansatz problemlos auf andere Teile Ihrer Anwendung erweitern, beispielsweise auf verschiedene Dienste oder andere Kontexte. Wann sollte kontextbezogene Bindung im Vergleich zum Factory-Muster verwendet werden
• Kontextbindung: Ideal, wenn der Prozessor basierend auf bestimmten Klassen (wie verschiedenen Controllern) oder bekannten Kontexten ausgewählt werden kann. Es vereinfacht den Code, bei dem der Kontext zur Kompilierungszeit bekannt ist.
• Factory-Muster: Verwenden Sie das Factory-Muster, wenn Sie einen Zahlungsprozessor basierend auf Laufzeitdaten (z. B. Benutzereingaben, API-Anfrage) dynamisch auswählen möchten. Dieser Ansatz bietet mehr Flexibilität bei der Auswahl des Zahlungsabwicklers zur Laufzeit, basierend auf Daten, die möglicherweise erst bei der Verarbeitung der Anfrage bekannt sind.

Im nächsten Beitrag werden wir uns mit dem Factory Pattern befassen, das eine dynamische Auswahl von Zahlungsabwicklern zur Laufzeit ermöglicht und so noch mehr Flexibilität für komplexe Anwendungen bietet.

Seien Sie gespannt auf den nächsten Teil, in dem wir uns mit der Nutzung von Fabriken für die Zahlungsabwicklung in Laravel 11 befassen!