程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> 關於PHP編程 >> 通過中看不中用的代碼分析Ioc容器,依賴注入....,中看不中用ioc

通過中看不中用的代碼分析Ioc容器,依賴注入....,中看不中用ioc

編輯:關於PHP編程

通過中看不中用的代碼分析Ioc容器,依賴注入....,中看不中用ioc


/**
 * 通過生產擁有超能力的超人實例 來理解IOC容器
 */

//超能力模組接口
interface SuperModuleInterface{
    public function activate(array $target);
}

//超能力模組
class XPower implements SuperModuleInterface{
    public function activate(array $target){
        //......
    }
}
class UltraBomb implements SuperModuleInterface{
    public function activate(array $target){
        //......
    }
}

//超人類
class Superman{
    protected $module;
 
    public function __construct(SuperModuleInterface $module)
    {
        $this->module = $module;
    }
}

/**
 * 簡陋的IOC容器(超級工廠)
 */
class Container{
    protected $binds;
    protected $instances;
    public function bind($abstract,$concrete){
        if($concrete instanceof Closure){
            $this->binds[$abstract] = $concrete;
        }else{
            $this->instances[$abstract] = $concrete;
        }
    }

    public function make($abstract,$parameters=[]){
        if(isset($this->instances[$abstract])){
            return $this->instances[$abstract];
        }
        array_unshift($parameters,$this);
        return call_user_func_array($this->binds[$abstract],$parameters);
    }
}

//超級工廠生產腳本
$container = new Container();
$container->bind('superman',
                 function($container,$moduleName)
                       {
                       return new Superman($container->make($moduleName));
                       }
);
$container->bind('xpower',function($container){ return new XPower; });
$container->bind('ultrabomb',function($container){ return new UltraBomb; });

//生產
$superman_1 = $container->make('superman',['xpower']);
$superman_2 = $container->make('superman',['ultrabomb']);

print_r($superman_1);
print_r($superman_2);



/*
Superman Object
(
    [module:protected] => XPower Object
        (
        )

)
Superman Object
(
    [module:protected] => UltraBomb Object
        (
        )

)
 */

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[原文內容]

IoC 容器, laravel 的核心

Laravel 的核心就是一個 IoC 容器,根據文檔,稱其為“服務容器”,顧名思義,該容器提供了整個框架中需要的一系列服務。作為初學者,很多人會在這一個概念上犯難,因此,我打算從一些基礎的內容開始講解,通過理解面向對象開發中依賴的產生和解決方法,來逐漸揭開“依賴注入”的面紗,逐漸理解這一神奇的設計理念。

本文一大半內容都是通過舉例來讓讀者去理解什麼是 IoC(控制反轉)DI(依賴注入),通過理解這些概念,來更加深入。更多關於 laravel 服務容器的用法建議閱讀文檔即可。

 

IoC 容器誕生的故事

講解 IoC 容器有很多的文章,我之前也寫過。但現在我打算利用當下的靈感重新來過,那麼開始吧。

超人和超能力,依賴的產生!

面向對象編程,有以下幾樣東西無時不刻的接觸:接口還有對象。這其中,接口是類的原型,一個類必須要遵守其實現的接口;對象則是一個類實例化後的產物,我們稱其為一個實例。當然這樣說肯定不利於理解,我們就實際的寫點中看不中用的代碼輔助學習。

怪物橫行的世界,總歸需要點超級人物來擺平。

我們把一個“超人”作為一個類,

  1. class Superman {}

我們可以想象,一個超人誕生的時候肯定擁有至少一個超能力,這個超能力也可以抽象為一個對象,為這個對象定義一個描述他的類吧。一個超能力肯定有多種屬性、(操作)方法,這個盡情的想象,但是目前我們先大致定義一個只有屬性的“超能力”,至於能干啥,我們以後再豐富:

  1. class Power {

  2. /**

  3. * 能力值

  4. */

  5. protected $ability;

  6.  

  7. /**

  8. * 能力范圍或距離

  9. */

  10. protected $range;

  11.  

  12. public function __construct($ability, $range)

  13. {

  14. $this->ability = $ability;

  15. $this->range = $range;

  16. }

  17. }

這時候我們回過頭,修改一下之前的“超人”類,讓一個“超人”創建的時候被賦予一個超能力:

  1. class Superman

  2. {

  3. protected $power;

  4.  

  5. public function __construct()

  6. {

  7. $this->power = new Power(999, 100);

  8. }

  9. }

