Unity（等）实际上如何帮助依赖注入
我对 DI 容器（尤其是 Unity）以及它们如何实际帮助 DI 有一些疑问。
我相信我了解 IoC/DI 并且多年来一直使用基于构造函数的 DI。通常，在使用 DI 时，只需要在类上有一个构造函数（例如 MyClassX），它采用接口作为参数（例如 IDataService），然后使用 new 运算符创建 IDataService 实现类的实例并将其传递到 MyClassX 的构造函数中。这样，MyClassX 不需要知道它正在使用的 IDataService 的确切类型，将其与特定类型解耦。如果我错了，请纠正我，但这就是我对 DI 的理解……尽管它不一定是基于构造函数的。
现在我在网上看到了一堆 Unity 的示例，但我发现不仅很难理解它所做的一切（对我来说，它似乎是一个神奇的对象工厂），而且很难理解它如何在我所理解的 DI 中提供帮助。对我来说，Unity 看起来更像是一个工厂实现（或一个模拟框架？），而不是专门与 DI 相关的任何东西。我想我真的错过了一些东西，正在等待“啊哈”的时刻。我已经做了很多谷歌搜索，但例子没有帮助......我需要一个理论解释。
有人可以向我解释一下 Unity 的具体用途吗……它的主要用途以及我所理解的它与 DI 的关系。
I have some questions about DI containers (Unity in particular) and how they actually aid in DI.
I believe I understand IoC/DI and have been using constructor based DI for some years. Usually with my use of DI it involved simply having a constructor on my class, say MyClassX that takes an interface as an argument say IDataService and then using the new operator to create an instance of an IDataService implementing class and pass it into MyClassX's constructor. This way MyClassX doesn't need to know the exact type of the IDataService it is using decoupling it from a specific type. Now correct me if I am wrong, but that's what I understand DI to be...though it does not have to be constructor based.
Now I have seen a stack of examples of Unity on the net, but I am finding it difficult to not only understand everything it does (it seems like a magic object factory to me) but also how it exactly aids in DI as I understand it. To me Unity seems more like a Factory implementation (or a Mock framework?) rather than anything to do specifically with DI. I think I have really missed something though and am waiting for an "ah ha" moment. I have done alot of Googling but examples don't help... I need an theoretical explanation.
Can someone explain to me what Unity is exactly for...the broad points of what it does and how it is related to DI as I understand it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您对基本依赖注入的理解是正确的。构造函数注入是最常见的模式。
其他一些 DI Unity 的做法：
线程和其他高级模型。
依赖关系。
业务代码中的 Unity 属性（我倾向于避免）
1和2在您需要时非常有用。我认为#3 和#4 应尽可能避免，因为它将代码中的依赖项添加到 Unity 容器中。
您错过的大爆炸已启用面向方面的编程通过 拦截统一。这允许实施横切关注点。日志记录就是一个典型的例子。如果您需要更多信息，请开始阅读所有企业库调用处理程序 进行异常处理、验证等，或者直接开始在 Web 上搜索 AOP。
当您将依赖项的构造函数注入与横切关注点的外部实现结合起来时，您可以非常接近仅包含业务逻辑的业务对象。在大型企业开发团队中，这是一个非常大的爆炸。
Your understanding of basic Dependency Injection is correct. Constructor injection is the most common pattern.
Some other DI Unity does:
thread, and other advanced models.
dependencies.
Unity attribute in your business code (which I prefer to avoid)
1 and 2 are nice when you need them. I think #3 and #4 are to be avoided when possible because it adds dependencies in your code to your Unity container.
The big bang that you are missing is Aspect Oriented Programing enabled by Interception with Unity. This allows the implementation of cross cutting concerns. Logging is the classic example. If you want more, start reading all the Enterprise Library Call Handlers for exception handling, validation, etc. or just start searching the web for AOP.
When you combine constructor injection of dependencies with external implementation of cross cutting concerns, you can get very close to business objects that only contain business logic. In a large Enterprise development team, that’s a very big bang.
当对象图很简单时，您可能看不到使用 DI 容器的明显优势。
假设您有一个 MyClassX 类，它依赖于 IExampleA、IExampleB。现在IExampleA和IExampleB的实现可能依赖于其他一些类等等。现在，这种对象图在物化/实例化时手动处理起来很复杂。
这就是 DI 发挥作用的地方。一旦注册（类及其依赖的类），您需要做的就是，
并且，不要误会我的意思，DI 可以提供的不仅仅是解决依赖关系。例如管理对象的生活方式和生命周期等。
When the object graph is simple you may not see the obvious advantages of using a DI container.
Say you have a class MyClassX which depends on IExampleA, IExampleB. Now the Implementation of IExampleA and IExampleB may depend on some other classes and so on. Now, this kind of object graph is complex to handle manually when it comes to materialized/instantiate it.
This is where DI comes into play. Once registered(class and its depended classes), All you need to do is,
And, don't get me wrong here, DI can provide much more than just resolving dependency. For example managing the LifeStyle and LifeCycle of objects etc.