当前位置：文江博客话题详情

dependency-injection inversion-of-control

DI 容器如何工作的最简单解释？

发布于 2024-09-06 11:54:33 字数 38 浏览 5 评论 0原文

简单来说和/或在高级伪代码中，DI 容器如何工作以及如何使用？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

白馒头 2024-09-13 11:54:33

DI 容器的核心是根据接口和具体类型之间的映射创建对象。

这将允许您从容器请求抽象类型：

IFoo f = container.Resolve<IFoo>();

这要求您之前配置容器以从 IFoo 映射到实现 IFoo 的具体类（例如 Foo）。

这本身并不会特别令人印象深刻，但 DI 容器做得更多：

它们使用自动接线，这意味着它们可以自动确定 IFoo 是否映射到 Foo，IBar 映射到 Bar，但 Foo 有对 IBar 的依赖，当您请求 IFoo 时，它将创建一个带有 Bar 的 Foo 实例。
他们管理组件的生命周期。您可能每次都需要一个新的 Foo 实例，但在其他情况下您可能需要相同的实例。您甚至可能每次都需要 Foo 的新实例，但注入的 Bar 应保持相同的实例。

一旦您开始尝试手动管理组合和生命周期，您应该开始欣赏 DI 容器提供的服务:)

许多 DI 容器可以做的远不止上述，但是那些是核心服务。大多数容器都提供通过代码或 XML 进行配置的选项< /a>.

当谈到容器的正确使用时，Krzysztof Kozmic 刚刚发布了很好的概述。

At its core a DI Container creates objects based on mappings between interfaces and concrete types.

This will allow you to request an abstract type from the container:

IFoo f = container.Resolve<IFoo>();

This requires that you have previously configured the container to map from IFoo to a concrete class that implements IFoo (for example Foo).

This in itself would not be particularly impressive, but DI Containers do more:

They use Auto-Wiring which means that they can automatically figure out that if IFoo maps to Foo and IBar maps to Bar, but Foo has a dependency on IBar, it will create a Foo instance with a Bar when you request IFoo.
They manage the lifetime of components. You many want a new instance of Foo every time, but in other cases you might want the same instance. You may even want new instances of Foo every time, but the injected Bar should remain the same instance.

Once you start trying to manually manage composition and lifetimes you should start appreciating the services provided by a DI Container :)

Many DI Containers can do much more than the above, but those are the core services. Most containers offer options for configuring via either code or XML.

When it comes to proper usage of containers, Krzysztof Kozmic just published a good overview.

回复收藏 0 原文

长伴 2024-09-13 11:54:33

“这只不过是一个花哨的哈希值
对象表。”

虽然上面的说法是一种轻描淡写的说法，但这是考虑它们的简单方法。给定集合，如果您请求类的相同实例 - DI 容器将决定是否为您提供一个它们

的使用使连接依赖项变得更加容易和清晰。

class House(Kitchen, Bedroom)
     // Use kitchen and bedroom.
end

class Kitchen()
    // Code...
end

class Bedroom()
   // Code...
end

想象一下，在没有 DI 容器的情况下构建房屋是一件痛苦的事情，一个卧室的实例，然后是一个厨房的实例，如果这些对象也有依赖关系，那么您需要将它们连接起来，然后您才能创建一个对象。使用 DI/IOC（控制反转）容器，您说您想要一个房屋对象，DI 容器将递归创建其每个依赖项并返回一个房屋。

没有 DI/IOC 容器：

house = new House(new Kitchen(), new Bedroom());

使用 DI/IOC 容器：

house = // some method of getting the house

最终，它们使代码更易于理解、更易于编写，并将将对象连接在一起的责任从手头的问题转移开。

"It's nothing more than a fancy hash
table of objects."

While the above is a massive understatement that's the easy way of thinking about them. Given the collection, if you ask for the same instance of an class - the DI container will decide whether to give you a cached version or a new one, or so on.

Their usage makes it easier and cleaner when it comes to wiring up dependencies. Imagine you have the following pseudo classes.

class House(Kitchen, Bedroom)
     // Use kitchen and bedroom.
end

class Kitchen()
    // Code...
end

class Bedroom()
   // Code...
end

Constructing a house is a pain without a DI container, you would need to create an instance of a bedroom, followed by an instance of a kitchen. If those objects had dependencies too, you would need to wire them up. In turn, you can spend many lines of code just wiring up objects. Only then could you create a valid house. Using a DI/IOC (Inversion of Control) container you say you want a house object, the DI container will recursively create each of its dependencies and return you a house.

Without DI/IOC Container:

house = new House(new Kitchen(), new Bedroom());

With DI/IOC Container:

house = // some method of getting the house

At the end of the day they make code easy to follow, easier to write and shift the responsibility of wiring objects together away from the problem at hand.

回复收藏 0 原文