Laravel 5.4 入門系列 13. 終篇：小白也能看懂的 Laravel 核心概念講解

BenCHou 發布于2019-06-27 16:19 / 764人閱讀

摘要：但是服務通常由服務提供者來管理的。小結通過上述的例子，基本上可以理解服務容器和服務提供者的使用。懂得了服務容器和服務提供者，理解門面也就不難了。

自動依賴注入

什么是依賴注入，用大白話將通過類型提示的方式向函數傳遞參數。

實例 1

首先，定義一個類:

/routes/web.php
class Bar {}

假如我們在其他地方要使用到 Bar 提供的功能（服務），怎么辦，直接傳入參數即可：

/routes/web.php
Route::get("bar", function(Bar $bar) {
    dd($bar);
});

訪問 /bar，顯示 $bar 的實例:

Bar {#272}

也就是說，我們不需要先對其進行實例！如果學過 PHP 的面向對象，都知道，正常做法是這樣:

class Bar {}
$bar = new Bar();
dd($bar);

實例 2

可以看一個稍微復雜的例子：

class Baz {}
class Bar 
{
    public $baz;

    public function __construct(Baz $baz)
    {
        $this->baz = $baz;
    }
    
}
$baz = new Baz();
$bar = new Bar($baz);
dd($bar);

為了在 Bar 中能夠使用 Baz 的功能，我們需要實例化一個 Baz，然后在實例化 Bar 的時候傳入 Baz 實例。

在 Laravel 中，不僅僅可以自動注入 Bar，也可以自動注入 Baz:

/routes/web.php
class Baz {}
class Bar 
{
    public $baz;

    public function __construct(Baz $baz)
    {
        $this->baz = $baz;
    }
    
}

Route::get("bar", function(Bar $bar) {
       dd($bar->baz);
});

顯示結果:

Baz {#276}

小結

通過上述兩個例子，可以看出，在 Laravel 中，我們要在類或者函數中使用其他類體用的服務，只需要通過類型提示的方式傳遞參數，而 Laravel 會自動幫我們去尋找響對應的依賴。

那么，Laravel 是如何完成這項工作的呢？答案就是通過服務容器。

服務容器 什么是服務容器

服務容器，很好理解，就是裝著各種服務實例的特殊類。可以通過「去餐館吃飯」來進行類比：

吃飯 - 使用服務，即調用該服務的地方

飯 - 服務

盤子 - 裝飯的容器，即服務容器

服務員 - 服務提供者，負責裝飯、上飯

這個過程在 Laravel 中如何實現呢？

飯

定義 Rice 類：

/app/Rice.php

把飯裝盤子

在容器中定義了名為 rice 的變量（你也可以起其他名字，比如 rice_container），綁定了 Food 的實例：
app()->bind("rice", function (){
    return new AppRice();
});
也可以寫成:
app()->bind("rice",AppRice::class);
現在，吃飯了，通過 make 方法提供吃飯的服務：
Route::get("eat", function() {
       
       return app()->make("rice")->food(); 
       // 或者 return resolve("rice")->food()；

});
make 方法傳入我們剛才定義的變量名即可調用該服務。
訪問 /eat，返回 香噴噴的白米飯。
為了方便起見，我們在路由文件中直接實現了該過程，相當于自給自足。但是服務通常由服務提供者來管理的。
因此，我們可以讓 AppServiceProvider 這個服務員來管理該服務：
/app/Providers/AppServiceProvider.php
namespace AppProviders;

public function register()
{
    $this->app->bind("food_container",Rice::class);
}
更為常見的是，我們自己創建一個服務員：
$ php artisan make:provider RiceServiceProvider
注冊:
/app/Providers/RiceServiceProvider.php
app->bind("rice",Rice::class);
}
這里定義了 register() 方法，但是還需要調用該方法才能真正綁定服務到容器，因此，需要將其添加到 providers 數組中：
/config/app.php
"providers" => [
   AppProvidersRiceServiceProvider::class,
],
這一步有何作用呢？Laravel 在啟動的時候會訪問該文件，然后調用里面的所有服務提供者的 register() 方法，這樣我們的服務就被綁定到容器中了。
小結
通過上述的例子，基本上可以理解服務容器和服務提供者的使用。當然了，我們更為常見的還是使用類型提示來傳遞參數：
use AppRice;

Route::get("eat", function(Rice $rice) {
       return $rice->food();

});
在本例中，使用自動依賴注入即可。不需要在用 bind 來手動綁定以及 make 來調用服務。那么，為什么還需要 bind 和 make 呢？ make 比較好理解，我們有一些場合 Laravel 不能提供自動解析，那么這時候手動使用 make 解析就可以了，而 bind 的學問就稍微大了點，后面將會詳細說明。
門面
門面是什么，我們回到剛才的「吃飯」的例子:
Route::get("eat", function(Rice $rice) {
       return $rice->food();

});
在 Laravel，通常還可以這么寫:
Route::get("eat", function() {
       return Rice::food();
});
或者
Route::get("eat", function() {
       return rice()->food();
});
那么，Laravel 是如何實現的呢？答案是通過門面。
門面方法實現
先來實現 Rice::food()，只需要一步：
/app/RiceFacade.php

現在，RiceFacade 就代理了 Rice 類了，這就是門面的本質了。我們就可以直接使用：
Route::get("eat", function() {

    dd(AppRiceFacade::food());

});
因為 AppRiceFacade 比較冗長，我們可以用 php 提供的 class_alias 方法起個別名吧：
/app/Providers/RiceServiceProvider.php
public function register()
{  
   $this->app->bind("rice",AppRice::class);
   class_alias(AppRiceFacade::class, "Rice");
}
這樣做的話，就實現了一開始的用法：
Route::get("eat", function() {
       return Rice::food();
});
看上去就好像直接調用了 Rice 類，實際上，調用的是 RiceFacade 類來代理，因此，個人覺得Facade 翻譯成假象比較合適。
最后，為了便于給代理類命名，Laravel 提供了統一命名別名的地方：
/config/app.php

"aliases" => [

    "Rice" => AppRiceFacade::class,

],
門面實現過程分析
首先：
Rice::food();
因為 Rice 是別名，所以實際上執行的是:
AppRiceFacade::food()
但是我們的 RiceFacade 類里面并沒有定義靜態方法 food 啊？怎么辦呢？直接拋出異常嗎？不是，在 PHP 里，如果訪問了不可訪問的靜態方法，會先調用 __callstatic,所以執行的是:
AppRiceFacade::__callStatic()
雖然我們在 RiceFacade 中沒有定義，但是它的父類 Facade 已經定義好了：
/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php
public static function __callStatic($method, $args)
{   
     
     // 實例化  Rice {#270}
    $instance = static::getFacadeRoot();
    
     // 實例化失敗，拋出異常
    if (! $instance) {
        throw new RuntimeException("A facade root has not been set.");
    }
    
     // 調用該實例的方法
    return $instance->$method(...$args);
}
主要工作就是第一步實例化:
public static function getFacadeRoot()
{
    return static::resolveFacadeInstance(static::getFacadeAccessor());
    // 本例中：static::resolveFacadeInstance("rice")
}
進一步查看 resolveFacadeInstance() 方法：
 protected static function resolveFacadeInstance($name)
    {   
          // rice 是字符串，因此跳過該步驟
        if (is_object($name)) {
            return $name;
        }
         
         // 是否設置了 `rice` 實例
        if (isset(static::$resolvedInstance[$name])) {
            return static::$resolvedInstance[$name];
        }
         
        return static::$resolvedInstance[$name] = static::$app[$name];
    }
第一步比較好理解，如果我們之前在 RiceFacade 這樣寫：
protected static function getFacadeAccessor()
{

    return new AppRice;

}
那么就直接返回 Rice 實例了，這也是一種實現方式。
主要難點在于最后這行：
return static::$resolvedInstance[$name] = static::$app[$name];
看上去像是在訪問 $app數組，實際上是使用 數組方式來訪問對象，PHP 提供了這種訪問方式接口，而 Laravel 實現了該接口。
也就是說，$app 屬性其實就是對 Laravel 容器的引用，因此這里實際上就是訪問容器上名為 rice 的對象。而我們之前學習容器的時候，已經將 rice 綁定了 Rice 類：
public function register()
{  
   $this->app->bind("rice",AppRice::class);
   // class_alias(AppRiceFacade::class, "Rice");
}
所以，其實就是返回該類的實例了。懂得了服務容器和服務提供者，理解門面也就不難了。
輔助方法實現
輔助方法的實現，更簡單了。不就是把 app->make("rice") 封裝起來嘛：
/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php
if (! function_exists("rice")) {
  
    function rice()
    {   
        return app()->make("rice");
        // 等價于 return app("rice");
        // 等價于 return app()["rice"];
    }
} 
然后我們就可以使用了:
Route::get("eat", function() {

    dd(rice()->food());
});
小結
Laravel 提供的三種訪問類的方式：

依賴注入：通過類型提示的方式實現自動依賴注入

門面：通過代理來訪問類

輔助方法：通過方法的方式來訪問類


本質上，這三種方式都是借助于服務容器和服務提供者來實現。那么，服務容器本身有什么好處呢？我們接下來著重介紹下。
IOC
不好的實現
我們來看另外一個例子（為了方便測試，該例子都寫在路由文件中），假設有三種類型的插座：USB、雙孔、三孔插座，分別提供插入充電的服務：
class UsbsocketService
{
    public function insert($deviceName){
        return $deviceName." 正在插入 USB 充電";
    }
}

class DoubleSocketService
{
    public function insert($deviceName){
        return $deviceName." 正在插入雙孔插座充電";
    }
}

class ThreeSocketService
{
    public function insert($deviceName){
        return $deviceName." 正在插入三孔插座充電";
    }
}
設備要使用插座的服務來充電：
class Device {

    protected $socketType; // 插座類型
    public function __construct()
    {
        $this->socketType = new UsbSocketService();
    }

    public function power($deviceName)
    {    
        return $this->socketType->insert($deviceName);
    }
}
現在有一臺手機要進行充電:
Route::get("/charge",function(){
       
   $device = new Device();
   return $device->power("手機");
    
});
因為 Laravel 提供了自動依賴注入功能，因此可以寫成：
Route::get("/charge/{device}",function(Device $device){
       
   return $device->power("手機");
    
});
訪問 /charge/phone，頁面顯示 phone 正在插入 USB 充電。
假如，現在有一臺電腦要充電，用的是三孔插座，那么我們就需要去修改 Device 類:
$this->socketType = new ThreeSocketService();
這真是糟糕的設計，設備類對插座服務類產生了依賴。更換設備類型時，經常就要去修改類的內部結構。
好的實現
為了解決上面的問題，可以參考「IOC」思路：即將依賴轉移到外部。來看看具體怎么做。
首先定義插座類型接口：
interface SocketType {
    public function insert($deviceName);
}
讓每一種插座都實現該接口：
class UsbsocketService implements SocketType
{
    public function insert($deviceName){
        return $deviceName." 正在插入 USB 充電";
    }
}

class DoubleSocketService implements SocketType
{
    public function insert($deviceName){
        return $deviceName." 正在插入雙孔插座充電";
    }
}

class ThreeSocketService implements SocketType
{
    public function insert($deviceName){
        return $deviceName." 正在插入三孔插座充電";
    }
}
最后，設備中傳入接口類型而非具體的類：
class Device {

    protected $socketType; // 插座類型
    public function __construct(SocketType $socketType) // 傳入接口
    {
        $this->socketType = $socketType;
    }

    public function power($deviceName)
    {    
        return $this->socketType->insert($deviceName);
    }
}
實例化的時候再決定使用哪種插座類型，這樣依賴就轉移到了外部：
Route::get("/charge",function(){
   
   $socketType = new ThreeSocketService();
   $device = new Device($socketType);
   echo $device->power("電腦");    
});
我們現在可以再不修改類結構的情況下，方便的更換插座來滿足不同設備的充電需求:
Route::get("/charge",function(){
   
   $socketType = new DoubleSocketService();
   $device = new Device($socketType);
   echo $device->power("臺燈");    
});
自動依賴注入的失效
上面舉的例子，我們通過 Laravel 的自動依賴注入可以進一步簡化：
Route::get("/charge",function(Device $device){ 
       echo $device->power("電腦");
});
這里的類型提示有兩個，一個是 Device $device，一個是 Device 類內部構造函數傳入的 SocketType $sockType。第一個沒有問題，之前也試過。但是第二個 SocketType 是接口，而 Laravel 會將其當成類試圖去匹配 SocketType 的類并將其實例化，因此訪問 /charge 時候就會報錯:
Target [SocketType] is not instantiable while building [Device].
錯誤原因很明顯，Laravel 沒法自動綁定接口。因此，我們就需要之前的 bind 方法來手動綁定接口啦：
app()->bind("SocketType",ThreeSocketService::class);
Route::get("/charge",function(Device $device){
       
       echo $device->power("電腦");
    
});
現在，如果要更換設備，我們只需要改變綁定的值就可以了:
app()->bind("SocketType",DoubleSocketService::class);
Route::get("/charge",function(Device $device){
       
       echo $device->power("臺燈");
    
});
也就是說，我們將依賴轉移到了外部之后，進一步由第三方容器來管理，這就是 IOC。
契約
契約，不是什么新奇的概念。其實就是上一個例子中，我們定義的接口:
interface SocketType {
    public function insert($deviceName);
}
通過契約，我們就可以保持松耦合了:
public function __construct(SocketType $socketType) // 傳入接口而非具體的插座類型
{
    $this->socketType = $socketType;
}
然后服務容器再根據需要去綁定哪種服務即可:
app()->bind("SocketType",UsbSocketService::class);
app()->bind("SocketType",DoubleSocketService::class);
app()->bind("SocketType",ThreeSocketService::class);
Laravel 5.4 入門系列告一段落，接下來準備學習 Vue :)