這樣的話,當我們創建一個“超人”實例的時候,同時也創建了一個“超能力”的實例,但是,我們看到了一點,“超人”和“超能力”之間不可避免的產生了一個依賴。

所謂“依賴”,就是 “我若依賴你,我就不能離開你”。

在一個貫徹面向對象編程的項目中,這樣的依賴隨處可見。少量的依賴並不會有太過直觀的影響,我們隨著這個例子逐漸鋪開,讓大家慢慢意識到,當依賴達到一個量級時,是怎樣一番噩夢般的體驗。當然,我也會自然而然的講述如何解決問題。

一堆亂麻 —— 可怕的依賴

之前的例子中,超能力類實例化後是一個具體的超能力,但是我們知道,超人的超能力是多元化的,每種超能力的方法、屬性都有不小的差異,沒法通過一種類描述完全。我們現在進行修改,我們假設超人可以有以下多種超能力:

  • 飛行,屬性有:飛行速度、持續飛行時間

  • 蠻力,屬性有:力量值

  • 能量彈,屬性有:傷害值、射擊距離、同時射擊個數

我們創建了如下類:

  1. class Flight

  2. {

  3. protected $speed;

  4. protected $holdtime;

  5. public function __construct($speed, $holdtime) {}

  6. }

  7.  

  8. class Force

  9. {

  10. protected $force;

  11. public function __construct($force) {}

  12. }

  13.  

  14. class Shot

  15. {

  16. protected $atk;

  17. protected $range;

  18. protected $limit;

  19. public function __construct($atk, $range, $limit) {}

  20. }

*為了省事兒我沒有詳細寫出 __construct() 這個構造函數的全部,只寫了需要傳遞的參數。

好了,這下我們的超人有點“忙”了。在超人初始化的時候,我們會根據需要來實例化其擁有的超能力嗎,大致如下:

  1. class Superman

  2. {

  3. protected $power;

  4.  

  5. public function __construct()

  6. {

  7. $this->power = new Fight(9, 100);

  8. // $this->power = new Force(45);

  9. // $this->power = new Shot(99, 50, 2);

  10. /*

  11. $this->power = array(

  12. new Force(45),

  13. new Shot(99, 50, 2)

  14. );

  15. */

  16. }

  17. }

我們需要自己手動的在構造函數內(或者其他方法裡)實例化一系列需要的類,這樣並不好。可以想象,假如需求變更(不同的怪物橫行地球),需要更多的有針對性的 新的 超能力,或者需要 變更 超能力的方法,我們必須 重新改造 超人。換句話說就是,改變超能力的同時,我還得重新制造個超人。效率太低了!新超人還沒創造完成世界早已被毀滅。

這時,靈機一動的人想到:為什麼不可以這樣呢?超人的能力可以被隨時更換,只需要添加或者更新一個芯片或者其他裝置啥的(想到鋼鐵俠沒)。這樣的話就不要整個重新來過了。

對,就是這樣的。

我們不應該手動在 “超人” 類中固化了他的 “超能力” 初始化的行為,而轉由外部負責,由外部創造超能力模組、裝置或者芯片等(我們後面統一稱為 “模組”),植入超人體內的某一個接口,這個接口是一個既定的,只要這個 “模組” 滿足這個接口的裝置都可以被超人所利用,可以提升、增加超人的某一種能力。這種由外部負責其依賴需求的行為,我們可以稱其為 “控制反轉(IoC)”。

工廠模式,依賴轉移!

當然,實現控制反轉的方法有幾種。在這之前,不如我們先了解一些好玩的東西。

我們可以想到,組件、工具(或者超人的模組),是一種可被生產的玩意兒,生產的地方當然是 “工廠(Factory)”,於是有人就提出了這樣一種模式: 工廠模式

工廠模式,顧名思義,就是一個類所依賴的外部事物的實例,都可以被一個或多個 “工廠” 創建的這樣一種開發模式,就是 “工廠模式”。

我們為了給超人制造超能力模組,我們創建了一個工廠,它可以制造各種各樣的模組,且僅需要通過一個方法:

  1. class SuperModuleFactory

  2. {

  3. public function makeModule($moduleName, $options)

  4. {

  5. switch ($moduleName) {

  6. case 'Fight': return new Fight($options[0], $options[1]);

  7. case 'Force': return new Force($options[0]);

  8. case 'Shot': return new Shot($options[0], $options[1], $options[2]);

  9. }

  10. }

  11. }

