IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：

在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(

DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。

最终，你总会赢：）

控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）

当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。

假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。

尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。

具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。

依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。

这是怎么一回事？反转（耦合）控制，更改方法签名的耦合方向。对于反向控制，方法签名的定义由方法实现（而不是方法的调用方）决定。此处完整解释

它解决了哪个问题？方法上的自顶向下耦合。这随后消除了重构的需要。

什么时候使用合适，什么时候不合适？对于定义良好的小型应用程序，如果没有太大的变化，可能会产生开销。然而，对于将要发展的定义较少的应用程序，它减少了方法签名的固有耦合。这使开发人员可以更自由地开发应用程序，避免了对代码进行昂贵的重构。基本上，允许应用程序在很少返工的情况下发展。

我将写下我对这两个术语的简单理解：

For quick understanding just read examples*

依赖注入（DI）：依赖注入通常意味着将方法依赖的对象作为参数传递给方法，而不是让方法创建依赖对象。这在实践中意味着，该方法不直接依赖于特定的实现；任何满足要求的实现都可以作为参数传递。使用此对象可以告诉它们的依赖关系。春天使它成为可能。这导致了松散耦合的应用程序开发。

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

控制反转（IoC）容器：这是框架的共同特征，IOC通过其BeanFactory管理java对象——从实例化到销毁-由IoC容器实例化的Java组件称为bean，IoC容器管理bean的范围、生命周期事件以及为其配置和编码的任何AOP特性。

快速示例：控制反转是指获得自由、更大的灵活性和更少的依赖性。当你使用台式电脑时，你是从属的（或者说，受控的）。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个糟糕的书面软件会让你更加痛苦。如果你用笔记本电脑取代了你的桌面，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是电脑控制它。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

作为设计指南的控制反转具有以下目的：

某个任务的执行与实现是分离的。每个模块都可以专注于它的设计目的。模块不假设其他系统做什么，而是依赖它们的合同。替换模块对其他模块没有任何副作用，我将在这里保持抽象，您可以访问以下链接以详细了解主题。一个很好的例子

详细说明

我在使用库或框架的上下文中想到了控制反转。

传统的“控制”方式是我们构建一个控制器类（通常是主类，但也可以是任何类型的），导入一个库，然后使用您的控制器类来“控制”软件组件的操作。就像你的第一个C/Python程序（继HelloWorld之后）。

import pandas as pd
df = new DataFrame()
# Now do things with the dataframe.

在这种情况下，我们需要知道Dataframe是什么才能使用它。您需要知道要使用什么方法，它的取值方式等等。如果您通过多态性将它添加到自己的类中，或者只是重新调用它，那么您的类将需要Dataframe库才能正常工作。

“控制反转”意味着过程反转。您可以注册类并将其发送回要控制的引擎，而不是您的类控制库、框架或引擎的元素。换句话说，IoC可能意味着我们正在使用代码来配置框架。您也可以将其视为类似于我们在map或filter中使用函数来处理列表中的数据的方式，只是将其应用于整个应用程序。

如果您是构建引擎的人，那么您可能正在使用依赖注入方法（如上所述）来实现这一点。如果你是一个使用引擎的人（更常见），那么你应该能够只声明类，添加适当的符号，让框架为你完成剩下的工作（例如创建路由、分配servlet、设置事件、输出小部件等）。

在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。