Во многих статьях по всему миру термины «Инверсия управления» и «Принцип инверсии зависимостей», похоже, перепутаны и используются как синонимы (дальнейшая путаница обеспечивается инструментами, которые называются «DI-контейнеры» и «IoC-контейнеры»). Статья в Википедии делает хорошую работу, пытаясь объяснить, что IoC - это не то же самое, что DI:
Инверсия управления (IoC) описывает схему, в которой пользовательские части компьютерной программы получают поток управления из универсальной, многократно используемой библиотеки.
Таким образом, DIP означает, что ваши модули зависят от абстракций, а не от конкретных реализаций.
И IoC - это управление потоком программ для отдельного модуля. И одна из вещей, которую вы можете сделать этим модулем, это разрешить зависимости во время выполнения.
Это различие кажется справедливым, но я никогда не видел, чтобы кто-либо упоминал о других применениях принципа IoC, кроме разрешения зависимостей. Определение Википедии довольно широкое, и кажется, что вы могли бы сделать гораздо больше с модулем, который может делать вызовы в ваш пользовательский код на основе его конфигурации и некоторой внутренней логики.
Итак, вот некоторые вопросы, которые я пока не могу понять:
- Какова реальная связь между IoC и DIP? Всегда ли IoC служит средством реализации DIP?
- Почему инструменты для разрешения зависимостей называются DI- и IoC-контейнерами? Это означает, что DI и IoC - это одно и то же.
Примечание . Этот вопрос не является дубликатом раздела «В чем разница между DI и IoC» , поскольку последний задает вопрос о внедрении зависимости, а не об инверсии зависимости.
источник
Ответы:
На сайте Мартина Фаулера есть отличная статья, в которой есть глава, посвященная разнице между DIP, DI и IoC . Суть этого (как скопировано с этого сайта)
источник
ISomeInterface object = container.Resolve<ISomeInterface>()
это IoC или нет?