前回の投稿(Laravel 11 で決済処理インターフェイスを追加および実装する方法: ハードコードされたバインディング) では、PaymentProcessorInterface 間のバインディングをハードコーディングすることで決済プロセッサを設定する最初のステップを検討しました。 StripePaymentProcessor などの特定の実装。

このアプローチは小規模なアプリケーションにはシンプルで効果的ですが、複数の支払いゲートウェイを処理する必要があるより複雑なシナリオには柔軟性に欠けますが、インターフェイスを使用することでコードを分離できるため、コードをさらに拡張できます。オープンクローズ原則に従って、適切な機能を注入します:

• Laravel サービスコンテナメカニズムを使用した、コンパイル時のコンテキストバインディング。
• 実行時に必要なクラスをインスタンス化するファクトリ パターンを使用します。

この第 2 部では、特定のコンテキストに基づいてインターフェイスのさまざまな実装を挿入できる、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 はコンテキスト (コントローラー) に基づいて正しいプロセッサを自動的にインジェクションします。
• 柔軟性: このアプローチは、さまざまなサービスや他のコンテキストなど、アプリケーションの他の部分に簡単に拡張できます。 コンテキスト バインディングとファクトリ パターンを使用する場合
• コンテキスト バインディング: 特定のクラス (さまざまなコントローラーなど) または既知のコンテキストに基づいてプロセッサを選択できる場合に理想的です。コンパイル時にコンテキストが分かるコードを簡素化します。
• ファクトリー パターン: 実行時データ (ユーザー入力、API リクエストなど) に基づいて支払いプロセッサを動的に選択する場合は、ファクトリー パターンを使用します。このアプローチにより、リクエストが処理されるまでわからない可能性のあるデータに基づいて、実行時に支払処理業者をより柔軟に選択できます。

次の投稿では、実行時に決済プロセッサを動的に選択できるようにして、複雑なアプリケーションにさらなる柔軟性を提供するファクトリー パターンについて説明します。

次のパートでは、Laravel 11 での支払い処理にファクトリーを使用する方法について説明しますので、お楽しみに!