IoC容器之间的差异

Question

我正在寻找一些有关如何为 ASP.NET MVC 应用程序选择 IoC 容器的指南。

（例如）StructureMap、Ninject、Castle Windsor、Unity、autofac 等之间有什么区别？任何人都可以提供一些可能有助于选择一个图书馆的提示或资源链接吗？

更新:有一个问题（企业库 Unity 与其他 IoC 容器）其中讨论了 IoC 容器初始化的差异。

但是功能上是否存在任何差异，这会使某些 IoC 容器成为 ASP.NET MVC 应用程序的更好选择？

Answer 1

这是一个有用的博客文章比较.Net中可用的各种IOC框架之间的功能，我不知道有什么关于MVC有利于一个容器而不是另一个容器。

最高

Answer 2

各种 IoC 容器之间的不同之处在于开箱即用的生命周期或实例化模式（何时创建组件的新实例）：

• 结构图
  • 瞬态（称为每个请求）、单例、线程本地、每个 HttpContext、每个 HttpSession、混合
• 忍者
  • 瞬态、单例、每线程、每 HttpRequest
• 温莎城堡
  • 单例、瞬态、每线程、池化、每 HttpRequest（通过设施提供其他可用）
• 自动法
  • 瞬态（工厂）、单例、每个 HttpRequest
• 统一
  • 瞬态、单例、每线程

Answer 3

我个人已经确定了Autofac。似乎非常好的一件事是资源的确定性处置。

当我检查出来时，它与ASP.Net集成了它。我应该看一下其他框架，但我没有遇到过问题。当存在无法解析的组件时，它给出的错误消息非常好。

您最好的选择是尝试与他们每个人的项目。我已成为在代码中进行配置（尽可能多）并使用XML配置作为备份的真正粉丝。因此，请制定自己的优先级列表并试用它们。

Answer 4

就个人而言 - 这就是OOP不再是正确解决方案的地方，因为它不能很好地处理IoC。找到自己的解决方案可能会更好。我个人用F＃自己动手 - 只要我能控制两端。

新的Rx可能会帮助解决其中的一些问题，但它仍然只是借用功能编程中的一个乐队。

我想我们暂时将对象作为某些事物的基本模型 - 幸运的是，Web服务对象的工作非常糟糕，以至于标准已经从它们转向SOAP等功能接口。