這時候,超人 創建之初就可以使用這個工廠!

  1. class Superman

  2. {

  3. protected $power;

  4.  

  5. public function __construct()

  6. {

  7. // 初始化工廠

  8. $factory = new SuperModuleFactory;

  9.  

  10. // 通過工廠提供的方法制造需要的模塊

  11. $this->power = $factory->makeModule('Fight', [9, 100]);

  12. // $this->power = $factory->makeModule('Force', [45]);

  13. // $this->power = $factory->makeModule('Shot', [99, 50, 2]);

  14. /*

  15. $this->power = array(

  16. $factory->makeModule('Force', [45]),

  17. $factory->makeModule('Shot', [99, 50, 2])

  18. );

  19. */

  20. }

  21. }

可以看得出,我們不再需要在超人初始化之初,去初始化許多第三方類,只需初始化一個工廠類,即可滿足需求。但這樣似乎和以前區別不大,只是沒有那麼多 new 關鍵字。其實我們稍微改造一下這個類,你就明白,工廠類的真正意義和價值了。

  1. class Superman

  2. {

  3. protected $power;

  4.  

  5. public function __construct(array $modules)

  6. {

  7. // 初始化工廠

  8. $factory = new SuperModuleFactory;

  9.  

  10. // 通過工廠提供的方法制造需要的模塊

  11. foreach ($modules as $moduleName => $moduleOptions) {

  12. $this->power[] = $factory->makeModule($moduleName, $moduleOptions);

  13. }

  14. }

  15. }

  16.  

  17. // 創建超人

  18. $superman = new Superman([

  19. 'Fight' => [9, 100],

  20. 'Shot' => [99, 50, 2]

  21. ]);

現在修改的結果令人滿意。現在,“超人” 的創建不再依賴任何一個 “超能力” 的類,我們如若修改了或者增加了新的超能力,只需要針對修改 SuperModuleFactory 即可。擴充超能力的同時不再需要重新編輯超人的類文件,使得我們變得很輕松。但是,這才剛剛開始。

再進一步!IoC 容器的重要組成 —— 依賴注入!

由 “超人” 對 “超能力” 的依賴變成 “超人” 對 “超能力模組工廠” 的依賴後,對付小怪獸們變得更加得心應手。但這也正如你所看到的,依賴並未解除,只是由原來對多個外部的依賴變成了對一個 “工廠” 的依賴。假如工廠出了點麻煩,問題變得就很棘手。

其實大多數情況下,工廠模式已經足夠了。工廠模式的缺點就是:接口未知(即沒有一個很好的契約模型,關於這個我馬上會有解釋)、產生對象類型單一。總之就是,還是不夠靈活。雖然如此,工廠模式依舊十分優秀,並且適用於絕大多數情況。不過我們為了講解後面的 依賴注入 ,這裡就先誇大一下工廠模式的缺陷咯。

我們知道,超人依賴的模組,我們要求有統一的接口,這樣才能和超人身上的注入接口對接,最終起到提升超能力的效果。

事實上,我之前說謊了,不僅僅只有一堆小怪獸,還有更多的大怪獸。嘿嘿。額,這時候似乎工廠的生產能力顯得有些不足 —— 由於工廠模式下,所有的模組都已經在工廠類中安排好了,如果有新的、高級的模組加入,我們必須修改工廠類(好比增加新的生產線):

  1. class SuperModuleFactory

  2. {

  3. public function makeModule($moduleName, $options)

  4. {

  5. switch ($moduleName) {

  6. case 'Fight': return new Fight($options[0], $options[1]);

  7. case 'Force': return new Force($options[0]);

  8. case 'Shot': return new Shot($options[0], $options[1], $options[2]);

  9. // case 'more': .......

  10. // case 'and more': .......

  11. // case 'and more': .......

  12. // case 'oh no! its too many!': .......

  13. }

  14. }

  15. }

看到沒。。。噩夢般的感受!

其實靈感就差一步!你可能會想到更為靈活的辦法!對,下一步就是我們今天的主要配角 —— DI (依賴注入)

