我目前即将开始一个新项目，我需要一点帮助来选择一个强大，经过高度测试的IoC容器，并且可能在可预见的未来出现。我一直在关注一些，特别是Spring .Net（v1.3.2），Castle Windsor和Ninject。我需要能够说服我们所有的开发人员，我最终选择的容器将是最符合我们需求的容器，具有活跃的追随者并且不会在未来几年内消亡
我必须提到我最初来自Java背景并且在Java中使用过Spring，而在我的选择中，它是Java中最好的IoC容器。因此，我自然而然地第一次被提到.Net中的Spring产品。我更倾向于选择Spring .Net（仅仅因为我们可以转移知识），但如果其他产品（Windsor，Ninject等）成为“更好”的解决方案，我愿意改变主意。然而，经过一些研究，在我看来，它在.Net世界中并不那么受欢迎（尽管看起来大多数这些观点都有点过时）。但是我已经深入研究了为什么它不那么受欢迎，在我看来，大多数人都有大量的XML配置和缺乏代码配置的问题，但大多数人并不认为Spring.Net在技术上较差（这表明它在技术上是一个非常好的IoC continer）。进一步挖掘表明，从Spring .Net 1.3.2开始，您可以使用Spring.NET CodeConfig（我首选的配置方法）完整地配置应用程序上下文，这提供了与XML配置相同的功能。因此，我们可以将XML配置作为一个问题来消除。
Castle Windsor似乎和Spring .net一样成熟，非常受欢迎。我做了很多研究，但我看不出它比Spring .Net提供的任何优势。如果有的话，Spring.Net提供的功能方面比Castle Windsor（我可能错了）更多，因为Spring .Net是一个框架，而不仅仅是一个IoC容器。 Spring .Net似乎比其他所有文档都要好得多（文档非常重要）
Ninject似乎是镇上的新男孩，每个人似乎都对它赞不绝口，然而，对我而言，这个月的味道并不足以成为挑选可能会使用多年的容器的理由。
所以我的问题是，为什么Spring .Net不像Castle Windsor那样受欢迎，因为我看不到这些优于Spring .Net的优势，更重要的是我为什么要在Spring .Net上选择任何其他容器
欢迎您提出所有意见，但是，诸如“Castle Windsor提供的功能X在Spring .Net中不提供或在Spring .net中复制并不容易”的技术原因将更受重视。
原因不应该包括Ioc容器的依赖注入的速度，因为这不是问题，而且坦率地说，如果有人担心它们的依赖注入器的速度，那么他们可能不应该使用IoC容器这些容器之间的速度是如此微不足道。
感谢大家花时间阅读本文。