请用IoC容器卖给我

我已经看到一些建议在代码中使用IoC容器的方法。动机很简单。采取以下依赖项注入代码：

class UnitUnderTest
{
    std::auto_ptr<Dependency> d_;
public:
    UnitUnderTest(
        std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency)
    ) : d_(d)
    {
    }
};


TEST(UnitUnderTest, Example)
{
    std::auto_ptr<Dependency> dep(new MockDependency);
    UnitUnderTest uut(dep);
    //Test here
}

进入：

class UnitUnderTest
{
    std::auto_ptr<Dependency> d_;
public:
    UnitUnderTest()
    {
        d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency")));
    }
};


TEST(UnitUnderTest, Example)
{
    UnitUnderTest uut;
    //Test here
}

//Config for IOC container normally
<Dependency>ConcreteDependency</Dependency>

//Config for IOC container for testing
<Dependency>MockDependency</Dependency>

（以上当然是假设的C ++示例）

尽管我同意通过删除依赖项构造函数参数来简化类的接口，但出于某些原因，我认为治愈的方法比疾病的方法还差。首先，这对我来说是个很大的问题，这使您的程序依赖于外部配置文件。如果您需要单个二进制部署，则无法使用这些类型的容器。第二个问题是，API现在是弱类型，更糟糕的是，是字符串类型的。证据（在此假设示例中）是IoC容器的字符串参数，并对结果进行强制转换。

所以..使用这些容器还有其他好处吗？或者我只是不同意那些推荐的容器？

在具有许多层和许多活动部件的大型应用程序中，与优点相比，缺点似乎变得很小。

容器确实“简化了类的接口”，但是它以非常重要的方式做到了。容器是对依赖项注入所产生问题的一种解决方案，即需要在整个地方，向下通过对象图以及跨功能区域传递依赖项。您在这里有一个具有一个依赖关系的小示例-如果该对象具有三个依赖关系，并且依赖于该对象的对象有多个依赖于它们的对象，依此类推？如果没有容器，那些依赖关系链顶部的对象最终将负责跟踪整个应用程序中的所有依赖关系。

也有不同种类的容器。并非所有人都是字符串类型的，也不是所有人都需要配置文件。

Java的Guice IoC框架不依赖于配置文件，而是依赖于配置代码。这意味着该配置的代码与构成您实际应用程序的代码没有什么不同，并且可以重构等。

我相信Guice是最终实现正确配置的Java IoC框架。

这个伟大的SO答案由本Scheirman详细介绍了C＃的一些代码示例; IoC容器（DI）的一些优点是：

• 您的依赖项链可能会嵌套，并且手动将其连接起来很快变得笨拙。
• 允许使用面向方面的编程。
• 声明性和嵌套数据库事务。
• 声明性和嵌套工作单元。
• 正在记录。
• 前/后条件（按合同设计）。