logo标签列表

如何选择一个 DI 容器？

asp.net-mvc-3dependency-injection
8

可能重复：
主要的C# DI/IoC框架有什么区别？

由于存在如此多的DI容器，我感到有些迷茫。 我是DI模式的新手。

我正在阅读.NET中的依赖注入一书，发现DI在改进代码库、使其松耦合和更易于测试方面非常有用。

现在，我想为我的虚拟项目引入一个DI容器，但是选择太多了。

我该如何在Castle Windsor、Unity、StructureMap、Spring.NET、Autofac、Ninject、Funq、LinFu等之间进行选择？

我猜一个连贯的方法是“只需选择一个”并开始使用它（因为我认为它们在早期阶段特别容易互换），但我希望做出更明智的决定。

无论你做什么，都不要选择Funq，因为它不支持自动构造函数注入，这基本上使它在任何真实项目中都不能使用，或者实际上使它不符合作为真正的DI容器的资格。 - Steven
6个回答
5
这就像买车一样。你可能喜欢丰田，但它只有2.5升的发动机。你可能喜欢法拉利，但它太红了。你可能喜欢马自达，但你的老板不允许你开。你可能喜欢悍马，但你的同事会嘲笑你。将制造商混合到你的品味中，总会有某些东西对别人或在不同的时刻来说是缺失的。
我的经验是-首先，依赖注入通常比没有依赖注入更好。选择任何一个都会让你受益匪浅。我会选择以下内容：
  • 在社区中得到很好的支持（这样您就可以得到答案）
  • 有一个良好的支持公司（这样你就不需要在它倒闭时重写你的代码）
  • 让你感觉舒适（这样你不会在孩子面前骂人，不酷）
  • 项目不会过度庞大
  • 不仅仅是依赖注入，还提供了一个生态系统，可以减少您花费在您知道自己可以做但现在不能做的任务上的时间-然后您可以专注于重要的事情
  • 被很多人使用（这样你就知道很多部件也在现实生活中测试并填充错误）
  • 不是5年前（例如文档上说它支持Windows 98之类的）
    • 我个人认为-http://www.springframework.net/。我的意思是，他们的文档目录页面长达20页...
    或者你可能只想看看一些类似问题的答案：
  • 哪些.NET依赖注入框架值得关注？
    • 2
    您可以从MVC3中的内置DependencyResolver开始。稍后，您可以轻松升级到Enterprise Library Unity DI。
    Brad Wilson在如何在MVC3中使用DI上提到了一系列文章。
    0

    我的立场是，看几本书 - 你已经有了优秀的 ".NET 中的依赖注入" 书（在这个列表中我会添加 Ninject，不幸的是它没有在这本书中涵盖） - 然后选择一个你最理解并且喜欢语法的书。开始使用高级功能并不是非常重要，关键是开始。

    一旦你有了一个 IoC 容器，替换它应该基本上是微不足道的，因为所有的更改都将在一个地方 - 聚合根 - 而不是散布在你的代码库中。使用 IoC 容器还将强制你设计依赖注入，如果你还没有的话，那将对你的项目产生更大的影响。

    0

    我一直在使用Ninject和Unity。当你将Unity MVC添加到Unity中时，代码让我想起了Ninject的代码。

    两者都非常容易实现。两者都允许替换以配置文件为中心的方式，转而采用启动器类为中心的方式。

    我建议创建一个2小时的项目，并在每个IOC DI框架中实现它，通过经验决定哪个更适合您。但是，如果您在不查看其他功能的情况下执行此操作，则可能会发现您错过了某些内容。因此，请查看外围功能，例如第三方支持。

    0
    除了其他很棒的评论之外 - 如果您安装了Unity.MVC3包，请注意，如果您想要在每个请求中处理您的对象，则必须使用HierarchicalLifetimeManager。它非常好用，但我认为在大多数情况下，所有主要的都非常好用。
    对于您来说，问题是找到适合您环境的那一个。有些地方允许开源，有些则不允许，在这种情况下，Unity胜出。
    -5

    最发达的.NET DI容器是托管可扩展框架（MEF），我强烈建议使用它。MEF快速、易用且易于团队维护，具有完美的学习曲线。

    6
    ".NET中最发达的DI容器是MEF"这个说法绝对不是真实的。 - BrokenGlass
    3
    MEF 不是一个 DI 容器。MEF 在基础实现的基础上提供即插即用的配置。（正如其名称所示，它是一个可扩展性框架而不是 DI）。 - Manas
    4
    MEF根本不是一个依赖注入容器。 - Sebastian Weber
    Sebastian，你刚听到MEF不是DI容器的流言。我说：它就是，而且你也无法反驳。它比一堆过度设计的前辈以更高效的方式完成工作。让我们逐个来看：1）MEF是容器 2）MEF注入依赖项。1 + 2 = DI容器，至少如此。话不多说。 - ogggre
    3
    即使是MEF的开发人员也不声称它是一个容器，而是一个插件机制。如果你喜欢用属性等方式来污染你的代码，你可能会滥用它作为容器。你也可以用锤子在墙上钻洞。 - Sebastian Weber
    显示剩余4条评论
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接