Unity（等）如何实际帮助依赖注入

Question

我对DI容器（特别是Unity）以及它们实际上如何帮助DI有一些疑问。

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

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

根据我的理解，有人可以向我解释Unity的确切含义......它的作用以及它与DI的相关性。

Answer 1

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

其他一些DI Unity确实：

1. 终身管理 - 实例创建可以是单例，每个一个 线程等高级模型。
2. 处理依赖关系图 - 请求根对象，Unity创建其所有依赖关系 的依赖关系。
3. 启用方法和属性注入 - 需要a 您的业​​务代码中的Unity属性（我更愿意避免）
4. 服务定位器模式 - 通常被视为anti-pattern
当你需要时，

1和2很好。我认为尽可能避免使用＃3和＃4，因为它会将代码中的依赖项添加到Unity容器中。

您遗失的大爆炸是Aspect Oriented Programing 由Interception with Unity启用。这允许实施横切关注点。记录是典型的例子。如果您想要更多，请开始阅读所有Enterprise Library Call Handlers以进行异常处理，验证等，或者只是开始在网上搜索AOP。

当您将依赖关系的构造函数注入与交叉关注问题的外部实现相结合时，您可以非常接近仅包含业务逻辑的业务对象。在一个大型企业开发团队中，这是一个非常大的爆炸。

Answer 2

当对象图很简单时，您可能看不到使用DI容器的明显优势。

假设您有一个MyClassX类，它依赖于IExampleA，IExampleB。现在IExampleA和IExampleB的实现可能依赖于其他一些类等。现在，当涉及物化/实例化时，这种对象图很难手动处理。

这就是DI发挥作用的地方。一旦注册（类及其依赖类），您需要做的就是，

 var myclassX = _container.Resolve<MyClassX>()

而且，不要误解我的意思，DI可以提供的不仅仅是解决依赖性问题。例如，管理对象的LifeStyle和LifeCycle等。