PHP元件化開發

設計思想中有兩種極端：大而全、小而美。

一般我們常用的庫是小而美，用的框架是大而全。從Symfony實現Component式開發開始，框架的元件化逐漸成為趨勢。我們可以任意的組合各種Compoent來形成自己的PHP框架，比如B團隊出的Db及ORM引擎、B團隊出的快取引擎、E團隊出的Route對映引擎、C團隊出的DI、D團隊出的MVC、X團隊的單元測試工具。Composer出現後，提供了高度便捷性，加速了這種趨勢。

Yii這個框架是典型的全棧式框架，常規應用開發所需功能幾乎都揉和到一個專案中。yii2到現在，它的核心實現還是以傳統Web應用場景為重心。但這只是他的形，他的核心思想裡是元件化的，有Component這樣的完善機制，只是沒有拆開成各個子專案而已。

如何將Yii2這樣的專案拆成Component式的子專案呢，你可以自己想想！

程式碼重用據說是OOP思想最想要解決的問題？如果我們寫出的每個功能，抽象的庫、具體的業務模組，都可以實現最大化獨立和重用，似乎是很美好的一件事情，藉助於開源的趨勢，若干年的積累後，只要像搭積木一樣組合一下，就可以完成滿足實際需求的應用系統。

請注意上文中的“搭積木”這個詞，搭積木源自於孩童時的遊戲，不同的積木組合可以拼成各種房子、各種車等，但積木組合出來的都是人所處環境的實物，和應用系統這種存在於計算機世界的事物在目前的認知上是完全不同的體系，搭積木這個詞用在應用開發上，合適嗎？

通常我們的結論是這樣：程式碼可以以庫的形式重用，重複的功能模組式開發和引用，但不同的應用有不同的場景，還是需要以比較“巧妙”的方式去定製的，比如“鉤子”、“行為”、“事件”、“外掛”等。

話再說回來，元件化可以到什麼程度呢？

市面上成功的CMS等系統都通過“外掛”或“擴充套件”，配合“應用市場”建立了比較強大的開發者生態圈，通過“巧妙”的機制實現具體場景的定製化，滿足使用者的需求。

舉個簡單的例子來說，TP的Model是這樣的：

在具體的Model裡如UserModel，覆蓋

// 刪除資料前的回撥方法
    protected function _before_delete($options) {}
    // 刪除成功後的回撥方法
    protected function _after_delete($data,$options) {}

這兩個方法以實現資料刪除前和刪除後觸發的關聯操作，但Yii中，只要繼承Component基類實現的類，都可以使用事件和行為來擴充套件原來的邏輯，而且可從外部來定義，非常靈活。

yii中的用法大致為：

$model = new User;

$model->on(‘before_delete’, $callabe, $data);

TP的控制器中也有鉤子，應該也算是一種實現方式吧。

庫Component化、業務功能以模組化的方式實現，就可以實現擴充套件和定製的無限可能性。