Инверсия управления и внедрение зависимостей с выбранными кавычками — правильно ли я понимаю?

Я прочитал ряд тем, объясняющих разницу между IoC и DI , и хотя многие из объяснений противоречили друг другу, я думаю, что они все же помогли мне понять разницу.

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

Я знаю, что на эту тему было создано много тем, но я надеюсь, что эта тема не будет закрыта, поскольку я не думаю, что какая-либо из ОП в упомянутых темах также показала все соответствующие сообщения (из различных тем ), что помогло им, наконец, понять это.

В любом случае, вот как я это понимаю (, если возможно, обращайтесь/ответьте на каждый вопрос отдельно):

a )Когда мы применяем принцип DIP на уровне структуры , мы используем термин IoC ? И одним из механизмов реализации DIP на уровне инфраструктуры является DI ?

b )Термин IoC не применяется, когда мы реализуем DIP(используя DI)на более низком уровне/не -уровне структуры , и в этом случае мы просто называем это DI ?

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

d )При применении DIP (с помощью DI)на уровне фреймворка(IoC ),тогда три типа управления инвертируются:

1. Управление интерфейсом. Теперь модуль высокого уровня управляет интерфейсом, которого должны придерживаться модули более низкого уровня, а не наоборот

2. Контроль потока.--> Теперь код фреймворка(вместо код пользователя/бизнеса)управляет потоком программы (, другими словами-они (т.е. фреймворк )называют вас (т.е. бизнес-код))

3. Контроль создания зависимостей . Эта инверсия передает контроль над фактическим созданием и выбором зависимостей третьей стороне, которая нейтральна по отношению к любой из двух других вовлеченных сторон.

e )При применении DIP (с помощью DI)на не -уровне фреймворка , два типа управления инвертируются:

1. Управление интерфейсом. Теперь модуль высокого уровня управляет интерфейсом, которого должны придерживаться модули более низкого уровня, а не наоборот

2. Контроль создания зависимостей . Эта инверсия передает контроль над фактическим созданием и выбором зависимостей третьей стороне, которая нейтральна по отношению к любой из двух других вовлеченных сторон.

?

Вот выдержки, которые помогли:

Зачем так много терминов, чтобы сказать одно и то же? IoC и DIP

Inversion of Control is the generic term. Dependency Injection is a specific type of IoC

...

Inversion of Control is when the framework/infrastructure invokes application code, rather than the other way around

...

can do DI without doing IoC. If you inject aConsoleStringWriter into a HelloWorld I don't really think of this as IoC because there is no "framework" or "infrastructure".

Инверсия управления

If you accept Fowler's definition, Inversion of Control is a much broader term than DI that covers allframework usage where you plug into a framework, but the framework is still in control. Dependency Injection is a specialization of IoC that applies IoC specifically to manage dependencies.

В чем именно разница между IoC и DI

IoC is the ability to vary the implementation of a contract. DI is the ability to supply the implementation.

...

In traditional applications, developers would write business code and framework code. The business code would then call the framework code to accomplish tasks. Under an IoC model, you "invert" that model and create a framework that accepts business modules and calls them to accomplish tasks

Dependency Injection is a technique (hard to call it a pattern, really) of removing internal dependencies from implementations by allowing dependent objects to be injected into the class/method by an external caller. IoC frameworks use dependency injection to supply user modules and other dependent code to framework routines that "glue it all together." Dependency injection is used heavily by IoC frameworks because that is the mechanism that allows them to "Call You."

DIP, DI, IoC

DIP is the principle that guides us towards DI. Basically, loose coupling is the goal, and there are at least two ways to achieve it. • Dependency Injection • Service Locator

У кого-нибудь есть хорошая аналогия для внедрения зависимостей?

The essence of Inversion of Control (of which Dependency Injection is an implementation) is the separation of the use of an object from the management thereof.

Разница между ioc и внедрением зависимостей

The terms Dependency Injection (DI) & Inversion of Control (IoC) are generally used interchangeably to describe the same design pattern (although not everyone agrees on that point, and some people tend to apply them in slightly different ways). The pattern was originally called IoC, but Martin Fowler proposed the shift to DI because all frameworks invert control in some way and he wanted to be more specific about which aspect of control was being inverted.

Инверсия управления против внедрения зависимостей

Inversion of Control (IoC) means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside source (for example, an xml configuration file). Dependency Injection (DI) means that this is done without the object intervention, usually by a framework component that passes constructor parameters and set properties.

спасибо