浅谈Laravel中的设计模式(三) Container 容器

2,660 阅读3分钟

阅读时长:5分钟

技术预备:熟悉Laravel的使用

容器(Container)

一、什么是容器呢?

容器这个词估计使用过Laravel的童鞋们肯定不陌生了,但是日常业务开发好像都没见过它,我们今天就来看看他到底是干什么用的,本篇使用Laravel的精简版Lumen进行举例。

首先他出现在哪里呢?

我们可以从入口文件找到他,就是这个$app,那么这个$app到底是什么?我们继续深入看看

在app.php文件夹中可以看到,这个$app就是Laravel\Lumen\Application::class,而这个类继承了Container类,所以说Application类就是Laravel中的容器了。

“赵童鞋,究竟什么是容器呢?"

Laravel中的容器其实就是整个框架的核心,在上图的index.php中可以看到,一个Request进来后,index.php其实只是调用了$app->run()方法。

之后的URL解析、中间件处理、依赖注入,直到请求进入业务方法里,通通都是容器在进行处理。

二、容器是怎么运作的呢?

像上述所说,Laravel框架中的大部分功能都是在容器中实现的,而最常用的功能就有服务提供者。

我们这里就通过调用DB的Facade类来说明一下容器中的服务提供者是怎么运作的。

首先可以看到,在Application中,"db" 绑定了registerDatabaseBindings()这个方法。

registerDatabaseBindings()方法中,使用了框架提供的singleton()注册了一个关联“db”的匿名函数,而这个匿名函数就是“db”的解析器。

在前面的篇章我们讲到,当我们通过静态调用DB类的时候,Laravel的Facade模式就通过调用resolveFacadeInstance()去容器中解析出“db”的实际对象。

可以看到,里面的实际操作是使用了static::$app[$name]的写法去获取。

因为Laravel中的Container实现了ArrayAccess,所以实际调用会进入到Container的offsetGet()方法中,也就是进入了make()方法,而因为容器的实际对象是Application类,所以会先进入Application的make()方法。

在make方法中,终于出现了前面说到的$availableBindings,也就是说,在这里会调用前面的registerDatabaseBindings()方法,注册“db”的解析器。再进行调用父类,也就是Container的make()方法。

而make()方法又跳进了resolve()中。

(不得不说,当初第一次看框架代码时我也被绕晕了,习惯就好)

resolve()这里,容器会先去$this->instances中查找,也就是一个用于存放已实例化的对象的数组。

当获取不到的时候,就会通过$this->getConcrete()获取到我们前面注册的“db”的解析器,也就是调用文章最前面registerDatabaseBindings()中的匿名函数,获取到“db”的实例,最终返回给前面的DB静态调用。

(至于匿名函数解析器是怎么工作的,感兴趣的童鞋可以去看看官方文档的loadComponent、register流程,亲自去看一遍源码印象更深刻)

三、容器有什么用呢?

通过上面的描述,我们可以知道容器中是有一个数组instances[]保存着已实例化了的对象的,也就是单例模式。

而没有实例化的对象也是有着类似于解析器之类的关联机制。

这种做法最大的好处就是可以减少对象生成的开销,例如某个接口需要使用到Redis和DB,那么框架就会去调用解析器将这两个对象解析出来,并且保存在数组中以便于后续的逻辑中进行复用。

而当某个接口不需要Redis和DB的时候,就可以节省下这两个对象的开销,并不需要修改一句代码。

四、结语

本次的浅谈容器到这里就结束了,如果觉得被绕晕了的话,说明真的认真看了o( ̄▽ ̄)d。

千万别灰心,亲自去跟着源码走一趟,这种被绕晕的感觉就会慢慢消失了。

----- End -----

更多好文

请扫描下面二维码

欢迎关注~