IoC,你把容器放在哪里？

我正在使用温莎城堡作为我正在研究的宠物项目.我开始注意到我需要在代码中的不同位置调用IoC容器来创建新对象.这种对容器的依赖使我的代码难以维护.

我用过两种解决方案来解决这个问题

我试图创建抽象工厂作为容器周围的包装器,我可以注入我需要创建对象的应用程序的部分.这有效,但有一些缺点,因为城堡很难将自己的容器注入依赖.所以我必须手工完成,这种方式会破坏IoC容器的整个目的.

我已经使用主应用程序控制器类来包装IoC容器并作为中央工厂/存储库工作.这是非常成功的,但是这个类太大了,就像一个中心神对象,几乎所有其他对象都有它的引用.

两种解决方案都有一些工作,但两者都有其缺点.所以我很好奇其他人是否有同样的问题,并找到了更好的解决方案.

编辑 问题不适用于依赖于对象B的对象A.这里我通常只使用构造函数注入,一切正常.有时我有类型A的对象需要在其生命周期中创建可变数量的其他类型的B对象.我不知道该怎么做.

@Blair Conrad:直到现在,维护问题并不严重.我有一些类依赖于容器对象调用container.Resolve <>.而且我不希望我的代码取决于我认为的基础设施.我还在尝试,所以我注意到在从这个项目的ninject切换到城堡时我必须更改很多代码.

@flowers:嗯.我喜欢你的拳头解决方案.它结合了我尝试过的两种解决方案.我认为我仍然在对象中思考太多而在界面/职责方面还不够.我尝试过专门建造的工厂,但我想让他们在幕后使用容器来创建对象,而我却不知道如何以一种干净的方式将容器转移到对象中.

请不要使用像IoC.Container.Resolve或ContainerFactory.GetContainer这样的静态类!

这使代码更复杂,更难以维护,重用和读取.

通常,任何单个组件或服务只有一个单点注入 - 这是构造函数(具有可选属性).通常,您的组件或服务类不应该知道容器这样的东西的存在.

如果您的组件确实需要在内部具有动态解析(即根据名称解析异常处理策略或工作流),那么我建议考虑通过高度特定的提供程序提供IoC权限

我建议你看看Nick Blumhardt的迷你系列.

http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx