使用 Laravel 服務容器的優勢

這篇文章主要介紹了關於使用 Laravel 服務容器的優勢 ，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

如果說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服務容器：

<?phpinterface 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來執行個體化對象的時候還是會產生依賴.比如上面$tra = new Traveller($trafficTool),這說明我們要建立一個Traveller之前必須得有一個$trafficTool,即Traveller依賴於trafficTool.當使用new來執行個體化Traveller的時候,Traveller和trafficTool之間就產生了耦合.這樣,這兩個組件就沒辦法分開了。

現在我們來看看使用laravel服務容器是怎麼實現的：
在服務容器中綁定類

<?phpnamespace 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服務容器，實際開發中它會給你提供更多的便利。當然它也不是完美無缺的，下篇部落格打算再來描述它的缺點，總之實際使用中揚長避短才是關鍵。

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！