Autofac 是 .NET 下的一个开源 Ioc 容器的实现库，虽然实际上系统自带有一个 Microsoft.Extensions.DependencyInjection，已经提供了基础的依赖注入的能力。但是我发现很多人喜欢用 Autofac，因为这个 Ioc 容器提供的功能更多更加强大。

首先简单介绍一下控制反转，依赖注入，虽然这个应该网上有很多文章都有讲过，但还是介绍一下自己的看法(不保证是对的)。

传统的面向过程开发的思维模式是由一个个的过程对数据进行叠加的操作，这段数据在内存中不断的变化，然后被 IO 输出。而面向对象开发的思维模型是在一个对象群集中，由一个靠近边界的对象接受来自边界外的消息以后，该对象 A 发现处理该消息还需要进行其他的操作，于是 A 传递一个新的消息给对象 B，然后 B 传递新消息传给 C 。。。可能一直延续多次，直到这个消息链条一直被处理完成。

然而这样就存在一个问题，由谁来构建这个群集中的对象，并保证他们能够正确的创建和消亡。最简单的方法就是由需要他的对象自己创建，大多数时候我们就是这样做的，加入构造对象 A 需要 B 的实例，那么就创建 B 的实例并将 B 的实例传递给A 的构造函数，但是当对象间的依赖关系变得复杂以后，靠手动创建对象将是一件非常麻烦的事情。原因在于你假如你依赖 3 个对象，而这三个对象的创建又依赖于其他的对象，那么这个依赖关系的链条将变得非常的长。

即使你能够通过一些帮助的函数来抽象出部分重复的依赖关系的准备过程。但是还有一个问题没有解决，那就是过于复杂的耦合问题，因为所有的依赖关系都被硬编码到了源代码当中，当你想要更改的的的时候的时候几乎是不可能的，例如本质上 A 依赖于 B 的原因是因为他需要一个能够处理 Print 消息的组件。

前面说的由依赖者自己准备被依赖者的反面就是控制反转，而依赖由外部提供给依赖者局势依赖注入。或者可以说，他俩没区别，茴香豆的五种写法，客制化/定制化，字儿有区别，意义没有。

实现 DI 或者说 Ioc 由两种方法：

1. 服务定位器模式
2. DI/Ioc 容器

一般认为定位器模式是反模式。

前面提到 DI 容器实际上主要功能只有一个就是依赖的管理，但是问题在于怎么管理。

Autofac 提出了一些概念：

1. 组件: 也就是实际被添加到容器中的类型
2. 服务：一组可以处理的消息集合，实际一般也就是接口
3. 组件生命周期：OnPreparing，OnActivating，OnActivated，OnRelease 组件在创建前后都会有指定的事件发生，我们可以注册指定的事件处理函数。
4. Scope 有些对象的存在时限定在一个指定范围的，就像代码块中声明的变量一样，当这个 Scope 消亡以后，对应的组件也就消亡了。
5. 实例作用域 当请求服务的时候返回的服务实例的作用返回是每次请求都返回一个新的，还是每次都相同，还是在同一个 Scope 中相同
6. 模块 Autofac 的配置

// TODO API 介绍