惰性依赖注册与团结

Question

注1：我想清楚：我不是试图延迟加载依赖或注入懒惰类型。

大多数（所有？）IoC容器需要元数据与容器来描述如何当被问及某种类型应该可以解决注册;这包括接口的实现，对象的生命周期等等。在过去几年中，基于流利/惯例的API已经添加到大多数（所有）IoC容器中，这在提供这种容器时减少了很多噪音元数据到容器。

随着ninject，我使用基础的方法来注册我的元数据的惯例，但是我做它的需求，而不是前期。在创建〜10个对象的集成测试场景中，这会节省巨大的性能;您将失去必须在每次测试中注册整个应用程序依赖项的开销。

注2：请不要告诉我，你不应该在集成测试使用IoC容器。

有一定的压力移动到使用Microsoft组件时可用，所以团结就是在我的视野。我有基于约定的注册工作，但我无法弄清楚如何在Ninject中按需要/懒洋洋地“发现”这些元数据。

我第一次尝试实现这个是围绕UnityContainer实例使用一个包装器，并且在包装器上调用GetInstance（type）时，我可以查询容器以查看该类型是否已注册。如果没有，我可以调用我的约定，发现元数据并注册类型。然而，这种方法只能深入一层。如果该类型注入更多的依赖关系，则每个依赖关系都不会反馈回GetInstance（type）方法，从而成为我的困境。

问题：我怎样才能懒洋洋地/点播型注册添加到Unity？

来源将是很好的，但一个指向容器中的钩会一样好。我尝试了继承，但没有什么可以像Ninject一样重写。

Answer 1

首先 - Unity的每个问题都可以，而且应该通过避免使用它来解决。

如果这不是一种选择，我认为Unity没有选择按需注册东西。

作为一个旁注，我仍然不会默认尝试注册懒惰的东西。一个容器产生不可接受的性能这一事实并不意味着另一个容器会出现这种情况。你有没有先测量一下？

我在测试中使用容器（温莎）很多，我从来没有发现预先注册是一个问题。更重要的是，（我知道那些测试是如此不同的规则适用）我认为不预先注册的东西是错误的。即使允许，我也知道大多数容器仍然针对前期注册进行了大量优化，因此您的性能增益可能为零，甚至您可能发现自己看到的数字比通过正确的方式进行前期注册更差。

Answer 2

现在，Unity 3支持递延解析。请参阅http://msdn.microsoft.com/en-us/library/dn178463(v=pandp.30).aspx#sec33。