自动依赖注入
什么是依赖注入:通过类型提示的方式向函数传递参数。
实例1
首先,定义一个类:
1 | /routes/web.php |
假如我们在其他地方要使用到 Bar 提供的功能(服务),怎么办,直接传入参数即可:
1 | /routes/web.php |
访问 /bar,显示 $bar 的实例:
1 | Bar {#272} |
也就是说,我们不需要先对其进行实例!如果学过 PHP 的面向对象,都知道,正常做法是这样:
1 | class Bar {} |
实例2
可以看一个稍微复杂的例子:
1 | class Baz {} |
为了在 Bar 中能够使用 Baz 的功能,我们需要实例化一个 Baz,然后在实例化 Bar 的时候传入 Baz 实例。
在 Laravel 中,不仅仅可以自动注入 Bar,也可以自动注入 Baz:
1 | /routes/web.php |
显示结果:
1 | Baz {#276} |
小结
通过上述两个例子,可以看出,在 Laravel 中,我们要在类或者函数中使用其他类体用的服务,只需要通过类型提示的方式传递参数,而 Laravel 会自动帮我们去寻找响对应的依赖。
那么,Laravel 是如何完成这项工作的呢?答案就是通过服务容器。
服务容器
什么是服务容器
服务容器,很好理解,就是装着各种服务实例的特殊类。可以通过「去餐馆吃饭」来进行类比:
- 吃饭 - 使用服务,即调用该服务的地方
- 饭 - 服务
- 盘子 - 装饭的容器,即服务容器
- 服务员 - 服务提供者,负责装饭、上饭
实现
饭:定义Rice类:
1
2
3
4
5
6
7
8
9
10/app/Rice.php
namespace App;
class Rice
{
public function food()
{
return '香喷喷的白米饭';
}
}把饭装盘子:
在容器中定义了名为 rice 的变量(你也可以起其他名字,比如 rice_container),绑定了 Food 的实例:1
2
3app()->bind('rice', function (){
return new \App\Rice();
});
也可以写成:
1 | app()->bind('rice',\App\Rice::class); |
现在,吃饭了,通过 make 方法提供吃饭的服务:
1 | Route::get('eat', function() { |
make 方法传入我们刚才定义的变量名即可调用该服务。
访问 /eat
,返回 香喷喷的白米饭。
为了方便起见,我们在路由文件中直接实现了该过程,相当于自给自足。但是服务通常由服务提供者来管理的。
因此,我们可以让 AppServiceProvider 这个服务员来管理该服务:
1 | /app/Providers/AppServiceProvider.php |
更为常见的是,我们自己创建一个服务员:
1 | $ php artisan make:provider RiceServiceProvider |
注册:
1 | /app/Providers/RiceServiceProvider.php |
这里定义了 register() 方法,但是还需要调用该方法才能真正绑定服务到容器,因此,需要将其添加到 providers 数组中:
1 | /config/app.php |
这一步有何作用呢?Laravel 在启动的时候会访问该文件,然后调用里面的所有服务提供者的 register() 方法,这样我们的服务就被绑定到容器中了。
小结
通过上述的例子,基本上可以理解服务容器和服务提供者的使用。当然了,我们更为常见的还是使用类型提示来传递参数:
1 | use App\Rice; |
在本例中,使用自动依赖注入即可。不需要在用 bind 来手动绑定以及 make 来调用服务。那么,为什么还需要 bind 和 make 呢? make 比较好理解,我们有一些场合 Laravel 不能提供自动解析,那么这时候手动使用 make 解析就可以了,而 bind 的学问就稍微大了点,后面将会详细说明。
门面
门面是什么,我们回到刚才的「吃饭」的例子:
1 | Route::get('eat', function(Rice $rice) { |
在 Laravel,通常还可以这么写:
1 | Route::get('eat', function() { |
或者
1 | Route::get('eat', function() { |
那么,Laravel 是如何实现的呢?答案是通过门面。
门面方法实现
先来实现 Rice::food(),只需要一步:
1 | /app/RiceFacade.php |
现在,RiceFacade 就代理了 Rice 类了,这就是门面的本质了。我们就可以直接使用:
1 | Route::get('eat', function() { |
因为 \App\RiceFacade 比较冗长,我们可以用 php 提供的 class_alias 方法起个别名吧:
1 | /app/Providers/RiceServiceProvider.php |
这样做的话,就实现了一开始的用法:
1 | Route::get('eat', function() { |
看上去就好像直接调用了 Rice 类,实际上,调用的是 RiceFacade 类来代理,因此,个人觉得Facade 翻译成假象比较合适。
最后,为了便于给代理类命名,Laravel 提供了统一命名别名的地方:
1 | /config/app.php |
门面实现过程分析
首先:
1 | Rice::food(); |
因为 Rice 是别名,所以实际上执行的是:
1 | \App\RiceFacade::food() |
但是我们的 RiceFacade 类里面并没有定义静态方法 food 啊?怎么办呢?直接抛出异常吗?不是,在 PHP 里,如果访问了不可访问的静态方法,会先调用 __callstatic
,所以执行的是:
1 | \App\RiceFacade::__callStatic() |
虽然我们在 RiceFacade 中没有定义,但是它的父类 Facade 已经定义好了:
1 | /vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php |
主要工作就是第一步实例化:
1 | public static function getFacadeRoot() |
进一步查看 resolveFacadeInstance() 方法:
1 | protected static function resolveFacadeInstance($name) |
第一步比较好理解,如果我们之前在 RiceFacade 这样写:
1 | protected static function getFacadeAccessor() |
那么就直接返回 Rice 实例了,这也是一种实现方式。
主要难点在于最后这行:
1 | return static::$resolvedInstance[$name] = static::$app[$name]; |
看上去像是在访问 $app数组,实际上是使用 数组方式来访问对象,PHP 提供了这种访问方式接口,而 Laravel 实现了该接口。
也就是说,$app 属性其实就是对 Laravel 容器的引用,因此这里实际上就是访问容器上名为 rice 的对象。而我们之前学习容器的时候,已经将 rice 绑定了 Rice 类:
1 | public function register() |
所以,其实就是返回该类的实例了。懂得了服务容器和服务提供者,理解门面也就不难了。
辅助方法实现
辅助方法的实现,更简单了。不就是把 app->make(‘rice’) 封装起来嘛:
1 | /vendor/laravel/framework/src/Illuminate/Foundation/helpers.php |
然后我们就可以使用了:
1 | Route::get('eat', function() { |
小结
Laravel 提供的三种访问类的方式:
- 依赖注入:通过类型提示的方式实现自动依赖注入
- 门面:通过代理来访问类
- 辅助方法:通过方法的方式来访问类
本质上,这三种方式都是借助于服务容器和服务提供者来实现。那么,服务容器本身有什么好处呢?我们接下来着重介绍下。
IOC
不好的实现
我们来看另外一个例子(为了方便测试,该例子都写在路由文件中),假设有三种类型的插座:USB、双孔、三孔插座,分别提供插入充电的服务:
1 | class UsbsocketService |
设备要使用插座的服务来充电:
1 | class Device { |
现在有一台手机要进行充电:
1 | Route::get('/charge',function(){ |
因为 Laravel 提供了自动依赖注入功能,因此可以写成:
1 | Route::get('/charge/{device}',function(Device $device){ |
访问 /charge/phone
,页面显示 phone 正在插入 USB 充电
。
假如,现在有一台电脑要充电,用的是三孔插座,那么我们就需要去修改 Device 类:
1 | $this->socketType = new ThreeSocketService(); |
这真是糟糕的设计,设备类对插座服务类产生了依赖。更换设备类型时,经常就要去修改类的内部结构。
好的实现
为了解决上面的问题,可以参考「IOC」思路:即将依赖转移到外部。来看看具体怎么做。
首先定义插座类型接口:
1 | interface SocketType { |
让每一种插座都实现该接口:
1 | class UsbsocketService implements SocketType |
最后,设备中传入接口类型而非具体的类:
1 | class Device { |
实例化的时候再决定使用哪种插座类型,这样依赖就转移到了外部:
1 | Route::get('/charge',function(){ |
我们现在可以再不修改类结构的情况下,方便的更换插座来满足不同设备的充电需求:
1 | Route::get('/charge',function(){ |
自动依赖注入的失效
上面举的例子,我们通过 Laravel 的自动依赖注入可以进一步简化:
1 | Route::get('/charge',function(Device $device){ |
这里的类型提示有两个,一个是 Device $device,一个是 Device 类内部构造函数传入的 SocketType $sockType。第一个没有问题,之前也试过。但是第二个 SocketType 是接口,而 Laravel 会将其当成类试图去匹配 SocketType 的类并将其实例化,因此访问 /charge 时候就会报错:
1 | Target [SocketType] is not instantiable while building [Device]. |
错误原因很明显,Laravel 没法自动绑定接口。因此,我们就需要之前的 bind 方法来手动绑定接口啦:
1 | app()->bind('SocketType',ThreeSocketService::class); |
现在,如果要更换设备,我们只需要改变绑定的值就可以了:
1 | app()->bind('SocketType',DoubleSocketService::class); |
也就是说,我们将依赖转移到了外部之后,进一步由第三方容器来管理,这就是 IOC。
契约
契约,不是什么新奇的概念。其实就是上一个例子中,我们定义的接口:
1 | interface SocketType { |
通过契约,我们就可以保持松耦合了:
1 | public function __construct(SocketType $socketType) // 传入接口而非具体的插座类型 |
然后服务容器再根据需要去绑定哪种服务即可:
1 | app()->bind('SocketType',UsbSocketService::class); |