在为.NET选择依赖注入框架时，我应该考虑什么


What should I consider when choosing a dependency injection framework for .NET

see also Which C#/.NET Dependency
Injection frameworks are worth looking
into?

现在有许多依赖注入框架可供选择。由于所使用的库，您常常被迫使用给定的依赖项注入框架。然而，公共服务定位器库使库代码独立于注入框架。

要学好所有的知识来决定使用哪一种是不合理的。我不相信我们已经到了可以讨论最佳依赖注入框架的阶段。那么，为了帮助决定在给定的情况下使用的最佳依赖注入框架，我应该问关于项目和我自己的哪些问题呢？

了解您为什么选择当前正在使用的依赖注入框架，以及您是否仍然满意这一选择，这也是很有用的。

在比较依赖注入框架的样式时，是否有一个有用的词汇表需要使用？

服务定位器库是在现实生活中工作的，还是您的技能被迫在同一个项目中使用许多不同的依赖注入框架？

使用每个依赖项注入框架重构代码有多容易，例如，像resharper这样的工具在给定的框架中是否工作良好？

仅供参考，就在今天早上，我在这里看到了所有.NET IOC容器之间的有趣比较：

http://elegantcode.com/2009/01/07/ioc-libraries-比较/

几个问题：

  • 您需要多少主流支持？春天可能是世界上最大的一个。到目前为止，每个人都使用过或听说过它，所以有很多信息。它也可能拥有最多的特性，但这意味着还有更多的东西需要学习。像autofac这样的小容器也许不错，但你可能会遇到一个你找不到帮助的问题。
  • 使用XML配置方便吗？每个IOC容器都依赖于某种类型的配置和设置。Spring和Unity是XML重的。
  • 这是一个永久的选择吗？如果你在一个只有一次机会选择的地方，那就不重要了。但是，如果你想选择另一个解决方案，你可能不想让一个国际奥委会要求你将你的课程(与上述问题相反)归为属性，因为当你不得不把所有的东西都撕掉的时候，你会恨自己。相比之下，包装一些XML配置可能没有那么痛苦。
  • 你的商店怎么样？仅仅因为"喘息"，我无法提供几个开源选项。不是微软！"反应。如果你是一个直的微软商店，使用统一将是一个更容易的文化胜利。

    • 以个人名义：

    我使用结构图的原因与我链接的博客中提到的相同。我认为XML配置对于维护，特别是调试来说是一个巨大的痛苦(参见wcf)。我还没试过Ninject，但根据他们的市场营销，肯定是超级Rad！

    相关讨论

    很难回答哪个框架是"最好的"，但我可以告诉您哪个框架是最容易的：简单的注入器：

    The Simple Injector is an easy-to-use Inversion of Control library for
    .NET and Silverlight. It solely supports code-based configuration and
    is an ideal starting point for developers unfamiliar with larger IoC /
    DI libraries

    http://simpleinjector.codeplex.com/

    无耻的插头btw；-)

    Spring and Unity are Xml heavy.

    我不同意统一的说法，你可以写

    1
    container.RegisterType<IRobot, MrRoboto>();

    并使用一个流畅的风格界面在代码中进行设置。我个人喜欢团结。

    我认为选择归根结底是找到一个满足您需求的框架，然后是个人偏好。

    您的项目是否已经使用了一个库，比如已经与DI框架集成的Rhino工具？如果是这样，如果您希望避免使用"许多不同的依赖注入框架"，那么这可能是一个很好的起点。

    查看这两个帖子：

    • 企业图书馆统一与其他IOC容器
    • 那么：您使用哪个.NET依赖注入框架？