由於對超能力模組的需求不斷增大,我們需要集合整個世界的高智商人才,一起解決問題,不應該僅僅只有幾個工廠壟斷負責。不過高智商人才們都非常自負,認為自己的想法是對的,創造出的超能力模組沒有統一的接口,自然而然無法被正常使用。這時我們需要提出一種契約,這樣無論是誰創造出的模組,都符合這樣的接口,自然就可被正常使用。

  1. interface SuperModuleInterface

  2. {

  3. /**

  4. * 超能力激活方法

  5. *

  6. * 任何一個超能力都得有該方法,並擁有一個參數

  7. *@param array $target 針對目標,可以是一個或多個,自己或他人

  8. */

  9. public function activate(array $target);

  10. }

上文中,我們定下了一個接口 (超能力模組的規范、契約),所有被創造的模組必須遵守該規范,才能被生產。

其實,這就是 php 中 接口( interface ) 的用處和意義!很多人覺得,為什麼 php 需要接口這種東西?難道不是 java 、 C# 之類的語言才有的嗎?這麼說,只要是一個正常的面向對象編程語言(雖然 php 可以面向過程),都應該具備這一特性。因為一個 對象(object) 本身是由他的模板或者原型 —— 類 (class) ,經過實例化後產生的一個具體事物,而有時候,實現統一種方法且不同功能(或特性)的時候,會存在很多的類(class),這時候就需要有一個契約,讓大家編寫出可以被隨時替換卻不會產生影響的接口。這種由編程語言本身提出的硬性規范,會增加更多優秀的特性。

雖然有些繞,但通過我們接下來的實例,大家會慢慢領會接口帶來的好處。

這時候,那些提出更好的超能力模組的高智商人才,遵循這個接口,創建了下述(模組)類:

  1. /**

  2. * X-超能量

  3. */

  4. class XPower implements SuperModuleInterface

  5. {

  6. public function activate(array $target)

  7. {

  8. // 這只是個例子。。具體自行腦補

  9. }

  10. }

  11.  

  12. /**

  13. * 終極炸彈 (就這麼俗)

  14. */

  15. class UltraBomb implements SuperModuleInterface

  16. {

  17. public function activate(array $target)

  18. {

  19. // 這只是個例子。。具體自行腦補

  20. }

  21. }

同時,為了防止有些 “磚家” 自作聰明,或者一些叛徒惡意搗蛋,不遵守契約胡亂制造模組,影響超人,我們對超人初始化的方法進行改造:

  1. class Superman

  2. {

  3. protected $module;

  4.  

  5. public function __construct(SuperModuleInterface $module)

  6. {

  7. $this->module = $module

  8. }

  9. }

改造完畢!現在,當我們初始化 “超人” 類的時候,提供的模組實例必須是一個SuperModuleInterface 接口的實現。否則就會提示錯誤。

正是由於超人的創造變得容易,一個超人也就不需要太多的超能力,我們可以創造多個超人,並分別注入需要的超能力模組即可。這樣的話,雖然一個超人只有一個超能力,但超人更容易變多,我們也不怕怪獸啦!

現在有人疑惑了,你要講的 依賴注入 呢?

其實,上面講的內容,正是依賴注入。

什麼叫做 依賴注入

本文從開頭到現在提到的一系列依賴,只要不是由內部生產(比如初始化、構造函數__construct 中通過工廠方法、自行手動 new 的),而是由外部以參數或其他形式注入的,都屬於 依賴注入(DI) 。是不是豁然開朗?事實上,就是這麼簡單。下面就是一個典型的依賴注入:

  1. // 超能力模組

  2. $superModule = new XPower;

  3.  

  4. // 初始化一個超人,並注入一個超能力模組依賴

  5. $superMan = new Superman($superModule);

關於依賴注入這個本文的主要配角,也就這麼多需要講的。理解了依賴注入,我們就可以繼續深入問題。慢慢走近今天的主角……

更為先進的工廠 —— IoC 容器!

剛剛列了一段代碼:

  1. $superModule = new XPower;

  2.  

  3. $superMan = new Superman($superModule);

讀者應該看出來了,手動的創建了一個超能力模組、手動的創建超人並注入了剛剛創建超能力模組。呵呵,手動。

現代社會,應該是高效率的生產,干淨的車間,完美的自動化裝配。

