我正在寻找一个简单但实用且强大的 .net IOC/DI 框架
我将在一个由经验较少的开发人员组成的项目中使用它，因此像 Spring.NET 这样的复杂框架不是一个选择。我在想：
- Ninject
- Castle Windsor
- StructureMap
哪个会呈现适度的学习曲线而不失去灵活性？
另一个问题 - 放置配置的正确位置在哪里？由于 3 层 ASP.NET 应用程序上的内核/配置（不是 MVC！！！所有示例都使用 MVC :)）
I am going to use it in a project with less-experienced developers so a complex framework such as Spring.NET is not an option. I was thinking about:
- Ninject
- Castle Windsor
- StructureMap
Which would present a moderate learning curve without losing flexibility?
and another question - where is the correct place to put the configuration? Since the kernel/configuration on a 3-tier ASP.NET application (not MVC!!! all examples are using MVC :) )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
正确使用 DI 的好处在于，您可以将有关使用哪个 DI 容器的决定推迟到最后负责的时刻。在应用程序架构术语中，这对应于所谓的组合根，您可以在其中将所有依赖关系连接在一起。这通常是应用程序的入口点。
除了组合根之外，整个应用程序都可以在不引用任何特定 DI 容器的情况下编写。您只需要遵循众所周知的模式和原则。
在选择 DI 容器时，我知道这些 .NET 的 DI 容器：
就个人而言，到目前为止，我对温莎城堡很满意，但我尚未获得使用所有这些容器的丰富经验。
The great thing about proper use of DI is that you can defer the decision about which DI Container to use until the last responsible moment. In application architecture terms, this corresponds to a so-called Composition Root, which is where you wire all depedendencies together. This is often the application's entry point.
Apart from the Composition Root, the entire application can be written without referencing any particular DI Container at all. You just need to follow well-known patterns and principles.
When it comes to pick a DI Container, I'm aware of these DI Containers for .NET:
Personally, I have been happy with Castle Windsor so far, but I have yet to gain extensive experience with all of these containers.
下面是一个 ASP.NET（不是 MVC）Ninject 示例：
http: //davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx
Here's an ASP.NET (not MVC) Ninject sample:
http://davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx
我使用过 ninject，发现让新开发人员跟上它的速度很容易。
I have used ninject and found it easy to bring new developers up to speed with it.
考虑从手动接线开始：请参阅 http://blog .objectmentor.com/articles/2010/01/17/dependency-injection-inversion。它使经验较少的开发人员能够更好地了解 IOC/DI 的基础知识。
Consider to start with wiring by hand: see http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion . It gives less-experienced developers a better insight in the basics of IOC/DI.
我认为你拒绝 spring.net 太仓促了。 Spring 提供了极其灵活的学习曲线，因此一开始它是一种“你从中获取你想要的”方法。
您可以从最简单的 IoC 容器开始，然后转向 aop、事务、单元测试或您想要的任何内容，因此复杂性逐渐增加。
这是我最近两份工作中使用 Spring 的第一大卖点。其他要点是：
当项目成熟时，你的开发人员也会成熟，所以 spring 最终会派上用场......（在我看来，一开始是免费的）
I think you are being too hasty to reject spring.net. Spring offers an extremely flexible learning curve, so at the beginning it's kind of "you take what you want from it" approach.
You can start with the simplest-of-all IoC container, and later on move to aop, transactions, unit testing, or whatever you desire, so the complexity builds up gradually.
This was the #1 selling point at my last two jobs for using Spring. Additional points were:
When the project matures, so will your developers, so spring will come out handy at the end ... (at no cost in the beginning, in my opinion)
Autofac 是我选择的容器。它允许通过 lambda 表达式进行注册，以实现最大的灵活性（该链接有一些很好的示例）。
它还具有 Silverlight 兼容版本。我不确定其他容器是否也是如此。
至于放置，容器应该在应用程序启动时构建。对于 ASP.NET 应用程序，这将位于 Global.Application_Start 方法中。
Autofac 具有 ASP.NET 集成，它使用您在构建过程中构建的容器注入页面实例启动。
Autofac is my container of choice. It allows registration via lambda expressions for maximum flexibility (the link has some nice examples).
It also has a Silverlight-compatible version. I'm unsure if the other containers do.
As for placement, the container should be built during application startup. For an ASP.NET application, this would be in the Global.Application_Start method.
Autofac has ASP.NET integration which injects pages instances using the container you build during startup.
首先看看 http://funq.codeplex.com/与 Windsor 和其他基于反射的容器相比，速度非常快 其次，它非常灵活，但仍然具有非常可读的配置（如果您已经了解了 Lamba 表达式，那么无论如何这都需要很长时间）
Have a look at http://funq.codeplex.com/ first of all it's extremely fast compared to windsor and other reflection based containers second of all it's very flexible but still has a very readable configuration (If you've gotten your head around Lamba expressions which should take to long any ways)
我们使用托管扩展性框架。它是 .NET 4.0 框架的一部分（当前处于候选版本中），您可以在 System.ComponentModel.Composition 命名空间。 Codeplex 站点目前仍然是最好的文档来源。
MEF的重点更多地是“可扩展性”而不是“依赖注入”，但它使用依赖注入来实现这一点。例如，Visual Studio 2010 代码编辑器使用 MEF 来实现可扩展性。
我们将它用作 DI 框架，尚未遇到任何问题（尽管我确实需要 动态实例化示例，尚未成为核心的一部分）。
We use the managed extensibility framework. It is part of the .NET 4.0 framework (currently in release candidate), where you can find it in the System.ComponentModel.Composition namespace. The codeplex site is currently still the best source of documentation.
The focus of MEF is more on "extensibility" rather than "dependency injection", but it uses dependency injection to achieve this. For example, the visual studio 2010 code editor uses MEF to enable extensibility.
We use it as a DI framework and have not yet run into any problems (though I did need the dynamic instantiation sample which is not part of the core yet).
如果您还熟悉任何 DI 框架，我会选择 简单注入器。
它有一个非常简单的 API，可以帮助您快速入门。虽然简单，但它仍然支持许多高级配置方案。该库的设计考虑到了迁移，这意味着切换到另一个框架将相当简单。为了证明这一点，在项目的 wiki 上有一个迁移指南。
If you're yet familiar with any DI framework, I'd go with the Simple Injector.
It has a very simple API, that will get you started very quickly. Although simple, it still enables many advanced configuration scenario's. The library designed with migration in mind, which means that switching to another framework would is rather straightforward. To prove this point, there is an migration guide on the project's wiki.
除了 Ninject（这是一个很棒的产品）之外，还有我熟悉的其他两个选项：
希望这有帮助。
In addition to Ninject, which is a great product, there are also two other options that I'm familiar with:
Hope this helps.
我发现 StructureMap 使用起来非常有用且直观。我玩了一下 Ninject，发现不太方便，但是 YMMV。我还建议您使用 通用服务定位器 作为 IOC 实际实现和您的 IOC 实际实现之间的中介。应用。当您稍后想要切换 IOC/DI 容器时，这不会那么痛苦。有 StructureMap 和 Castle Windsor 的适配器。我认为通过谷歌搜索，还有一个 Ninject 2 的适配器，根据这个
I find StructureMap very usefull and intuitive to use. I played with Ninject a bit and found that less convenient, but YMMV. I would also recommend you use the common service locator as an intermediary between the actual implementation of your IOC and your application. When you want to switch your IOC/DI container later on, this is less painfull. There are adapters for StructureMap and Castle windsor. And I think from googling that there also is an adapter for Ninject 2 according to this blog.