Рационально ли внедрять зависимости в класс через DI-контейнер, обходя при этом стороной конструктор и сеттеры?
В целом это считается плохой практикой. Приведу ссылку на соответствующий кусок из документации DI контейнера в Symfony: https://symfony.com/doc/current/components/depende...
Доставая зависимости непосредственно из контейнера вы лишаете себя массы преимуществ внедрения зависимостей:Страдает тестируемость класса т.к. вы не можете подменить сервисы на нужные вам во время тестовВы лишаете себя возможности валидации целостности графа зависимостей в случае если используется компилируемый контейнер (как, например, в Symfony)Вы привносите в класс излишнюю информацию о названиях конкретных сервисов которые вы достаёте из контейнераВам потребуется дополнительно проверять есть ли каждый из сервисов в контейнере и что же именно вы достали из контейнера (через instanceof)
Уверен что есть и другие факторы, это то что пришло на ум в первую очередь.
Нет, не так. Суть DI в управлении зависимостями, когда я смотрю конструктор - я должен видеть от чего зависит код. Ваш вариант практически не отличается от использования глобальных переменных/сервис локатора.
Все современные контейнеры позволяют забиндить интерфейс с реализацией, плюс автовайринг. Для вас, как программиста, даже проще сразу инжектить нужные вам классы, чем просить их у контейнера.
Принцип инверсии зависимостей (англ. dependency inversion principle, DIP):
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Ваш вариант абсолютно противоречит этому принципу, потому что все ваши классы внезапно начинают зависеть от контейнера, тогда как бизнес логика и даже уровень приложения вообще не должны знать о его существовании.