參考資料：

Patrick Stephan :: A Simple Look At The Laravel Service Container

Unraveling Laravel Facades – Alan Storm

2.7. 外觀模式 — DesignPatternsPHP 1.0 文檔

簡單理解laravel框架中的服務容器，服務提供者以及怎樣調用服務 - xiake2014的博客 - 博客頻道 - CSDN.NET

laravel 學習筆記 —— 神奇的服務容器 - 靈感 - 來自生活的饋贈

Laravel 的請求生命周期 | Laravel 5.4 中文文檔

PHP: 重載 - Manual

PHP: 數組式訪問 - Manual

GPU云服務器云服務器 -laravel laravel laravel cdn php laravel

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/22846.html

入門級解讀：小白也能看懂的TensorFlow介紹

摘要：成本函數成本對于線性回歸，成本函數是表示每個預測值與其預期結果之間的聚合差異的某些函數對于邏輯回歸，是計算每次預測的正確或錯誤的某些函數。成本函數的變換涉及到預測結果和實際結果之間數值距離的任何函數都不能作為成本函數。矩陣和多特征線性回歸快速回顧之前文章的前提是：給定特征——任何房屋面積（sqm），我們需要預測結果，也就是對應房價（$）。為了做到這一點，我們：我們找到一條「最擬合」所有數據...

