本篇文章給大家帶來的內容是關于Laravel服務容器的系結與決議,有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助,
前言
? 老實說,第一次老大讓我看laravel框架手冊的那天早上,我是很絕望的,因為真的沒接觸過,對我這種渣渣來說,laravel的入門門檻確實有點高了,但還是得硬著頭皮看下去(雖然到現在我還有很多沒看懂,也沒用過),
? 后面慢慢根據公司專案的代碼對laravel也慢慢熟悉起來了,但還是停留在一些表面的功能,例如依賴注入,ORM操作,用戶認證這些和我專案業務邏輯相關的操作,然后對于一些架構基礎的,例如服務提供器,服務容器,中間件,Redis等這些一開始就要設定好的東西,我倒是沒實際操作過(因為老大一開始就做好了),所以看手冊還是有點懵,
? 所以有空的時候逛逛論壇,搜下Google就發現許多關于laravel核心架構的介紹,以及如何使用的網站(確實看完后再去看手冊就好理解多了),下面就根據一個我覺得不錯的網站上面的教學來記錄一下laravel核心架構的學習
網站地址:https://laraweb.net/ 這是一個日本的網站,我覺得挺適合新手的,內容用瀏覽器翻譯過來就ok了,畢竟日文直翻過來很好理解的
關于服務容器
? 手冊上是這樣介紹的:Laravel 服務容器是用于管理類的依賴和執行依賴注入的工具,依賴注入這個花俏名詞實質上是指:類的依賴項通過建構式,或者某些情況下通過「setter」方法「注入」到類中,,,,,,(真的看不懂啥意思)
? 服務容器是用于管理類(服務)的實體化的機制,直接看看服務容器怎么用
? 1.在服務容器中注冊類(bind)
|
1 2 |
|
? 2.從服務容器生成類(make)
|
1 2 3 |
|
? 這是服務容器最簡單的使用,下面是對服務容器的詳細介紹
laravel容器基本認識
? 一開始,index.php 檔案加載 Composer 生成定義的自動加載器,然后從 bootstrap/app.php 腳本中檢索 Laravel 應用程式的實體,Laravel 本身采取的第一個動作是創建一個 application/ service container 的實體,
|
1 2 3 |
|
? 這個檔案在每一次請求到達laravel框架都會執行,所創建的$app即是laravel框架的應用程式實體,它在整個請求生命周期都是唯一的,laravel提供了很多服務,包括認證,資料庫,快取,訊息佇列等等,$app作為一個容器管理工具,負責幾乎所有服務組件的實體化以及實體的生命周期管理,當需要一個服務類來完成某個功能的時候,僅需要通過容器決議出該型別的一個實體即可,從最終的使用方式來看,laravel容器對服務實體的管理主要包括以下幾個方面:
-
服務的系結與決議
-
服務提供者的管理
-
別名的作用
-
依賴注入
先了解如何在代碼中獲取到容器實體,再學習上面四個關鍵
如何在代碼中獲取到容器實體
第一種是
|
1 2 3 4 |
|
第二種是
|
1 2 3 4 5 6 7 |
|
第三種是
? 在服務提供者里面直接使用$this->app,服務提供者后面還會介紹,現在只是引入,因為服務提供者類都是由laravel容器實體化的,這些類都繼承自Illuminate\Support\ServiceProvider,它定義了一個實體屬性$app:
|
1 2 3 |
|
? laravel在實體化服務提供者的時候,會把laravel容器實體注入到這個$app上面,所以我們在服務提供者里面,始終能通過$this->$app訪問到laravel容器實體,而不需要再使用app()函式或者App Facade了,



鏈接:https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取碼:x2p5
免費分享,但是X度限制嚴重,如若鏈接失效點擊鏈接或搜索加群 群號518475424,
如何理解服務系結與決議
? 淺義層面理解,容器既然用來存盤物件,那么就要有一個物件存入跟物件取出的程序,這個物件存入跟物件取出的程序在laravel里面稱為服務的系結與決議,
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
? 還有一個單例系結singleton,是bind的一種特殊情況(第三個引數為true),系結到容器的物件只會被決議一次,之后的呼叫都回傳相同的實體
|
1 2 3 4 |
|
? 在系結的時候,我們可以直接系結已經初始化好的資料(基本型別、陣列、物件實體),還可以用匿名函式來系結,用匿名函式的好處在于,這個服務系結到容器以后,并不會立即產生服務最終的物件,只有在這個服務決議的時候,匿名函式才會執行,此時才會產生這個服務對應的服務實體,
? 實際上,當我們使用singleton,bind方法以及陣列形式,(這三個方法是后面要介紹的系結的方法),進行服務系結的時候,如果系結的服務形式,不是一個匿名函式,也會在laravel內部用一個匿名函式包裝起來,這樣的話, 不輪系結什么內容,都能做到前面介紹的懶初始化的功能,這對于容器的性能是有好處的,這個可以從bind的原始碼中看到一些細節:
|
1 2 3 |
|
看看bind的底層代碼
|
1 |
|
? 第一個引數服務系結名稱,第二個引數服務系結的結果(也就是閉包,得到實體),第三個引數就表示這個服務是否在多次決議的時候,始侄訓傳第一次決議出的實體(也就是單例系結singleton),
? 服務系結還可以通過陣列的方式:
|
1 2 3 |
|
系結大概就這些,接下來看決議,也就是取出來用
|
1 |
|
? 這個方法接收兩個引數,第一個是服務的系結名稱和服務系結名稱的別名,如果是別名,那么就會根據服務系結名稱的別名配置,找到最終的服務系結名稱,然后進行決議;第二個引數是一個陣列,最侄訓傳遞給服務系結產生的閉包,
看原始碼:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
|
第一步:
|
1 2 3 |
|
? 該方法主要是區分,決議的物件是否有引數,如果有引數,還需要對引數做進一步的分析,因為傳入的引數,也可能是依賴注入的,所以還需要對傳入的引數進行決議;這個后面再分析,
第二步:
|
1 2 3 |
|
? 如果是系結的單例,并且不需要上面的引數依賴,我們就可以直接回傳 $this->instances[$abstract],
第三步:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
? 這一步主要是先從系結的背景關系找,是不是可以找到系結類;如果沒有,則再從 $bindings[] 中找關聯的實作類;最后還沒有找到的話,就直接回傳 $abstract 本身,
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
? 如果之前找到的 $concrete 回傳的是 $abstract 值,或者 $concrete 是個閉包,則執行 $this->build($concrete),否則,表示存在嵌套依賴的情況,則采用遞回的方法執行 $this->make($concrete),直到所有的都決議完為止,
$this->build($concrete)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
|
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/124136.html
標籤:PHP
