이전 게시물(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은 컨텍스트(컨트롤러)에 따라 올바른 프로세서를 자동으로 주입합니다.
• 유연성: 이 접근 방식을 다른 서비스나 다른 컨텍스트와 같은 애플리케이션의 다른 부분으로 쉽게 확장할 수 있습니다. 컨텍스트 바인딩과 팩토리 패턴을 사용하는 경우
• 컨텍스트 바인딩: 특정 클래스(예: 다른 컨트롤러) 또는 알려진 컨텍스트를 기반으로 프로세서를 선택할 수 있는 경우에 이상적입니다. 컴파일 타임에 컨텍스트가 알려진 코드를 단순화합니다.
• 팩토리 패턴: 런타임 데이터(예: 사용자 입력, API 요청)를 기반으로 결제 프로세서를 동적으로 선택하려면 팩토리 패턴을 사용하세요. 이 접근 방식은 요청이 처리될 때까지 알 수 없는 데이터를 기반으로 런타임에 결제 프로세서를 선택하는 데 더 많은 유연성을 제공합니다.

다음 게시물에서는 런타임에 결제 프로세서를 동적으로 선택하여 복잡한 애플리케이션에 더 많은 유연성을 제공하는 팩토리 패턴을 살펴보겠습니다.

다음 부분에서는 Laravel 11에서 결제 처리를 위해 팩토리를 사용하는 방법을 다룰 예정입니다!