dependency-injection - Unity(等)实际上如何帮助依赖注入(inject)

Question

我有一些关于 DI 容器(尤其是 Unity)的问题，以及它们实际上如何帮助 DI。

我相信我了解 IoC/DI 并且多年来一直在使用基于构造函数的 DI。通常我使用 DI 它只涉及在我的类上有一个构造函数，比如 MyClassX，它接受一个接口(interface)作为参数，比如 IDataService，然后使用 new 运算符创建一个 IDataService 实现类的实例，并将它传递给 MyClassX 的构造函数。这样 MyClassX 就不需要知道它正在使用的 IDataService 的确切类型，将它与特定类型解耦。如果我错了，请纠正我，但这就是我对 DI 的理解......尽管它不一定是基于构造函数的。

现在我在网上看到了一堆 Unity 的例子，但我发现很难理解它所做的一切(对我来说它就像一个神奇的对象工厂)，而且很难理解它是如何帮助 DI 的我明白了。对我来说，Unity 更像是工厂实现(或 Mock 框架？)，而不是专门与 DI 相关的任何事情。我想我真的错过了一些东西，正在等待“啊哈”的时刻。我已经做了很多谷歌搜索，但例子没有帮助......我需要一个理论解释。

谁能向我解释一下 Unity 的确切用途...它的主要用途以及它与我所理解的 DI 的关系。

Answer 1

您对基本依赖注入(inject)的理解是正确的。构造函数注入(inject)是最常见的模式。

其他一些 DI Unity 可以:

1. 生命周期管理 – 实例创建可以是单例的，每个实例一个线程和其他高级模型。
2. 处理依赖关系图 - 请求一个根对象，Unity 创建它的所有依赖关系依赖项。
3. 启用方法和属性注入(inject) – 需要业务代码中的 Unity 属性(我更愿意避免)
4. 服务定位器模式 – 通常被认为是 anti-pattern

1 和 2 在您需要时非常有用。我认为应尽可能避免 #3 和 #4，因为它会将代码中的依赖项添加到 Unity 容器中。

您缺少的大爆炸是 Aspect Oriented Programing 由 Interception with Unity 启用.这允许实现横切关注点。日志记录是一个典型的例子。如果您想要更多，请开始阅读所有 Enterprise Library Call Handlers用于异常处理、验证等，或者只是开始在 Web 上搜索 AOP。

当您将依赖项的构造函数注入(inject)与横切关注点的外部实现相结合时，您可以非常接近仅包含业务逻辑的业务对象。在大型企业开发团队中，这是一个非常大的突破。