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

结构图、Ninject、Castle Windsor、Unity、Autopac和其他软件有什么区别？有人能提供一些提示或链接到可能有助于选择一个库的资源吗？

更新：有一个问题(企业库统一与其他IOC容器)讨论IOC容器初始化的差异。

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

不同的IOC容器之间有一点不同，那就是它的生命周期或实例化模式是开箱即用的(何时创建组件的新实例)：

• 结构图
  • 瞬态(按请求调用)、单实例、线程本地、每个httpcontext、每个httpsession、混合
• 九针
  • 瞬态、单例、每个线程、每个httpRequest
• 温莎城堡
  • 单实例、瞬态、每个线程、池、每个httpRequest(通过设施提供的附加功能)
• AutoFac
  • 瞬态(工厂)，单件，按HTTPRequest
• 团结
  • 每个线程的瞬时、单例

这是一篇很有帮助的博客文章，它比较了.NET中各种IOC框架的功能，但我不知道MVC有什么比另一个更倾向于一个容器的功能。

马克斯

我个人决定用自动空调。有一件事似乎很好，那就是对资源的确定性处理。

当我签出它时，它也与ASP.NET集成在一起。我应该看一下其他框架，但我没有对它产生任何问题。当有一个不可解析的组件时，它给您的错误消息是非常好的。

你最好的选择是尝试每个项目。我非常喜欢在代码中进行配置(尽可能多)，并使用XML配置作为备份。所以，列出你自己的优先顺序，然后试试看。

就个人而言，OOP不再是正确的解决方案，因为它不能很好地处理IOC。找到自己的解决方案可能会更好。就我个人而言，只要我能控制两端，我就用f来滚我自己的。

新的RX可能对这些问题有所帮助，但它仍然只是从功能编程中借用了一个创可贴。

不过，我想我们有一段时间一直将对象作为一些事情的基本模型——幸运的是，在Web服务对象中，这些对象的工作非常糟糕，以至于标准已经从它们转向了功能接口(如SOAP)。