一群怪獸來了,如此低效率產出超人是不現實,我們需要自動化 —— 最多一條指令,千軍萬馬來相見。我們需要一種高級的生產車間,我們只需要向生產車間提交一個腳本,工廠便能夠通過指令自動化生產。這種更為高級的工廠,就是工廠模式的升華 —— IoC 容器

  1. class Container

  2. {

  3. protected $binds;

  4.  

  5. protected $instances;

  6.  

  7. public function bind($abstract, $concrete)

  8. {

  9. if ($concrete instanceof Closure) {

  10. $this->binds[$abstract] = $concrete;

  11. } else {

  12. $this->instances[$abstract] = $concrete;

  13. }

  14. }

  15.  

  16. public function make($abstract, $parameters = [])

  17. {

  18. if (isset($this->instances[$abstract])) {

  19. return $this->instances[$abstract];

  20. }

  21.  

  22. array_unshift($parameters, $this);

  23.  

  24. return call_user_func_array($this->binds[$abstract], $parameters);

  25. }

  26. }

這時候,一個十分粗糙的容器就誕生了。現在的確很簡陋,但不妨礙我們進一步提升他。先著眼現在,看看這個容器如何使用吧!

  1. // 創建一個容器(後面稱作超級工廠)

  2. $container = new Container;

  3.  

  4. // 向該 超級工廠 添加 超人 的生產腳本

  5. $container->bind('superman', function($container, $moduleName) {

  6. return new Superman($container->make($moduleName));

  7. });

  8.  

  9. // 向該 超級工廠 添加 超能力模組 的生產腳本

  10. $container->bind('xpower', function($container) {

  11. return new XPower;

  12. });

  13.  

  14. // 同上

  15. $container->bind('ultrabomb', function($container) {

  16. return new UltraBomb;

  17. });

  18.  

  19. // ****************** 華麗麗的分割線 **********************

  20. // 開始啟動生產

  21. $superman_1 = $container->make('superman', ['xpower']);

  22. $superman_2 = $container->make('superman', ['ultrabomb']);

  23. $superman_3 = $container->make('superman', ['xpower']);

  24. // ...隨意添加

看到沒?通過最初的 綁定(bind) 操作,我們向 超級工廠 注冊了一些生產腳本,這些生產腳本在生產指令下達之時便會執行。發現沒有?我們徹底的解除了 超人 與 超能力模組 的依賴關系,更重要的是,容器類也絲毫沒有和他們產生任何依賴!我們通過注冊、綁定的方式向容器中添加一段可以被執行的回調(可以是匿名函數、非匿名函數、類的方法)作為生產一個類的實例的 腳本 ,只有在真正的 生產(make) 操作被調用執行時,才會觸發。

這樣一種方式,使得我們更容易在創建一個實例的同時解決其依賴關系,並且更加靈活。當有新的需求,只需另外綁定一個“生產腳本”即可。

實際上,真正的 IoC 容器更為高級。我們現在的例子中,還是需要手動提供超人所需要的模組參數,但真正的 IoC 容器會根據類的依賴需求,自動在注冊、綁定的一堆實例中搜尋符合的依賴需求,並自動注入到構造函數參數中去。Laravel 框架的服務容器正是這麼做的。實現這種功能其實理論上並不麻煩,但我並不會在本文中寫出,因為……我懶得寫。

不過我告訴大家,這種自動搜尋依賴需求的功能,是通過 反射(Reflection) 實現的,恰好的,php 完美的支持反射機制!關於反射,php 官方文檔有詳細的資料,並且中文翻譯基本覆蓋,足夠學習和研究!

http://php.net/manual/zh/book.reflection.php

現在,到目前為止,我們已經不再懼怕怪獸們了。高智商人才集思廣益,井井有條,根據接口契約創造規范的超能力模組。超人開始批量產出。最終,人人都是超人,你也可以是哦

回歸正常世界。我們開始重新審視 laravel 的核心。

現在,我們開始慢慢解讀 laravel 的核心。其實,laravel 的核心就是一個 IoC 容器,也恰好是我之前所說的高級的 IoC 容器。

可以說,laravel 的核心本身十分輕量,並沒有什麼很神奇很實質性的應用功能。很多人用到的各種功能模塊比如 Route(路由)Eloquent ORM(數據庫 ORM 組件)Request and Response(請求和響應)等等等等,實際上都是與核心無關的類模塊提供的,這些類從注冊到實例化,最終被你所使用,其實都是 laravel 的服務容器負責的。

我們以大家最常見的 Route 類作為例子。大家可能經常見到路由定義是這樣的:

  1. Route::get('/', function() {

  2. // bla bla bla...

  3. });

實際上, Route 類被定義在這個命名空間:Illuminate\Routing\Router,文件vendor/laravel/framework/src/Illuminate/Routing/Router.php

我們通過打開發現,這個類的這一系列方法,如 getpostany 等都不是靜態(static)方法,這是怎麼一回事兒?不要急,我們繼續。

服務提供者

我們在前文介紹 IoC 容器的部分中,提到了,一個類需要綁定、注冊至容器中,才能被“制造”。

對,一個類要被容器所能夠提取,必須要先注冊至這個容器。既然 laravel 稱這個容器叫做服務容器,那麼我們需要某個服務,就得先注冊、綁定這個服務到容器,那麼提供服務並綁定服務至容器的東西,就是 服務提供者(ServiceProvider)

雖然,綁定一個類到容器不一定非要通過 服務提供者(ServiceProvider)

但是,我們知道,有時候我們的類、模塊會有需要其他類和組件的情況,為了保證初始化階段不會出現所需要的模塊和組件沒有注冊的情況,laravel 將注冊和初始化行為進行拆分,注冊的時候就只能注冊,初始化的時候就是初始化。拆分後的產物就是現在的服務提供者

服務提供者主要分為兩個部分,register(注冊)boot(引導、初始化),具體參考文檔。register 負責進行向容器注冊“腳本”,但要注意注冊部分不要有對未知事物的依賴,如果有,就要移步至 boot 部分。

Facade

我們現在解答之前關於 Route 的方法為何能以靜態方法訪問的問題。實際上這個問題文檔上有寫,簡單說來就是模擬一個類,提供一個靜態魔術方法__callStatic,並將該靜態方法映射到真正的方法上。

我們使用的 Route 類實際上是 Illuminate\Support\Facades\Route 通過 class_alias() 函數創造的 別名 而已,這個類被定義在文件vendor/laravel/framework/src/Illuminate/Support/Facades/Route.php

我們打開文件一看……诶?怎麼只有這麼簡單的一段代碼呢?

  1. <?php namespace Illuminate\Support\Facades;

  2.  

  3. /**

  4. * @see \Illuminate\Routing\Router

  5. */

  6. class Route extends Facade {

  7.  

  8. /**

  9. * Get the registered name of the component.

  10. *

  11. * @return string

  12. */

  13. protected static function getFacadeAccessor()

  14. {

  15. return 'router';

  16. }

  17.  

  18. }

其實仔細看,會發現這個類繼承了一個叫做 Facade 的類,到這裡謎底差不多要解開了。

上述簡單的定義中,我們看到了 getFacadeAccessor 方法返回了一個 route,這是什麼意思呢?事實上,這個值被一個 ServiceProvider 注冊過,大家應該知道注冊了個什麼,當然是那個真正的路由類!

有人會問,Facade 是怎麼實現的。我並不想說得太細,一個是我懶,另一個原因就是,自己發現一些東西更容易理解,並不容易忘記。很多細節我已經說了,建議大家自行去研究。

至此,我們已經講的差不多了。

和平!我們該總結總結了!

無論如何,世界和平了。

這裡要總結的內容就是,其實很多事情並不復雜,怕的是復雜的理論內容。我覺得很多東西一旦想通也就那麼回事兒。很多人覺得 laravel 這不好那不好、這裡難哪裡難,我只能說,laravel 的確不是一流和優秀的框架,說 laravel 是一流、優秀的框架的人,不是 laravel 的粉絲那麼就是跟風炒作。Laravel 最大的特點和優秀之處就是使用了很多 php 比較新(實際上並不新)的概念和技術(也就一堆語法糖)而已。因此 laravel 的確符合一個適宜學習的框架。Laravel 的構思的確和其他框架有很大不同,這也要求學習他的人必須熟練 php,並 基礎扎實!如果你覺得學 laravel 框架十分困難,那麼原因只有一個:你 php 基礎不好。

另外,善於利用命名空間和面向對象的諸多特性,去追尋一些東西,你會發現,原來這一切這麼容易。

 

 

 

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved