依赖注入 (DI) vs. 控制反转 (IOC)
4.85/5 (70投票s)
依赖注入 (DI) vs. 控制反转 (IOC)。
控制反转和依赖注入的主要目标是移除应用程序的依赖。这使得系统更加解耦和可维护。
首先，让我们试着理解 IOC（控制反转）。如果你回到早期的计算机编程时代，程序流程通常在自己的控制下运行。例如，让我们考虑一个简单的聊天应用程序流程，如下图所示。
- 最终用户发送聊天消息。
- 应用程序等待来自另一端的消息。
- 如果没有找到消息，则转到步骤 2，否则转到步骤 4。
- 显示消息。
- 用户继续他的工作。
现在，如果您仔细分析程序流程，它是顺序的。程序自己控制。控制反转意味着程序将控制权委托给其他人来驱动流程。例如，如果我们使聊天应用程序基于事件，那么程序流程将如下所示：-
- 最终用户发送聊天消息。
- 用户继续他的工作。
- 应用程序监听事件。如果消息到达，则事件被激活，并且消息被接收和显示。
如果你看到程序流程，它不是顺序的，它是基于事件的。所以现在控制权被反转了。因此，不是内部程序控制流程，而是事件驱动程序流程。事件流方法更加灵活，因为没有直接调用，从而导致更大的灵活性。
这里要提醒一下，不要得出结论说 IOC 只能通过事件来实现。您可以通过回调委托、观察者模式、事件、DI（依赖注入）和许多其他方式委托控制流程。
IOC（控制反转）是一个通用的父术语，而 DI（依赖注入）是 IOC 的一个子集。IOC 是一个概念，其中应用程序的流程被反转。例如，而不是调用者调用该方法。
SomeObject.Call();
将被基于事件的方法替换，如下所示。
SomeObject.WhenEvent += Call();
在上面的代码中，调用者正在公开一个事件，当该事件发生时，他正在采取行动。它基于好莱坞原则“不要打电话给我们，我们会打电话给你”。在好莱坞，当艺术家们过去参加试镜时，评委会对他们说“不要打电话给我们，我们会打电话给你”。
上述方法使代码更加灵活，因为调用者不知道对象方法，并且对象不知道调用者程序流程。
DI 提供对象需要的对象。因此，依赖关系不是自己构造自己，而是通过某些外部手段注入它们。例如，假设我们有以下类“Customer”，它使用“Logger”类来记录错误。因此，您可以从类内部创建“Logger”，而不是通过构造函数注入它，如下面的代码片段所示。
通过上述方法实现的最大好处是“解耦”。现在，您可以调用客户对象并传递任何类型的“Logger”对象，如下面的代码所示。
Customer obj = new Customer(new EmailLogger());
Customer obj1 = new Customer(new EventViewerLogger());
因此，总结一下差异。
控制反转 :- 这是一个通用术语，并且以多种方式实现（事件、委托等）。
依赖注入 :- DI 是 IOC 的一个子类型，并且通过构造函数注入、setter 注入或方法注入来实现。
通过这篇博客，我想通知我所有的朋友，我已经开始了一个名为 在 youtube 上 60 天内学习 c# 和 .NET 的系列。所以，如果您有一些想要学习 c# 的新朋友，请谈论一下这个倡议。 http://www.youtube.com/watch?v=yh2SrzCkNQA
下面是一个很好的视频，演示了 IOC（控制反转）以及它与 DI（依赖注入）的不同之处
如需进一步阅读，请观看以下面试准备视频和分步视频系列。