詳解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 傳送郵件方法
}
}
//如果任何地方要發郵件我們就複製下面這兩行代www.cppcns.com碼
$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(T程式設計客棧rafficTool $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{ mSwDfYa public function register(){ //在服務容器中繫結類 $this->app->bind( 'TrafficTool','Train'); $this->app->bind('Traveller','Traveller'); } }
例項化物件
<?php
// 例項化物件
$tra = app()->make('Traveller');
$tra->vismSwDfYaitTibet();
當我們使用服務容器獲取旅行類的物件時,容器會自動注入物件所需要的引數。而在此之前我只需要繫結特定的類就可以了,這樣做才體現了真正的自動化,而且使得旅行類和旅行工具類完全解耦了。當我們需要更改旅行方式的時候,我們就只需要更改繫結就可以了。
總結
上面舉了幾個簡單的例子,如果能完全理解和掌握laravel服務容器,實際開發中它會給你提供更多的便利。當然它也不是完美無缺的,總之實際使用中揚長避短才是關鍵。
以上就是詳解Laravel服務容器的優勢的詳細內容,更多關於Laravel服務容器的優勢的資料請關注我們其它相關文章!