Laravel服务提供者在平台短信服务中的应用
我的个人博客：逐步前行STEP
服务提供者是一个有效的将工具与业务解耦的方案，下面结合一个实用案例来解释服务提供者在实现提供基础服务的工具中的应用。
服务提供者
服务提供者是 Laravel 应用启动的中心，所有 Laravel 的核心服务都是通过服务提供者启动，通过使用服务提供者来管理类的依赖和执行依赖注入，可以很好地将一些底层服务与应用层代码解耦。
短信服务
短信服务对于一个系统来说，是基础的、通用的服务，不依赖于业务细节，所以应该将其与业务解耦。
系统设计
将不同服务商的sdk称为驱动，短信服务应该满足以下需求：
- 可替换驱动
- 驱动实例化对使用者透明
1、可替换驱动
要满足第1点，首先应该使用接口约束对外暴露的方法，只有驱动满足接口约束，才能不影响业务直接替换驱动，于是设计接口：
<?php
namespace App\Interfaces;
Interface SmsDriverInterface
{
public function sendMessage($phones, $template_id, $parameters);
}
如果接入的厂商是七牛云，则创建七牛云短信驱动，并在驱动中调用SDK实现功能：
<?php
namespace App;
use Qiniu\Auth;
use Qiniu\Http\Client;
use Qiniu\Http\Error;
use Qiniu\Sms\Sms;
class QiniuDriver implements SmsDriverInterface
{
const HOST = 'https://sms.qiniuapi.com';
const VERSION = 'v1';
public function __construct()
{
$this->auth = new Auth(config('access_key'), config('secret_key'));
$this->sms = new Sms($this->auth);
}
public function sendMessage($phones, $template_id, $parameters = [])
{
$phones = array_map(function($item)
{
if(!is_string($item))
{
$item = strval($item);
}
return $item;
}, $phones);
$ret = $this->sms->sendMessage($template_id, $phones, $parameters);
$result = $this->getResultApiRet($ret);
return $result;
}
}别的厂商的驱动也这样实现接口SmsDriverInterface，在更换厂商的时候，换一个驱动实例化就可以了。
2、驱动实例化对使用者透明
此处的使用者就是使用短信服务实现业务需求的工程师啦，因为短信服务的基础、通用的特性，会被在业务中很多地方使用，如果更换驱动的话，会涉及很多具体业务代码的修改，所以需要创建一个服务类，用来统筹驱动的使用，具体业务中再调用这个服务类，驱动的实例化就对业务透明了：
<?php
namespace App;
class SmsService
{
public $driver;
public function driver($driver_name)
{
switch($driver_name)
{
case 'qiniu':
$this->driver = new QiniuDriver();
break;
case 'aliyun':
$this->driver = new AliyunDriver();
break;
}
}
public function senndMessage($phone, $template_id)
{
return $this->driver->sendMessage($phone, $template_id);
}
} 再做改进，将传参选择驱动类型改为从配置中获取驱动类型：
<?php
namespace App;
class SmsService
{
public $driver;
public function driver()
{
switch(config('driver'))
{
case 'qiniu':
$this->driver = new QiniuDriver();
break;
case 'aliyun':
$this->driver = new AliyunDriver();
break;
}
}
......
}至此，基本满足了刚才所说的2点基本需求，但是，在增加驱动的时候要去改动driver()中的代码，增加其它驱动项，在服务类中枚举出所有的驱动似乎不够简洁，这里可以使用服务提供者再做优化：
<?php
namespace App\Providers;
use App\Interfaces\SmsDriverInterface;
use App\NullSms;
use App\QiniuSms;
use App\SmsService;
use Illuminate\Support\ServiceProvider;
class SmsServiceProvider extends ServiceProvider
{
protected $defer = true;
/**
* Bootstrap the application services.
*
* @return void
*/
public function boot()
{
}
/**
* Register the application services.
*
* @return void
*/
public function register()
{
$this->app->singleton(SmsDriverInterface::class, function ($app) {
switch(config('driver'))
{
case 'qiniu':
return new QiniuDriver();
}
return new NullSms();
});
}
public function provides()
{
return [SmsDriverInterface::class];
}
}
这里将驱动接口与配置中指定的具体驱动绑定，在服务类中的实例化方式可以改成依赖注入，因为短信驱动应该使用单例并且为了调用短信服务方便，将服务类中方法改为静态方法：
namespace App;
class SmsService
{
public $driver;
public function __construct(SmsDriverInterface $driver)
{
$this->driver = $driver;
}
public static function driver()
{
return app(self::class)->driver;
}
public static function sendMessage($phone, $template_id)
{
return SmsSend::driver()->sendMessage($phone, $template_id);
}
}最后将短信服务提供者添加到config/app.php文件的providers列表中，短信服务者的开发就完成了。
在这个案例中，短信服务提供者通过服务容器的依赖注入，实现了驱动在服务类中的自动实例化，在逻辑上将底层驱动与上层服务解耦。
这个案例比较简单，还有很多可以完善的地方，比如，不在服务提供者中能够使用switch去匹配驱动类型，而是增加一个驱动管理器，根据命名规则去实例化对应的驱动，这样的话就达到了增加并更换驱动的时候，只增加驱动类，以及更换config配置，就能“平滑”替换驱动的目的。