我将在一个经验不足的开发人员的项目中使用它，因此不能选择Spring.NET这样的复杂框架。我在考虑：
哪会出现适度的学习曲线而又不失灵活性？
和另一个问题 - 放置配置的正确位置在哪里？由于3层ASP.NET应用程序上的内核/配置（不是MVC !!!所有示例都使用MVC :)）
答案 0 :(得分：4)
正确使用DI的好处在于，您可以推迟决定使用哪个DI容器直到最后一个负责任的时刻。在应用程序体系结构术语中，这对应于所谓的组合根，您可以将所有依赖项连接在一起。这是often the application's entry point。
除了Composition Root之外，整个应用程序可以在不引用任何特定DI容器的情况下编写。您只需要follow well-known patterns and principles。
当谈到选择DI容器时，我知道这些用于.NET的DI容器：
就个人而言，到目前为止，我对Castle Windsor很满意，但我还没有获得所有这些容器的丰富经验。
答案 1 :(得分：2)
这是一个ASP.NET（非MVC）Ninject示例：
答案 2 :(得分：0)
我使用过ninject，发现很容易让新开发人员加快速度。
答案 3 :(得分：0)
考虑从手工接线开始：见http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion。它为经验不足的开发人员提供了更好的IOC / DI基础知识。
答案 4 :(得分：0)
我认为你太急于拒绝spring.net。 Spring提供了非常灵活的学习曲线，因此在开始时它就是“你从中得到你想要的东西”的方法 你可以从最简单的IoC容器开始，然后转向aop，事务，单元测试或任何你想要的东西，这样复杂性就会逐渐增加。
这是我上一次使用Spring工作的第一个卖点。补充要点是：
当项目成熟时，你的开发人员也会成熟，所以春天最终将会派上用场......（在我看来，开头免费）
答案 5 :(得分：0)
除了Ninject，这是一个很棒的产品，还有其他两个我熟悉的选项：
希望这有帮助。
答案 6 :(得分：0)
Autofac是我的首选容器。它允许通过lambda表达式进行注册以获得最大的灵活性（链接有一些很好的例子）。
它还具有Silverlight兼容版本。我不确定其他容器是否可以。
对于放置，应在应用程序启动期间构建容器。对于ASP.NET应用程序，这将在Global.Application_Start方法中。
Autofac有ASP.NET integration，它使用您在启动期间构建的容器注入页面实例。
答案 7 :(得分：0)
首先看看http://funq.codeplex.com/与windsor和其他基于反射的容器相比，它的速度非常快第二，它非常灵活，但仍具有非常可读的配置（如果你已经掌握了Lamba表达式）这应该采取任何方式）
答案 8 :(得分：0)
我们使用managed extensibility framework。它是.NET 4.0框架的一部分（目前处于候选版本中），您可以在System.ComponentModel.Composition命名空间中找到它。 codeplex网站目前仍然是文档的最佳来源。
MEF的重点更多地放在“可扩展性”而不是“依赖注入”上，但它使用依赖注入来实现这一点。例如，visual studio 2010代码编辑器使用MEF来实现可扩展性。
我们将它用作DI框架并且还没有遇到任何问题（尽管我确实需要dynamic instantiation样本，但它还不是核心的一部分）。
答案 9 :(得分：0)
如果你还熟悉任何DI框架，我会选择Simple Injector。
它有一个非常简单的API，可以让您快速入门。虽然简单，但它仍然可以启用许多advanced configuration scenario's。该库设计时考虑了迁移，这意味着切换到另一个框架会相当简单。为证明这一点，有一个migration guide on the project's wiki。
答案 10 :(得分：-2)
我发现StructureMap非常有用且直观易用。我和Ninject玩了一下，发现不太方便，但是YMMV。我还建议您使用common service locator作为IOC实际实施与您的应用程序之间的中介。如果您想稍后切换IOC / DI容器，那就不那么痛苦了。 StructureMap和Castle windsor有适配器。我想通过谷歌搜索，根据这个blog，Ninject 2还有一个适配器。