關于使用 Laravel 服務容器的優勢介紹

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

<?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-&gt;_trafficTool-&gt;go(); ??} }

當旅行者要坐火車去旅行通常我們這樣寫:

<?php  $train = new Train(); $tra = new Traveller($train); $tra->visitTibet();

事實上這種寫法已經非常不錯了,因為對于旅行工具的依賴已經通過接口的方式轉移到外部了。但是使用new來實例化對象的時候還是會產生依賴.比如上面trafficTool),這說明我們要創建一個Traveller之前必須得有一個$trafficTool,即Traveller依賴于trafficTool.當使用new來實例化Traveller的時候,Traveller和trafficTool之間就產生了耦合.這樣,這兩個組件就沒辦法分開了。

現在我們來看看使用laravel服務容器是怎么實現的:

在服務容器中綁定類

<?php namespace AppProviders; use LaravelLumenProvidersEventServiceProvider as ServiceProvider; class RepositoryServiceProvider extends ServiceProvider {   public function register()   {      //在服務容器中綁定類      $this->app-&gt;bind(?'TrafficTool',?'Train'); ?????$this-&gt;app-&gt;bind('Traveller',?'Traveller'); ??} }

實例化對象

<?php // 實例化對象 $tra = app()->make('Traveller'); $tra-&gt;visitTibet();

當我們使用服務容器獲取旅行類的對象時,容器會自動注入對象所需要的參數。而在此之前我只需要綁定特定的類就可以了,這樣做才體現了真正的自動化,而且使得旅行類和旅行工具類完全解耦了。當我們需要更改旅行方式的時候,我們就只需要更改綁定就可以了。

總結

上面舉了幾個簡單的例子,如果能完全理解和掌握laravel服務容器,實際開發中它會給你提供更多的便利。當然它也不是完美無缺的,下篇博客打算再來描述它的缺點,總之實際使用中揚長避短才是關鍵。

? 版權聲明
THE END
喜歡就支持一下吧
點贊13 分享