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

时间:2009-08-12 17:29:56

标签: .net dependency-injection inversion-of-control

  

另见Which C#/.NET Dependency Injection frameworks are worth looking into?

现在有很多dependency injection个框架可供选择。由于您使用的库,您以前经常被迫使用给定的依赖注入框架。但是Common Service Locator library使库代码独立于注入框架。

学习所有这些课程所需的时间足以决定使用哪一个是不合理的。我不相信我们已经达到了可以讨论最佳依赖注入框架的阶段。那么我应该问什么问题关于项目和我自己来帮助决定在特定情况下使用的最佳依赖注入框架?

了解为什么选择目前正在使用的依赖注入框架以及您是否仍然对此选择感到满意也很有用。

在比较依赖注入框架的样式时是否还有一个有用的词汇表?

服务定位器库是否在现实生活中工作,或者你是否被迫在同一个项目中使用了许多不同的依赖注入框架?

使用每个依赖注入框架对代码进行折射是多么容易,例如ReSharper等工具是否适用于给定的框架?

4 个答案:

答案 0 :(得分:15)

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

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

一些问题:

  1. 您需要多少主流支持?春天可能是最大的支持。现在每个人都使用它或听说过它,所以很多信息。它也可能具有最多的功能,但这意味着需要学习更多功能。像Autofac这样的小容器可能不错,但是你可能会遇到一个你无法找到帮助的问题。
  2. 您是否熟悉XML配置?每个IoC容器都依赖于某种配置和设置。 Spring和Unity是XML重的。
  3. 这是一个永久的选择吗?如果您在其中一个只有一次选择的地方,那就无所谓了。但是,如果你想在未来选择其他解决方案,你可能不希望IoC要求你归类你的类(与上述问题相反),因为当你不得不撕掉所有的时候你会讨厌自己那东西。相比之下,包装一些XML配置可能并不那么痛苦。
  4. 您的商店是什么样的?我只是因为“喘气!这不是微软!”而无法推销几个开源选项。反应。如果你是一个直接的MS商店,使用Unity将是一个更容易的文化胜利。
  5. 个人说明:

    我使用StructureMap的原因与我链接的博客中提到的原因相同。我认为XML配置很难维护,特别是调试(参见WCF)。我还没有尝试过Ninject,但根据他们的营销,它一定是超级棒!

答案 1 :(得分:6)

很难回答哪个框架是“最好的”,但我可以告诉你哪个框架最简单:简单的注射器:

  

Simple Injector是一个易于使用的Inversion of Control库   .NET和Silverlight。它仅支持基于代码的配置和   对于不熟悉较大IoC /的开发人员来说是一个理想的起点   DI库

http://simpleinjector.codeplex.com/

无耻的插头顺便说一句; - )

答案 2 :(得分:2)

我认为选择取决于找到一个符合您要求然后个人偏好的框架。

您的项目是否已经使用了已经与DI框架集成的rhino-tools等库?如果确实如此,如果你想避免使用“许多不同的依赖注入框架”,这可能是一个很好的起点。

查看这两篇文章:

答案 3 :(得分:2)

  

Spring和Unity是Xml重的。

我不同意Unity的声明;你可以写

container.RegisterType<IRobot, MrRoboto>();

使用流畅的界面在代码中进行设置。我个人喜欢Unity。