Где правильно выполнить динамическую проверку, например, для выбора метода оплаты, используя laravel контракт и инъекцию зависимостей?

Question

[verygoodboy]

Изучая Laravel контракты, я нашел пример, где пользователь может выбрать метод оплаты.
В этом примере AppServiceProvider в методе register() выполняется проверка параметра в url, и в зависимости от параметра выполняется один либо другой метод:

class AppServiceProvider extends ServiceProvider
{
  public function register()
    {
        $this->app->singleton(PaymentContract::class, function ($app) {
           if (request()->has('credit')){
               return new CreditPayment();
           } else {
              return new BankPayment();
           }
        });
    }
}

Для примера, в учебных целях, такой проверки достаточно. Но есть ли еще варианты, где можно или было бы более правильно выполнять такую проверку? Возможно AppServiceProvider это не самое лучшее место для для таких проверок? Других примеров я не нашел.

Comments

[AgentSmith72]

В учебных целях это пустая трата времени)

Answer 1

[k2lhu]

Делать в реальном проекте так точно не рекомендуется.
То что вы приводите в виде примера - это размазывание бизнес логики между всеми слоями приложения.
Все что вам нужно, это какой-то класс PaymentFactory, который будет иметь метод make(string $credit), у которого аргумент $credit и будет принимать значения credit/bank/null и на основании переданного аргумента будет возвращать правильный объект класса обработчика конкретного метода оплаты. И уже этот PaymentFactory можете вызывать через DI.
Однако эту задачу можно решить через паттерн стратегия, тоже хорошо подойдет для удобной организации кода.

Comments

[verygoodboy]

Спасибо. Посмотрел паттерн стратегия. В принципе все понятно и для реализации такой задачи подходит. Хотя это уже более кастомный подход.

Answer 2

[Антон Антон]

Лучше всего делать это так, чтобы быстро найти хвосты когда будешь дорабатывать это дело через пол года. Ну и придерживаться этого подхода по всему проекту. В общем случае явное лучше неявного (что предполагает принятие решения в контроллере и явное создание объекта с нужным интерфейсом (ну или байндинг класса) в месте обработки запроса

Comments

[verygoodboy]

Спасибо