如果說laravel框架的核心是什麼,那麼無疑是服務容器。理解服務容器的概念,對於我們使用laravel太重要了,應該說是否理解服務容器的概念是區分是否入門laravel的重要條件。因爲整個框架正是在服務容器這一基礎上構建起來的。
laravel服務容器就像一個高度自動化的工廠,你需要的東西,定製好模型,使用特定接口來製造。
因爲使用了服務容器,laravel中大部分對象實例化的方式是這樣的:
$obj1 = $container->make('class1', 'class2');
$obj2 = $container->make('class3', 'class4');
但是在沒有使用服務容器的情況下,以下這種方式同樣可以做到:
$obj1 = new class1(new class2());
$obj2 = new class3(new class4());
那麼使用服務容器的優勢到底是什麼呢?下面我們通過一些具體例子來分析下它的優勢:
例一、發送郵件
我們把發送郵件的功能封裝成一個類,需要使用的時候,實例化並調用發送方法。
以下是不使用laravel服務容器常見的方式:
/**
*發送郵件服務類
*/
class EmailService{
public function send(){
//todo 發送郵件方法
}
}
//如果任何地方要發郵件我們就複製下面這兩行代碼
$emailService = new EmailService();
$emailService->send();
使用了了laravel服務容器以後:
$this->app->bind('emailService', function ($app) {
return new EmailService();
});
//如果任何地方要發郵件我們就複製下面這兩行代碼
$emailService = app('emailService');
$emailService->send();
這使得我們的代碼更加簡潔了,並且由於有了中間層,靈活性提高了(解耦),那麼無論是測試(在測試時我們可以僞造類替換EmailService類)還是優化EmailService類,都變得更加方便。
//只需要改這一個地方
$this->app->bind('emailService', function ($app) {
return new SupperEmailService();
});
其他調用的部分我們完全不用動,如果我們沒有這個綁定操作,那麼不得不在每個使用郵件服務的地方做更改。
//使用到EamilSerice類的每個地方都要更改
$emailService = new SupperEmailService();
$emailService->send();
例二、實現單例模式
還是上面的例子,出於性能的考慮,你需要SupperEamilService類實現單例模式,於是在不使用laravel服務容器的情況下,你將SupperEmailService類更改如下:
class SupperEamilService{
//創建靜態私有的變量保存該類對象
static private $instance;
//防止直接創建對象
private function __construct(){
}
//防止克隆對象
private function __clone(){
}
static public function getInstance(){
//判斷$instance是否是Uni的對象
//沒有則創建
if (!self::$instance instanceof self) {
self::$instance = new self();
}
return self::$instance;
}
//發送郵件方法
public function send(){
}
}
除此之外,由於現在SupperEamilService類構造函數爲私有,無法通過new關鍵字來實例化對象,所以在每個實例化SupperEmailService類的地方都要改成這樣:
$emailService=SupperEmailService::getInstance();
$emailService->send();
laravel服務容器天生支持單例,下面是laravel的實現方式:
//只需要把bind改成singleton
$this->app->singleton('emailService', function ($app) {
return new SupperEmailService();
});
要實現單例甚至只需要改一行代碼,把原來的bind方法改成singleton ,通過容器取出來的便是單例,真是太方便了。
例三、旅行者去旅行
這個例子假設一個旅行者去西藏旅行,可以做火車(train)或者走路(leg)去。
不使用laravel服務容器:
<?php
interface TrafficTool
{
public function go();
}
class Train implements TrafficTool
{
public function go()
{
echo "train....";
}
}
class Leg implements TrafficTool
{
public function go()
{
echo "leg..";
}
}
class Traveller
{
/**
* @var Leg|null|Train
* 旅行工具
*/
protected $_trafficTool;
public function __construct(TrafficTool $trafficTool)
{
$this->_trafficTool = $trafficTool;
}
public function visitTibet()
{
$this->_trafficTool->go();
}
}
當旅行者要坐火車去旅行通常我們這樣寫:
<?php
$train = new Train();
$tra = new Traveller($train);
$tra->visitTibet();
事實上這種寫法已經非常不錯了,因爲對於旅行工具的依賴已經通過接口的方式轉移到外部了。但是使用new來實例化對象的時候還是會產生依賴.比如上面trafficTool),這說明我們要創建一個Traveller之前必須得有一個$trafficTool,即Traveller依賴於trafficTool.當使用new來實例化Traveller的時候,Traveller和trafficTool之間就產生了耦合.這樣,這兩個組件就沒辦法分開了。
現在我們來看看使用laravel服務容器是怎麼實現的:
在服務容器中綁定類
<?php
namespace App\Providers;
use Laravel\Lumen\Providers\EventServiceProvider as ServiceProvider;
class RepositoryServiceProvider extends ServiceProvider
{
public function register()
{
//在服務容器中綁定類
$this->app->bind( 'TrafficTool', 'Train');
$this->app->bind('Traveller', 'Traveller');
}
}
實例化對象
<?php
// 實例化對象
$tra = app()->make('Traveller');
$tra->visitTibet();
當我們使用服務容器獲取旅行類的對象時,容器會自動注入對象所需要的參數。而在此之前我只需要綁定特定的類就可以了,這樣做才體現了真正的自動化,而且使得旅行類和旅行工具類完全解耦了。當我們需要更改旅行方式的時候,我們就只需要更改綁定就可以了。
總結
上面舉了幾個簡單的例子,如果能完全理解和掌握laravel服務容器,實際開發中它會給你提供更多的便利。當然它也不是完美無缺的,總之實際使用中揚長避短纔是關鍵。
更多內容請訪問
八重櫻:怎麼從一名碼農成爲架構師的必看知識點:目錄大全(持續更新)50W年薪挑戰!zhuanlan.zhihu.com
以上內容希望幫助到大家,很多PHPer在進階的時候總會遇到一些問題和瓶頸,業務代碼寫多了沒有方向感,不知道該從那裏入手去提升,對此我整理了一些資料,包括但不限於:分佈式架構、高可擴展、高性能、高併發、服務器性能調優、TP6,laravel,YII2,Redis,Swoole、Swoft、Kafka、Mysql優化、shell腳本、Docker、微服務、Nginx等多個知識點高級進階乾貨需要的可以免費分享給大家,需要的可以加入我的官方羣點擊此處。