问题描述
首先，我是软件界的新手。所以我很抱歉，如果这是一个简单或错误的问题。
我一直在阅读有关DI和IOC的信息，我知道DI是实现IOC的一种方式（还有其他方式）。所以让我一直想，DI总是会导致控制反转吗？是否取决于您如何调用可从DI中受益的方法或类？换句话说，您的申请流程将决定DI是否会导致IOC，对吗？
解决方法
我认为Dependency Injection Principles,Practices,and Patterns（DIPP＆P）的这句话引述起来很概括：
依赖注入或控制反转？
控制反转一词最初是指overall framework or runtime controlled the program flow形式的任何编程风格。根据该定义，在.NET Framework上开发的大多数软件都使用IoC。举例来说，当您编写ASP.NET Core MVC应用程序时，会创建带有操作方法的控制器类，但它的ASP.NET Core会调用您的操作方法。这意味着您不受控制-框架受控制。
如今，我们已经习惯了使用框架，因此我们认为这并不特殊，但是与完全控制您的代码不同，它是一种不同的模型。对于.NET应用程序，这仍然可能发生，尤其是对于命令行可执行文件。一旦Main被调用，您的代码就处于完全控制状态。它控制程序流程，生命周期-一切。没有引发特殊事件，也没有调用重写的成员。
在DI得名之前，人们开始将管理依赖项的库称为“控制容器的反转”，不久，IoC的含义逐渐向该特定含义漂移：对依赖项的控制反转。始终是分类学家，马丁·福勒（Martin Fowler）引入了术语“依赖注入”以在依赖管理的上下文中专门指IoC。此后，依赖注入已被广泛接受为最正确的术语。简而言之，IoC是一个更广泛的术语，包括但不限于DI。
[来源：第1.4.1节，第29页。Online version]
此引用是在.NET的上下文中编写的，但是如果您过滤掉.NET和ASP.NET，则它的适用范围很广。在Martin Fowler最初的定义中，IoC是关于框架的，而DI本身可以在没有任何框架的情况下应用，例如使用“简单”（无UI）控制台应用程序。这意味着，按照Fowler的原始定义，可以在不应用IoC的情况下实践DI。
多年来，IoC这个术语已经“漂移”了，我们现在通常将DI视为IoC的专门形式。可以说是“子类型”或“实现”，其中IoC是概念或“抽象”。这意味着没有IoC就无法应用DI，因为练习DI意味着练习IoC。但是，您可以练习IoC，而无需练习DI，因为还有其他IoC实现，例如Service Locator。
利益冲突：我是DIPP＆P的作者之一，尽管本节来自Dependency Injection in .NET，这是DIPP＆P的第一版。我没有参与第一版的撰写。