felix0913 2019-04-25 18:08 評論0 收藏0
最適合入門的 Laravel 初級教程 (一)

摘要：最適合入門的初級教程一為什么選擇曾經要跟白頭到老沒想到它升了個級就拋了錨把我等拋棄了痛定思痛重新審視了一遍框架是世界上最好的語言這個沒有疑問吧如果有那絕對是個異教徒這是要被拖出去燒死的信仰的問題神圣不可侵犯那最好的語言中最流行的框架是哪個呢最適合入門的 Laravel 初級教程 (一) 為什么選擇 laravel 曾經要跟 thinkphp 白頭到老；沒想到它升了個級就拋了錨；把我等...

klivitamJ 2019-06-28 14:39 評論0 收藏0
Laravel 教程 - 實戰 iBrand 開源電商 API 系統

摘要：最佳實踐良好的編碼規范單元測試持續集成文檔，從一開始就形成良好的編碼習慣。真實的電商業務所有的業務需求來自真實的客戶，并且線上良好運營中。重要通知： Laravel + 小程序的開源電商版本源碼已經在 github 上拉，歡迎提交 issue 和 star :) 開源電商 Server 端: Laravel API源碼開源電商 client 端：小程序源碼 iBrand 簡介...

iOS122 2019-06-28 18:26 評論0 收藏0
【C++從0到1】新手都能看懂的C++入門（上篇），建議收藏

摘要：上面這三種均不造成重載，現在來說明原因。結論對于引用返回，返回的對象必須是棧幀銷毀后還存在的。全局，靜態，未銷毀的函數棧幀當中的都是可以的指針與引用如圖兩者底層實現差不多，引用是用指針模擬的。不建議聲明和定義分離，分離會導致鏈接錯誤。 ...

xcold 2021-09-29 09:35 評論0 收藏0
終于有一篇小白能看懂的智能指針詳解了！

摘要：在我以為我和緣分尚淺的時候，搬來救兵，智能指針橫空出世，打敗了內存泄漏，拯救了我們的關系。智能指針引入了智能指針的概念，使用了引用計數的想法，讓程序員不再需要關心手動釋放內存。它還增加了一個成員函數用于交換兩個智能指針的值。 ...

includecmath 2021-09-07 09:59 評論0 收藏0