我正在将城堡温莎用于我正在从事的宠物项目。我开始注意到我需要在代码的不同位置调用 IoC 容器来创建新对象。这种对容器的依赖使我的代码更难维护。
我用两种解决方案来解决这个问题
我尝试创建抽象工厂作为容器的包装器，我可以将其注入(inject)到需要创建对象的应用程序部分中。这有效但有一些缺点，因为城堡很难将自己的容器作为依赖项注入(inject)。所以我必须手动完成，这违背了 IoC 容器的全部目的。
我使用主 applicationcontroller 类来包装 IoC 容器并作为中央工厂/存储库工作。这是相当成功的，但是这个类变得太大了，就像一个中心神对象，几乎所有其他对象都有对它的引用。
这两种解决方案都有效，但都有其缺点。所以我很好奇其他人是否有同样的问题并找到了更好的解决方案。
编辑
问题不在于依赖于对象 B 的对象 A。这里我通常只使用构造函数注入(inject)，一切正常。有时我有类型 A 的对象需要在它们的生命周期中创建可变数量的其他类型 B 的对象。我不知道该怎么做。
@Blair Conrad:到目前为止，维护问题并不严重。我有一些类依赖于调用 container.Resolve<> 的容器对象。而且我不想让我的代码取决于我认为的基础设施。我仍在尝试一些东西，所以我注意到当这个项目从 ninject 切换到城堡时，我不得不更改很多代码。
@花:嗯。我喜欢你的拳头解决方案。它结合了我尝试过的两种解决方案中有效的东西。我想我仍然在对象方面考虑得太多，而在接口(interface)/职责方面考虑得还不够多。
我尝试过专门 build 的工厂，但我想让他们在幕后使用容器来创建对象，我还没有找到如何以干净的方式将容器 DI 到对象中。
最佳答案
至少在我的应用程序中，依赖注入(inject)的主要好处是能够编写与上下文无关的代码。从这个角度来看，您的第二个解决方案似乎真的颠覆了 DI 可能给您带来的好处。如果“上帝对象”向引用它的每个类公开不同的接口(interface)，它可能不会太邪恶。但如果你走那么远，我不明白你为什么不把它一直带到篮筐。
示例:您的 God 对象有一个 getFoo() 方法和一个 getBar() 方法。对象 A 需要一个 Foo，对象 B 需要一个 Bar。如果 A 只需要一个 Foo，则 Foo 应该直接注入(inject) A 并且 A 根本不应该知道 God。但是如果 A 需要继续创建 Foos，那么将 A 引用到 God 几乎是不可避免的。但是你可以通过缩小对上帝的引用类型来保护自己免受绕过上帝造成的损害。如果你让 God 实现 FooFactory 并给 A 一个对 God 实现的 FooFactory 的引用，你仍然可以以上下文中立的方式在 A 中编写代码。这增加了代码重用的机会，并增加了你对上帝的改变不会导致意外副作用的信心。例如，当从 God 中删除 getBar() 时，您可以确定 A 类不会中断。
但是......如果你无论如何都要拥有所有这些接口(interface)，你可能最好编写专门构建的工厂类并将所有对象(包括工厂)连接到容器中，而不是完全包装容器。容器仍然可以配置工厂。
关于oop - IoC，你把容器放在哪里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/109668/