IoC容器的好处
我试图打开我的想法IoC的原则，我碰到了文章：马丁福勒IoC
他提供了一些使用PicoContainer的例子：
private MutablePicoContainer configureContainer() {
MutablePicoContainer pico = new DefaultPicoContainer();
Parameter[] finderParams = {new ConstantParameter("movies1.txt")};
pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
pico.registerComponentImplementation(MovieLister.class);
return pico;
}
然后使用示例：
public void testWithPico() {
MutablePicoContainer pico = configureContainer();
MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}
首先想到的是：为什么要使用像PicoContainer这样复杂的东西来配置对象的创建 - 实际上应用依赖注入 - （我是.NET开发人员，所以在.NET中它可能需要使用Reflection ，这是耗时的），当我们可以用快速的新操作符实现在（例如） 工厂或生成器中相同的封装对象创建。
另一件事： configureContainer（）仍然被编译，确切的类型是在编译时指定的。 那么为什么不使用工厂，并在配置文件中决定使用哪个工厂？
由于我对这种方法不熟悉，我想我缺少IoC容器的好处。
我只是在这里更新了与这个问题有关的答案。
在.Net中，我会看看Unity Framework（来自MSFT）的文档。 我还对编写实施注册的想法持怀疑态度，但随着时间的推移，我克服了这一点。 主要是因为你确实可以使用基于文件的配置，你可以注册多个实现（并且标记每个实现以便它们可以被调用），并且通常你在生产中不使用多个实现。
最大的好处是自动装配 - 您可以找到您的依赖关系。 一组复杂的类的链式自动装配非常漂亮，如果没有其他因为你可以轻松地注册一个10类中的一个类的Mock实例而不触及实现代码。 这导致了以引导容器为代价的大量可测试性。 现在对我来说，这是桌面赌注，甚至不值得讨论。 想象一下，如果Type1依赖于2,3和4，4依赖于5和6，6依赖于7.如果我想测试系统如何对6中的错误做出反应，我该怎么做？ 我需要做的就是Mock（使用像Moq这样的酷酷框架）Type6，注册模拟，但使用其他类的实际实现。
[Fact]
public void TestType6BlowingUp()
{
IocContainer container = new IocContainer();
container.RegisterType(Type1, Type1Impl);
container.RegisterType(Type2, Type2Impl);
container.RegisterType(Type3, Type3Impl);
container.RegisterType(Type4, Type4Impl);
container.RegisterType(Type5, Type5Impl);
container.RegisterType(Type6, Type6Mock);
container.RegisterType(Type7, Type7Impl);
Type1 type1 = container.Resolve<Type1>();
Type1Response response = type1.DoSomethingThatCallsType6Downstream();
//Should get errorcode 500
Assert.True("Expected ErrorCode 500", response.ErrorCode == 500);
}