Как IoC Container реализует внедрение зависимостей по сравнению с тем, как я это реализовывал

Question

Чтобы выполнить Dependency Injection, я мог бы создать универсальный словарь для различных типов соединений БД, а затем динамически создать экземпляр одного типа с помощью отражения перед передачей его в конструктор объекта, который в этом нуждается.

Какую разницу и пользу это приносит при использовании контейнера IOC, поскольку он не делает мои вещи более независимыми, чем первое решение. Как Контейнер МОК будет делать изнутри? Отличается ли это от первого решения?

Как бы вы реализовали DI без контейнера? Когда вы переключитесь на контейнер IoC?

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

Answer 1

Полагаю, контейнер делает для вас много кода котельной плиты. Например, он делает именно то, что вы сказали, создавая экземпляр класса на основе отраженного поведения. Многие контейнеры также позволяют вам явно настраивать вашу систему на основе файлов конфигурации.

IOC или DI - только понятия. Концепции IOC / DI дают вам «независимость», которую вы поддерживаете. Фактическая реализация может варьироваться. Вы можете сделать это без использования стороннего контейнера или написать свой собственный. Или вы можете использовать функции, предоставляемые хорошо протестированным сторонним контейнером.

Если вы просто хотите внедрить разные типы соединений БД, у вас очень маленькая потребность в IOC / DI. В общем, IOC / DI (будьте осторожны, а не контейнер, который является просто реализацией IOC / DI) предоставляет вам полностью конфигурируемое программное обеспечение, средства для модульного тестирования (путем введения заглушек), самостоятельной настройки и т. Д.

Обычно IOC / DI необходимы, когда:

1. Ваше программное обеспечение настолько велико и сложно, что ни у одного человека нет всего этого в голове, или
2. имеет так много разных конфигураций, что вам не нужны индивидуальные сборки, или
3. настолько взаимосвязан между частями, что вам трудно испытать каждую деталь в отдельности

Answer 2

Внедрение зависимостей не имеет ничего общего со словарями. Как объясняет Николас Блюмхардт в отличном сообщении в блоге, вам нужна совершенно другая ментальная модель для DI .

DI является слабой связью благодаря применению Конструкторской инъекции и Composition Root шаблонов проектирования. Когда DI-контейнер входит в изображение, он делает это с помощью шаблона Register Resolve Release .

Так что, если класс требует соединения с БД, он запрашивает его через конструктор.

Answer 3

Ничто не говорит о том, что вам нужно использовать контейнер IoC, просто контейнеры IoC предварительно собраны, и вам не нужно писать код самостоятельно.Это означает, что вы можете сконцентрироваться на создании своего приложения, а не собственной системы DI.

Это похоже на создание пользовательского интерфейса или использование стороннего элемента управления.Обе работы, это просто зависит от того, где вы хотите провести время.Я знаю, что мне не особо важно создавать собственную DI-систему, поэтому я бы предпочел использовать предварительно созданную.

Вы можете также спросить, зачем вообще использовать фреймворк, если вы можете писать напрямуюк API ОС.Это все о повышении надежности (путем повторного использования кода, который кто-то другой уже написал и потратил много времени, чтобы убедиться, что он не содержит ошибок) и повышения вашей производительности (без необходимости писать все самостоятельно).

РЕДАКТИРОВАТЬ:

Существует множество способов реализации DI.Вы всегда можете посмотреть на все контейнеры, которые там есть, и как они работают.Все они с открытым исходным кодом, и исходный код доступен.