注意1：我想说清楚：我不是在尝试延迟加载依赖项或注入延迟类型。
大多数（全部？）IoC容器需要在容器中注册元数据，以描述在询问时应如何解析某些类型;这包括接口的实现，对象的生命周期等。在过去几年中，基于流畅/约定的API已被添加到大多数（所有？）IoC容器中，这在提供此功能时减少了大量噪音元数据到容器。
使用ninject，我使用基于约定的方法来注册我的元数据，但我是按需提供，而不是预先。这样可以在集成测试场景中节省大量性能，您可以在其中创建~10个对象;您将失去每次测试都必须注册整个应用程序依赖项的开销。
注意2：请不要告诉我您不应在集成测试中使用IoC容器。
在可用时转向使用Microsoft组件会有一些压力，因此Unity正在我的视野中。我有基于约定的注册工作，但我无法弄清楚如何在Ninject中按需/懒惰地“发现”这个元数据。
我第一次尝试实现这个是在UnityContainer实例周围使用包装器，并在包装器上调用GetInstance（type）后，我可以查询容器以查看该类型是否已注册。如果没有，我可以调用我的约定，发现元数据，并注册类型。然而，这种方法只有一个层次;如果该类型注入了更多依赖项，则每个依赖项都不会被反馈到GetInstance（type）方法中，从而导致我的困境。
问题：我如何懒洋洋/按需添加类型注册到Unity？
Source会很好，但指向容器中钩子的指针也一样好。我尝试了继承，但没有像Ninject那样覆盖。
答案 0 :(得分：5)
首先 - Unity的每个问题都可以，并且应该通过避免使用它来解决。
如果那不是一个选项，我认为Unity中没有选择按需注册内容。
作为旁注，我仍然不会默认试图懒洋洋地注册东西。它使用一个容器产生不可接受的性能这一事实并不意味着另一个容器会出现这种情况。你先测量过吗？
我在测试中使用了容器（Windsor），我从未发现前期注册成为问题。更重要的是，（我知道那些是测试，所以不同的规则适用）我认为不预先注册的东西是错误的。我知道的大多数容器即使允许这样做，仍然会针对前期注册进行大量优化，因此您的性能提升可能为零，甚至您可能会发现自己看到的数字比以正确方式进行并预先注册更糟糕。