我正在为 .net 寻找一个简单但实用且强大的 IOC/DI 框架答案

【问题标题】：I am looking for a simple yet practical and robust IOC/DI framework for .net我正在为 .net 寻找一个简单但实用且强大的 IOC/DI 框架
【发布时间】：2011-01-12 17:59:19
【问题描述】：

我将在经验较少的开发人员的项目中使用它，因此不能选择像 Spring.NET 这样的复杂框架。我在想：

忍者
温莎城堡
结构图

哪个会呈现出适中的学习曲线而不会失去灵活性？

还有另一个问题 - 放置配置的正确位置在哪里？由于 3 层 ASP.NET 应用程序上的内核/配置（不是 MVC ！！！所有示例都使用 MVC :)）

【问题讨论】：

它们都有学习曲线，但原理是可以转移的。我说选择一个，了解它是如何工作的，编写一个简单的测试应用程序来感受它。然后看看其他的，看看它们是否能缓解任何痛点。

标签： dependency-injection inversion-of-control castle-windsor structuremap ninject

【解决方案1】：

正确使用 DI 的好处在于，您可以将使用哪个 DI 容器的决定推迟到最后一个负责任的时刻。在应用程序架构术语中，这对应于所谓的 Composition Root，您可以在其中将所有依赖关系连接在一起。这是often the application's entry point。

除了 Composition Root 之外，整个应用程序都可以在完全不引用任何特定 DI Container 的情况下编写。你只需要follow well-known patterns and principles。

在选择 DI 容器时，我知道这些 .NET 的 DI 容器：

就我个人而言，到目前为止，我对温莎城堡很满意，但我还没有获得所有这些容器的丰富经验。

【讨论】：

这并不完全正确。各种容器提供不同的功能，并从不同的角度解决不同的问题。您可以利用您选择的容器的强大功能（如可启动性、事件连接、类型化工厂等），而无需引用它，而是通过以某种方式设计组件。您通常可以调整其他容器以与您的组件一起使用，但这意味着您需要编写一些额外的胶水代码来弥补其不足/差异。

【解决方案2】：

这是一个 ASP.NET（不是 MVC）Ninject 示例：

http://davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx

【讨论】：

【解决方案3】：

我使用过 ninject，发现它很容易让新开发人员跟上它的速度。

【讨论】：

【解决方案4】：

考虑从手工接线开始：参见http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion。它可以让经验不足的开发人员更好地了解 IOC/DI 的基础知识。

【讨论】：

【解决方案5】：

我认为您拒绝 spring.net 太仓促了。 Spring 提供了一个极其灵活的学习曲线，所以一开始它是一种“你可以从中获取你想要的东西”的方法。
您可以从最简单的 IoC 容器开始，然后再转向 aop、事务、单元测试或任何您想要的东西，因此复杂性会逐渐增加。

这是我最近两份工作中使用 Spring 的第一大卖点。其他要点是：

它不会强迫您使用它的 api 或改变您的架构。同样，这会引导您按照自己的节奏调整其功能。
非常广泛的文档。

当项目成熟时，你的开发人员也会成熟，所以 spring 最终会派上用场......（在我看来，一开始是免费的）

【讨论】：

【解决方案6】：

Autofac 是我选择的容器。它允许通过 lambda 表达式注册以获得最大的灵活性（链接有一些很好的例子）。

它还有一个与 Silverlight 兼容的版本。我不确定其他容器是否有。

至于放置，容器应该在应用程序启动时构建。对于 ASP.NET 应用程序，这将在 Global.Application_Start 方法中。

Autofac 有 ASP.NET integration，它使用您在启动期间构建的容器注入页面实例。

【讨论】：

温莎城堡有 Silverlight 3 版本

【解决方案7】：

看看http://funq.codeplex.com/ 首先，它与 Windsor 和其他基于反射的容器相比非常快，其次它非常灵活，但仍然具有非常易读的配置（如果您已经了解了应该使用的 Lamba 表达式采取任何方式）

【讨论】：

它提供了几乎没有开箱即用的功能。这是一个脚手架，您需要在其上手动编写整个接线。
我同意 Krzysztof 的观点：例如，Funq 不支持自动构造函数注入（自动装配），这使得即使是最简单的注册也变得麻烦和脆弱。在最简单的小改动之后，你最终会改变你的 DI 配置。
@Steven 是的，没有为您做任何事情（并且该项目现在处于休眠状态）但是我不同意脆弱的部分。它是类型安全的，据我所知，这是我写答案时唯一完成的。如果不需要能够更改配置运行时，我相信配置应该是类型安全的。我宁愿遇到编译错误而不是运行时错误（如果您没有使用自动装配或忘记定义所需的具体类，windsor 就会出现这种情况）
大多数容器都允许您注册代表，因此这不是 Funq 独有的功能。我知道你喜欢编译时检查：我也喜欢。然而，使用委托，创建可编译但在运行时失败的配置仍然与使用自动装配一样容易（您只需忘记注册单个依赖项）。正因为如此，我看不出缺乏自动布线是一种优势。更有用的是允许您在完成配置后验证容器的功能。例如，Simple Injector 包含一个 Verify() 方法，正是这样做的。

【解决方案8】：

我们使用managed extensibility framework。它是 .NET 4.0 框架（目前处于候选版本）的一部分，您可以在 System.ComponentModel.Composition 命名空间中找到它。 codeplex 站点目前仍然是最好的文档来源。

MEF 的关注点更多的是“可扩展性”而不是“依赖注入”，但它使用依赖注入来实现这一点。例如，Visual Studio 2010 代码编辑器使用 MEF 来实现可扩展性。

我们将它用作 DI 框架，尚未遇到任何问题（尽管我确实需要 dynamic instantiation 示例，它还不是核心的一部分）。

【讨论】：

【解决方案9】：

如果您还熟悉任何 DI 框架，我会选择 Simple Injector。

它有一个非常简单的 API，可以让您快速入门。虽然简单，但它仍然可以启用许多advanced configuration scenario's。该库在设计时考虑了迁移，这意味着切换到另一个框架将相当简单。为了证明这一点，有一个migration guide on the project's wiki。

【讨论】：

【解决方案10】：

除了 Ninject 这个很棒的产品之外，还有另外两个我熟悉的选项：

Microsoft's Unity。一些 Alt.NET 人认为它有点大而复杂。作为 Prism 的一部分，我已经使用它几个月了（使用 Unity 不需要 Prism。它可以独立使用），我发现它简单明了。
StructureMap。我发现 StructureMap 的学习曲线也非常平缓，而且学习速度很快。

希望这会有所帮助。

【讨论】：

【解决方案11】：

我发现 StructureMap 非常有用且易于使用。我用 Ninject 玩了一下，发现不太方便，但是 YMMV。我还建议您使用common service locator 作为您的 IOC 的实际实现和您的应用程序之间的中介。当您想稍后切换您的 IOC/DI 容器时，这不会那么痛苦。 StructureMap 和 Castle windsor 都有适配器。而且我认为通过谷歌搜索，根据blog，还有一个用于 Ninject 2 的适配器。

【讨论】：

与容器无关与 CommonServiceLocator 关系不大。如果您以依赖注入风格编写代码，则无需引用您的容器或 CommonServiceLocator。
见commonservicelocator.codeplex.com/…stackoverflow.com/questions/735712/…