IoC容器之间的差异

时间:2009-10-28 20:12:51

标签: .net ioc-container

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

(例如)StructureMap,Ninject,Castle Windsor,Unity,autofac和其他人之间有什么区别?任何人都可以提供一些提示或链接到可能有助于选择一个库的资源吗?

更新:有一个问题(Enterprise Library Unity vs Other IoC Containers)讨论了IoC容器初始化的差异。

但是功能上是否有任何差异,这会使一些IoC容器成为ASP.NET MVC应用程序的更好选择?

4 个答案:

答案 0 :(得分:6)

各种IoC容器之间的一个不同之处是生命周期或实例化模式,这些模式支持开箱即用(何时创建组件的新实例):

  • StructureMap
    • transient(称为per-request),singleton,thread-local,per-HttpContext,per-HttpSession,Hybrid
  • Ninject
    • transient,singleton,per-thread,per-HttpRequest
  • 温莎城堡
    • 单身,瞬态,每线程,汇集,每次HttpRequest(可通过设施获得)
  • autofac
    • transient(factory),singleton,per-HttpRequest
  • 统一
    • transient,singleton,per-thread

答案 1 :(得分:5)

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

最高

答案 2 :(得分:1)

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

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

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

答案 3 :(得分:-1)

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

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

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