现在我想问一下我的理解是否正确，并在这里发布一些摘录，这些摘录对我有所帮助（尽管它们中的一些相互矛盾）。
无论如何，以下是我对此的理解（如果可能，请逐个回答每个问题）：
a) 当我们在框架级别应用DIP原则时，我们使用IoC这个术语？而在框架级别实现DIP的机制之一是DI？
b) 当我们在较低层/非框架级别实现DIP（使用DI）时，术语IoC不适用，此时我们简单地称其为DI？
c) DI通过将创建和选择依赖项的实际控制权传递给第三方来帮助我们实现DIP，该第三方对其他两个涉及方都是中立的？
d) 当在框架级别（IoC）应用DIP（使用DI）时，会颠倒三种类型的控件：
1. 接口的控制。现在高级模块控制着较低级别模块需要遵循的接口，而不是相反的。
2. 流程控制。现在框架代码（而不是用户/业务代码）控制程序的流程（换句话说，他们（即框架）调用你（即业务代码））。
3. 依赖项创建的控制。这种颠倒将实际创建和选择依赖项的控制权传递给一个对其他两个涉及方都是中立的第三方。
e) 当在非框架级别应用DIP（使用DI）时，会颠倒两种类型的控件：
1. 接口的控制。现在高级模块控制着较低级别模块需要遵循的接口，而不是相反的。
2. 依赖项创建的控制。这种颠倒将实际创建和选择依赖项的控制权传递给一个对其他两个涉及方都是中立的第三方。
控制依赖关系的创建。这种反转将实际创建和选择依赖关系的控制权交给了第三方，该第三方对另外两个参与方都是中立的。
?
以下摘录有所帮助:
控制反转是通用术语。依赖注入是IoC的一种特定类型
...
控制反转是指框架/基础设施调用应用程序代码，而不是相反的方式
...
可以在不进行IoC的情况下进行依赖注入。如果您将aConsoleStringWriter注入到HelloWorld中，我认为这并不是IoC，因为没有“框架”或“基础设施”。
如果您接受福勒的定义，那么控制反转比DI更广泛，它涵盖了所有使用框架的情况，您可以插入框架，但框架仍然处于控制状态。依赖注入是IoC的一种专业化，适用于特定地管理依赖关系。
IoC是变量实现契约的能力。DI是提供实现的能力。
...
在传统应用程序中，开发人员将编写业务代码和框架代码。然后，业务代码将调用框架代码来完成任务。在IoC模型下，你“反转”了这个模型，创建了一个接受业务模块并调用它们来完成任务的框架。
依赖注入是一种通过允许外部调用者向类/方法注入相关对象来从实现中删除内部依赖关系的技术（确实很难称之为模式）。IoC框架使用依赖注入来向“粘合一切”的框架例程提供用户模块和其他依赖代码。依赖注入在IoC框架中被广泛使用，因为它是允许它们“调用你”的机制。
DIP是引导我们朝着DI的原则。基本上，松耦合是目标，有至少两种方法可以实现它。 • 依赖注入 • 服务定位器
控制反转（其中依赖注入是一种实现方式）的本质在于将对象的使用与管理分离。
依赖注入（DI）和控制反转（IoC）这两个术语通常可以互换地描述相同的设计模式（虽然并不是每个人都同意这一点，有些人倾向于以稍微不同的方式应用它们）。这个模式最初被称为IoC，但Martin Fowler提出了从DI的角度看待，因为所有框架都以某种方式反转了控制，并且他想更具体地说明正在反转哪个控制方面。
控制反转（IoC）意味着对象不会创建它们依赖的其他对象来完成其工作。相反，它们从外部源获取所需的对象（例如，xml配置文件）。依赖注入（DI）意味着这是在没有对象干预的情况下完成的，通常是由框架组件通过传递构造函数参数和设置属性来完成。
谢谢
