关于依赖项注入：IoC容器配置/注册

我绝对需要使用IoC容器来解耦日益复杂的企业服务系统中的依赖关系。我面临的问题是与配置(也称为注册)相关的问题。我们目前有4种不同的环境-从开发到生产，以及介于两者之间。这些环境具有许多配置，这些配置因环境而异。但是，在我目前能想到的所有情况下，组件之间的依赖关系因环境而异，尽管我可能遗漏了一些东西，并且/或者这种情况显然可以改变。

因此，最终的问题是，有人使用IoC框架会有类似的经历吗？或者，有人可以通过某种约定或简化的配置信息来推荐一个可以灵活注册的框架吗？我是否仍然可以从流畅的界面中受益，还是坚持使用XML？我想避免使用XML-hell。

编辑：这是一个.Net环境，我一直在查看Windsor，Ninject和Autofac。尽管Autofac对lambda表达式的支持似乎与其他方法有所不同，但它们现在似乎都支持两种注册方法(流利和XML)。有人在类似的多部署环境中使用它吗？

---

如果您想抽象化容器并能够使用其他容器，请考虑以我在此处尝试的方式将其注入

---

我使用Ninject。我喜欢我不必使用Xml配置依赖项这一事实。我可以直接使用C＃代码。也有多种方法可以做到这一点。我知道其他库具有该功能，但是Ninject提供了快速实例化，它非常轻巧，具有条件绑定，支持紧凑的框架，并且支持Silverlight 2.0。我还在它上面使用了包装器，以防将来将来将它换成另一个框架。在确定框架时，??您绝对应该尝试Ninject。

---

看看Ayendes犀牛公地。他在IoC容器上使用了抽象。这样您就可以随时切换容器。像container.Resolve之类的东西总是存在于每个容器中。

我使用Structuremap进行肮脏的工作，它具有流畅的界面和XML内容，并且对于大多数您想做的事情来说功能强大。每个人都有自己的优缺点，因此有一点抽象，以便您可以轻松切换(您永远不知道它们将要存在多长时间)是好的。对于其余的我，我认为Spring.Net，Castle Windsor，Ninject和StructureMap不再相距遥远。

---

我不确定它是否适合您的特定情况，您没有提到您正在使用的平台，但是我在Castle Windsor的IOC框架方面取得了巨大的成功。依赖关系在配置文件中设置(这是一个.NET框架)

---