IoC，你把哪个容器放在哪里？ [英] IoC, Where do you put the container?
问题描述
有两个解决方案我用来解决这个问题。
我试图创建一个抽象工厂作为包装容器周围，我可以注入到我的应用程序的部分需要创建对象。这是有用的，但有一些缺点，因为城堡很难注入自己的容器作为依赖。所以我必须这样做，这种失败的IoC容器的整个目的。
我已经使用主要的applicationcontroller类来包装IoC容器和工作作为中央工厂/仓库。这是相当成功的，但是这个类变得太大了，就像一个中心的神对象，几乎所有的对象都有一个参考。
这两种解决方案都有一些工作但都有其缺点。所以我好奇，如果其他人有同样的问题，并找到更好的解决方案。
em>
问题不是依赖于对象B的对象A.在这里，我通常只是使用构造函数注入，一切都有效。有时我有一个类型为A的对象，需要在其生命周期内创建一个可变数量的其他类型的对象。我不知道该怎么做。
@Blair Conrad：到目前为止，维护问题并不严重。我有一些类依赖于容器对象调用container.Resolve<>。而且我不想让我的代码取决于我认为的基础架构。我还在尝试，所以我注意到这个项目从ninject切换到城堡时，我不得不改变很多代码。
@flowers：嗯。我喜欢你的拳头解决方案。它结合了我尝试过的两种解决方案的工作。我想我仍然在对象中思考太多，但在接口/责任方面还不够。
我尝试了专门建造的工厂，但是我想让他们使用幕后的容器来创建对象，我没有找到如何将容器以简洁的方式DI化为对象。
至少在我的应用程序中，依赖注入的主要优点是编写与上下文无关的代码的能力。从这个角度来看，你的第二个解决方案似乎真的颠覆了DI可以给你的好处。如果上帝对象暴露了引用它的每个类的不同接口，那么它可能不是太恶毒。但是，如果你走了那么远，我不明白为什么你不会把它一直走到环路上。
示例：你的God对象有一个getFoo（）方法和一个getBar（）方法。对象A需要一个Foo，对象B需要一个栏。如果A只需要一个Foo，Foo应该直接注入A，而A根本不应该知道上帝。但是，如果A需要继续创造Foos，给予一个参考上帝是不可避免的。但是你可以通过缩小对神的引用的类型来保护自己免受传神的伤害。如果你让上帝执行FooFactory并给A引用上帝执行的FooFactory，你仍然可以用上下文中立的方式在A中编写代码。这提高了代码重用的机会，并增加了您对上帝的改变不会导致意外的副作用的信心。例如，你可以确定从上帝那里删除getBar（），A类不会中断。
但是，如果你要拥有所有这些接口无论如何，你可能更好地编写专门的工厂类，并将所有的对象连接在一起，工厂包括在容器内，而不是根据容器包装。容器仍可配置工厂。
I'm using castle windsor for a pet-project I'm working on. I'm starting to notice that I need to call the IoC container in different places in my code to create new objects. This dependency on the container makes my code harder to maintain.
There are two solutions I've used to solve this problem
I tried to create abstract factories as wrappers around the container that I could inject into parts of my application that need to create objects. This works but has some drawbacks because castle has a hard time injecting it's own container as a dependency. So I have to do that by hand, this kind of defeats the whole purpose of the IoC container.
I have used the main applicationcontroller class to wrap the IoC container and work as a central factory/repository. This was quite succesfull but this class is getting too big and acts like a central god-object, almost every other objects has a reference to it.
Both solutions sort of work but both have their drawbacks. So I'm curious if other people had the same problem and have found better solutions.
edit The problem isn't for object A that depends on object B. Here I usually just use constructor injection and everything works. Sometimes I have objects of type A that need to create a variable number of other objects of type B during their lifetime. I'm not sure how to do this.
@Blair Conrad: The maintenance issues are not severe until now. I had some classes depend on the container object calling container.Resolve<>. And I don't want to have my code depending on what I think is infrastructure. I'm still trying things out so I noticed I had to change a lot of code when switching from ninject to castle for this project.
@flowers: Hmm. I like your fists solution. It combines the things that work from both solutions I've tried. I think I was still thinking too much in objects and not enough in interfaces/responsibilities. I tried purpose built factories but I would like to have them use the container behind the scenes to create the objects and I havn't found out how I can DI the container into objects in a clean way.
The main benefit of Dependency Injection, at least in my applications, is the ability to write code that is context agnostic. From that perspective, your second solution seems like it really subverts the benefit DI could be giving you. If the 'god object' exposes different interfaces to each class that references it, it might not be too evil. But if you went that far I don't see why you don't take it all the way to the hoop.
Example: Your God object has a getFoo() method and a getBar() method. Object A needs a Foo, object B needs a Bar. If A just needs one Foo, Foo should be injected directly into A and A should not be aware of God at all. But if A needs to keep creating Foos, giving A a reference to God is pretty much inevitable. But you can protect yourself from the damage done by passing God around by narrowing the type of the reference to God. If you make God implement FooFactory and give A a reference to the FooFactory implemented by God, you can still write the code in A in a context-neutral way. That improves the opportunities for code reuse, and it increases your confidence that a change to God will not cause unexpected side-effects. For example, you can be certain when removing getBar() from God that class A won't break.
BUT ... if you're going to have all those interfaces anyway, you're probably better off writing purpose-built factory classes and wiring all your objects together, factories included, within the container, rather than wrapping the container at all. The container can still configure the factories.
这篇关于IoC，你把哪个容器放在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
