Правильно ли я делаю, что все кроме работы с БД выношу в отдельные классы и потом внедряю как DI?

Question

[Flasher]

Правильно ли я делаю, что все кроме работы с БД выношу в отдельные классы и потом внедряю как DI? Например: загрузка картинок, обработка графики и тд. Если не правильно, то что надо выносить в отдельные классы и потом использовать, как Внедрение Зависимостей. Спасибо.

Comments

[zorca]

"Вообще лучше понимать, что делаешь. Если не понимаешь, то лучше не делать." © zorca
Программа будет работать в любом случае, а зависимости нужны в контейнере, если они многократно применяются в различных местах аппки. В отдельные классы выносится все что имеет свою собственную область применения.

[Flasher]

Тоесть, если код будет неоднократно использоваться в разных контроллерах. Например загрузка картинки, то в таком случае выносить лучше в отдельный класс, чтобы не было дублирования. Верно?

[Alex Maximovich]

В широком смысле класс описывает одну сущность и методы для работы с ней. Тут зависит от подхода.

[Flasher]

Alex Maximovich, а когда по вашему требуется использование классов для DI? Я просто тогда не понимаю, что дилигировать?

[Alex Maximovich]

Flasher, Надо понимать что такое DI и зачем это нужно. В основном его используют для уменьшения связанности между компонентами/модулями проекта. Прочитайте, может это немного прояснит ситуацию https://habrahabr.ru/post/166287/

[myxasa]

Назначение провайдера это централизованно подключить и инициализировать необходимые компоненты приложения (через bind, share, singleton — не важно), а так же выполнить иные глобальные (в рамках приложения) задачи.

Answer 1

[eRKa]

Все эти DI, IoC придумали для слабой связанности. Т.е. их использование оправдано, если Вы хотите разорвать сильную зависимость между какими-то модулями или объектами, т.к. в будущем ожидаете изменений или хотите добавить возможность тестирования какого-то участка кода.

Если Вам не принципиально ни то, ни другое, то не стоит доводить до фанатизма)

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

Comments

[Flasher]

Ага, что-то начинает проясняться.

Answer 2

[Сергей]

Это Вам надо читать про чистую архитектуру.
Можно подходить из таких соображения класс который легко тестируется уже сделан правильно.
Что нужно тестировать в классе? Только логику которую мы написали. Строго говоря на вход мы подаем объекты заглушки и тестируем только свою логику.
Этот подход сочитается с принципом единственной ответственности, те класс выполняет только свои дела.
Применяя DI правильно, у Вас получится такое разделение: компоненты - независимые переиспользуемые части и сборщики - те кто собирают компоненты в нужную систему и конфигурацию.
Вы получите ясность и переиспользуемость. Плюс гибкость.