LV中的Facade

第一次看到这个文件的时候，看到这么多的方法却找不到出处，心里很是着急。只能到处找答案了。
现在来解释说明一下

这个方法会执行，添加别名映射。
上面那些注释方法，一个是 db 对应类的，一个是 db.connection 对应类的。
Facade 是门面的意思，这个 DB 继承它，表示一个门面

• $app->get(\Illuminate\Support\Facades\DB::class)
• => $app->get(\Illuminate\Support\Facades\DB::getFacadeAccessor())
• => $app->get(‘db’)
• => $app->get(\Illuminate\Database\DatabaseManager::class)

容器获取对象，先通过门面类，获取门面类返回的接受访问对象（是一个字符串标识），再去访问这个标识，找到标识绑定的类，上面代码表面获取的是表面上获取的是 \Illuminate\Support\Facades\DB::class 对象，实际上获取的是 \Illuminate\Database\DatabaseManager::class 对象

为什么这么设计呢？

$app[‘DB’] => $app->DB => $app->get(‘DB’) 三个是一样的
这些入口标识符都是极具语义化的，明确表达了功能模块的类型，$app[‘语义化入口标识符’] 这样的容器获取功能模块的方法十分清晰。

为什么中间加入门面别名，而不是直接映射到具体的类？

• 因为每种功能模块，可能细化为多种类型，一个门面代表一种类型；通过修改配置文件的别名（更改门面），达到功能模块具体执行的类型。

• 比如你要个水果，有两个门面，一个苹果，一个梨子，改下水果对应的门面类型，就行了，买苹果，就去苹果店；买梨子，就去梨子店。

• 门面就是一个选择/决策；但是它有具体东西，比如这个 Illuminate\Support\Facades\DB 门面，返回了 db 那么这个门面的实体就是 db。但是，db 不是最底层的，db 还映射到了 Illuminate\Database\DatabaseManager

• 就是说，laravel container（容器）的别名映射关系可能是多层次的，标识符 => 实体类，
  中间可能经过多次别名传递，因为支持别名还有别名，所以配置别名的时候，不能乱搞，乱配置弄出死循环。你配置了什么别名，你要心里有数

  为什么说 变量、类名、函数名、类名、方法名 等等都要 语义化

• 最简单的容器，就是根据类名创建对象

• 更进一步，添加 接口=>类 映射，然后通过 接口/类名 创建对象

• 再更近一步，添加 标识符 => 类，通过标识符创建对象

• 再更进一步，多层映射关系，通过 标识符 找到最基础的类的对象

• 再更进一步，万物接对象，通过标识符可以获取任何类型数据

原本是映射到实体类型，现在可以绑定闭包，通过标识符获取这个闭包的执行结果，容器通过标识符获取对象，就是处理 标识符 的多层别名关系，得到实体类型或闭包，然后创建类或返回闭包执行结果。有单例，就有非单例，有些实体的获取，需要提供参数，然后又加了个 make(string $id, array $parameters = []) 方法。

理论上，容器应该只获取单例。需要明显区分的参数，就没必要让容器来创建，你直接获取参数，自己创建得了。但是，容器设计者都比较贪心，容器的最大功能就是处理参数的依赖关系，单例非单例都让它做得了。
开始是个小容器，后面越写功能越复杂，你懂得，让作者自己看源代码，都会头痛，时间久了，要是忘记自己设计时的一些“约定”，自己看着都费劲。

本作品采用《CC 协议》，转载必须注明作者和本文链接