Dans notre article précédent (Comment ajouter et implémenter des interfaces de traitement des paiements dans Laravel 11 : liaison codée en dur), nous avons exploré la première étape de la configuration des processeurs de paiement en codant en dur la liaison entre l'interface PaymentProcessorInterface. et une implémentation spécifique, comme StripePaymentProcessor.

Bien que cette approche soit simple et efficace pour les petites applications, elle manque de flexibilité pour des scénarios plus complexes dans lesquels vous pourriez avoir besoin de gérer plusieurs passerelles de paiement, mais l'utilisation d'une interface nous a permis de découpler le code afin de pouvoir l'étendre davantage. conformément au principe d'ouverture et de fermeture, pour injecter la fonctionnalité appropriée :

• liaison contextuelle au moment de la compilation, à l'aide du mécanisme Laravel Service Container.
• en utilisant un modèle d'usine instanciant les classes requises au moment de l'exécution.

Dans cette deuxième partie, nous plongerons dans la liaison contextuelle, une technique plus avancée dans le conteneur de services de Laravel qui vous permet d'injecter différentes implémentations d'une interface en fonction du contexte spécifique. Ceci est utile lorsque le choix d'un processeur de paiement dépend de l'état de l'application, par exemple quel contrôleur traite la demande.

Étape 1 : Comprendre la liaison contextuelle

La liaison contextuelle dans Laravel permet au conteneur de services d'injecter différentes implémentations d'une interface en fonction de la classe ou du contexte qui la demande. Au lieu de nous appuyer sur une seule implémentation codée en dur, nous pouvons utiliser la liaison contextuelle pour résoudre différents processeurs de paiement en fonction du contrôleur ou d'un autre facteur contextuel.

Étape 2 : liaison contextuelle dans AppServiceProvider

Commençons par configurer les liaisons contextuelles dans AppServiceProvider. Nous lierons différents processeurs de paiement en fonction du contrôleur qui les demande. Par exemple, StripePaymentController utilisera StripePaymentProcessor et PayPalPaymentController utilisera PayPalPaymentProcessor.

Voici comment procéder :

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

Que se passe-t-il ici ?

• $this->app->when() : cela indique à Laravel de lier une implémentation particulière d'une interface lorsqu'une classe spécifique (dans ce cas, un contrôleur) en a besoin.
• .needs() : ceci spécifie que la classe (StripePaymentController ou PayPalPaymentController) a besoin d'une instance de PaymentProcessorInterface.
• .give() : Ceci détermine quelle implémentation concrète fournir. Par exemple, StripePaymentController obtient StripePaymentProcessor et PayPalPaymentController obtient PayPalPaymentProcessor. Cette liaison vous permet de résoudre dynamiquement le bon processeur de paiement en fonction du contrôleur qui traite la demande.

Étape 3 : contrôleurs distincts pour chaque méthode de paiement

Avec la liaison contextuelle en place, chaque contrôleur peut désormais voir son processeur de paiement dédié injecté automatiquement. Voici comment configurer vos contrôleurs :

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

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

Dans les deux exemples, Laravel injecte automatiquement le bon processeur de paiement en fonction du contexte du contrôleur. Cela est dû à la liaison contextuelle configurée dans AppServiceProvider.

Pourquoi utiliser la liaison contextuelle ?

La liaison contextuelle est particulièrement utile lorsque vous savez quelle implémentation d'une interface utiliser en fonction de classes ou de contextes spécifiques, tels que les contrôleurs. Cela permet de garder votre code propre et gérable, en particulier lorsqu'il s'agit de plusieurs passerelles de paiement, chacune avec son propre contrôleur.

Conclusion

Dans cet article, nous avons exploré comment implémenter la liaison contextuelle dans Laravel 11 pour le traitement des paiements. Voici un bref récapitulatif des avantages de cette approche :

• Cleaner Code : pas besoin de logique manuelle pour choisir entre différents processeurs de paiement.
• Injection automatique : Laravel injecte automatiquement le bon processeur en fonction du contexte (contrôleur).
• Flexibilité : vous pouvez facilement étendre cette approche à d'autres parties de votre application, telles que différents services ou d'autres contextes. Quand utiliser la liaison contextuelle par rapport au modèle d'usine 
• Liaison contextuelle : idéale lorsque le processeur peut être sélectionné en fonction de classes spécifiques (comme différents contrôleurs) ou de contextes connus. Cela simplifie le code où le contexte est connu au moment de la compilation.
• Factory Pattern : utilisez le modèle Factory si vous souhaitez sélectionner dynamiquement un processeur de paiement en fonction des données d'exécution (par exemple, saisie utilisateur, demande API). Cette approche offre plus de flexibilité pour sélectionner le processeur de paiement, au moment de l'exécution, sur la base de données qui peuvent ne pas être connues avant le traitement de la demande.

Dans le prochain article, nous explorerons le Factory Pattern, qui permet une sélection dynamique des processeurs de paiement au moment de l'exécution, offrant encore plus de flexibilité pour les applications complexes.

Restez à l'écoute pour la prochaine partie, où nous expliquerons comment utiliser les usines pour le traitement des paiements dans Laravel 11 !