@magary4

Получаются тяжелые конструкторы с большим количеством инжекшен параметров?

public function __construct(
        Request $request,
        $router,
        Storage $storage,
        $user,
        Session $session,
        TranslatorInterface $translator,
        DocumentRepository $documentRepository,
        \Swift_Mailer $mailer,
        EngineInterface $templating,
        $checkout_email,
        WishlistOrderManager $wishlistOrderManager
    )
    {
        $this->request = $request;
        $this->router = $router;
        $this->storage = $storage;
        $this->user = $user;
        $this->session = $session;
        $this->translator = $translator;
        $this->documentRepository = $documentRepository;
        $this->mailer = $mailer;
        $this->templating = $templating;
        $this->checkout_email = $checkout_email;
        $this->wishlistOrderManager = $wishlistOrderManager;
    }


так и хочется инжектить контейнер и оттуда доставать все после ижекшена

читал что так не делают чтоб не зависеть от контейнера и в будушем можно было поменять фрейворк
но вот при таком количестве зависимостей я вижу что не так-то легко поменять этот фреймворк и сам не верю что это когда-то случится
так ли действительно нужно быть независимым от контейнера?
  • Вопрос задан
  • 331 просмотр
Пригласить эксперта
Ответы на вопрос 3
@oxidmod
Скорей всего ваш класс и швец и жнец и на дуде дудец, тобишь нарушает принцип единсвенной отвественности.

Скорей всего его можно распилить на основное действие и набор листенеров для разнообразных событий. Судя по зависимости от мейлера вам явно нужно отправлять письма. Идеальный кандидат на вынос в ивент листенер (а в будущем будет гораздо проще отправлять письма асинхронно через менеджер очередей).

Зы. без всего кода класса трудно сказать чтото определнное, но класс с зависимостью от роутера, реквеста, мейлера и менеджера заказов выглядит весьма странно, потому что роутер и реквест это уровень контроллера, мейлер, темплейтинг, транлятор - это некие вспомогательные сервисы, а менеджер заказов попахивает бизнесс-логикой. А у вас в этом классе вообще стерты границы межу уровнями. Советую почитать про layered architecture
Ответ написан
skobkin
@skobkin
Гентушник, разработчик на PHP и Symfony.
Дело не только в независимости от контейнера, а в очевидности наличия зависимостей. И в минимизации ответственности класса. Зачем ему знать о существовании чего-то, что ему не нужно?
Ответ написан
banderos120
@banderos120
Играю на балалайке
так ли действительно нужно быть независимым от контейнера?

Да. SOLID.

так ли действительно нужно быть независимым от контейнера?

Нет, если это необходимо, и обусловлено спецификой задачи, контейнер - это тот же класс.

По сути, если конструктор большой - это ничего страшного, в принципе, если все по делу, но это и первый сигнал о проблемах в архитектуре.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
26 янв. 2021, в 11:53
1234 руб./за проект
26 янв. 2021, в 11:48
5000 руб./за проект
26 янв. 2021, в 11:39
60000 руб./за проект