IoC 框架的 Builder 和 Container 这两个词从何而来？答案

【问题标题】：Where do the words Builder and Container come from for an IoC Framework?IoC 框架的 Builder 和 Container 这两个词从何而来？
【发布时间】：2017-01-21 06:47:03
【问题描述】：

我经常使用 Autofac，但对变量命名约定“容器”和“构建器”感到困惑。

有时似乎“容器”是“构建”的。

其他时候，它似乎是一个“容器”“构建”它可以解决的依赖项。

有时我看到开发人员将“容器”称为“构建器”，将“构建器”称为“容器”。

一个很好的例子是我今天自己的代码，使用 Autofac 和 NServiceBus，我在 C# 中有以下方法：

public BusConfiguration CreateConfigurationWithCustomContainer(Autofac.IContainer container)

在实现中，该方法：

BusConfiguration.UseContainer<AutofacBuilder>(
                 customizations =>
                 {
                     customizations.ExistingLifetimeScope(container);
                 }
            );

在此示例中，NServiceBus.BusConfiguration 有一个名为 UseContainer 的通用方法，我使用的是 Type NServiceBus.AutofacBuilder 和我的参数，名为 container，它属于 Type AutoFac.IContainer；

我的问题：

所以 NServiceBus 使用了“Builder”这个词，而 AutoFac 使用了“Container”这个词，它们在概念上对 NServiceBus 团队来说是一样的吗 Autofac 团队呢？
关于 IoC 框架，“容器”和“构建器”这两个词从何而来？
“容器”和“构建器”有何不同？还是在大多数情况下，就 IoC 框架而言，它们是否相同？

【问题讨论】：

标签： c# dependency-injection inversion-of-control autofac ioc-container

【解决方案1】：

建造者

Builder Pattern 是软件中常见的一种设计模式。它不是特定于依赖注入的。事实上，很多 DI 容器甚至不使用构建器模式。

也就是说，如何使用 DI 容器的现代观点是在 composition root 中配置组件，然后解析一个或多个对象图以启动应用程序。 builder 模式非常适合防止这种模式被违反（也就是说，它使得在运行时注册组件变得很困难）。

容器

容器是一个特定于 IoC 的概念，通常是指软件库，或者更具体地说，是一个库的一部分，它跟踪抽象-具体类型映射并允许用户解析它们。 Autofac 是 .NET 中众多可用的 IoC 容器之一。

【讨论】：