框架總結(jié)：術語表和PHP開發(fā)建議

5.3.1 術語表

我們并不想“制造”一些新的術語來增加大家的學習成本，但為了更高效地進行專業(yè)交流，我們將PhalApi框架中所用到的一些概念進行提煉并羅列如下。

(1)接口服務

通常，我們把遠程第三方提供的接口稱為API。但秉承Web Service的概念，我們更愿稱接口為服務。為了同時保留這兩者的意思，我們在這里統(tǒng)一將API稱為 接口服務 。也就是我們對應的?service=XXX.XXX 。

(2)資源服務

在使用DI依賴注入進行注冊的組件，我們也傾向稱之為服務，同時也是一些服務端上可用的資源，如數(shù)據(jù)庫、緩存、加解密等。因此統(tǒng)稱為 資源服務 。

5.3.2 PHP開發(fā)建議

在實際項目開發(fā)過程中，通過觀察不同開發(fā)人員編寫的PHP代碼，會很趣。因為你會發(fā)現(xiàn)每個人的編程風格都不盡相同，但我們更提倡約定編程、規(guī)范的代碼和編寫人容易理解的代碼。所以，下面就發(fā)現(xiàn)的問題進行說明。

(1)濫用的靜態(tài)方法

很多框架和很多項目都說自己在使用面向?qū)ο缶幊?，但其實很多時候是在類中全部使用靜態(tài)方法的偽面向?qū)ο?。這里可能會引發(fā)爭議，因為有些同學會認為靜態(tài)類方法比成員函數(shù)更快速，而且也確實有相關的數(shù)據(jù)表明是快了一點點（嚴格上來講，很微?。５鳛榇鷥r，我們失去的更多。如我們沒能使用動態(tài)，也不方便在單元測試時使用樁、短件、模擬等技巧。更為重要的是，失去了高層的概念提煉和規(guī)約層的約定，不利于接口和實現(xiàn)地分離。

所以，請只有在需要的時候才使用靜態(tài)static方法，如工具類或?qū)嵱貌僮鳌?/p>

(2)非真正意義上的單元測試

很多時候，我看到很多框架和項目中沒有單元測試的代碼，就算有也不是真正意義上的單元測試?？蓽y試的代碼是美的，因為可測試的代碼表明職責單一明了，有低耦合度，可以進行快速模擬和替換。關于單元測試，前面已有文檔詳細說明。

所以，請盡量嘗試和堅持PHPUnit單元測試，體驗測試驅(qū)動開發(fā)的樂趣，體驗浮現(xiàn)式設計的激動。

(3)無處不在的單例模式

很多同學在學習了設計模式后，都很想試用一把，所以往往在很多時候是為了“用設計模式”而用設計模式，而不考慮是否合適，是否真的需要。尤其對于單例模式，這種情況更為普遍。

使用單例模式的時機包括有：提高系統(tǒng)性能、全局只能有且只有一個實例否則會導致問題發(fā)生、提供一個全局的公共訪問點等。

然而其他很多情況則不需要。例如很多情況，實例為某容器所持有，則只需要在容器內(nèi)做數(shù)量控制即可，不需要被持有的實例再作單例控制。

所以，請只有確切需要使用單例時才使用。

5.3.3 PhalApi框架的不足

在我們不斷維護、演進PhalApi框架的同時，我們也在使用這個框架進行了很多項目的開發(fā)，與此同時也在閱讀各方面的書籍以獲得更深層次的理解。
在這樣實踐、思考、再設計的不斷反饋迭代后，我們看到了PhalApi確實在某方面表現(xiàn)得出色。

但一個負責任的框架，應該也明確指出它的不足。
這里，我們將PhalApi開發(fā)中的不足羅列如下，希望為你進行框架設計或者對PhalApi的使用有更好的理解。

(1)接口結(jié)果中msg應該改名為error

我們推薦的接口返回格式為：

{
    "ret": 200,
    "data": {
        "code": 0,   //對操作碼進行說明
        ....         //更多結(jié)果的說明
        "msg": ""
    },
    "msg": ""
}

顯然，上面兩個msg字段，會給開發(fā)團隊帶來困惑或混淆。
更好是應該把最外層的msg改成error更為貼切，因為只有錯誤時此字段才有效。

但基于前期的大量文檔說明，此外層的ret、data、msg三個字段已約定。所以，只能從應用層的msg進行重命名，如tips。

(2)對NotORM中l(wèi)imit操作的錯誤優(yōu)化

前期，由于沒有深刻留意MySql中OFFSET關鍵字的作用，導致了做了一些不精確的優(yōu)化。

可注意以下的微妙區(qū)別：

limit 5 OFFSET 10   #從第10個位置開始，查詢前5個

limit 5, 10         #從第5個位置開始，查詢前10個

但重點考慮到如果修復這個之前犯下的錯誤，會對項目升級后有很大的沖動。
可預料的故障有：”升級后，首頁列表無任何數(shù)據(jù)顯示“和“升級后，列表數(shù)據(jù)過多導致App加載崩潰”。

最后，出于對已在開發(fā)或已上線項目的保護和承諾向前兼容的原則，我們不得不保留了這個污點。
所以，當對底層進行改動時，須確保已透徹理解各操作的微妙區(qū)別。

(3)對數(shù)據(jù)庫操作封裝的欠缺

一直以來，數(shù)據(jù)庫支持這塊都是比較欠缺的。所以我們使用了NotORM。

但我們?yōu)榱四芨冒袾otORM與PhalApi整合，將它調(diào)整成更適合我們的使用方式，我們又為NotORM提供了一個封裝層，類似代理。

然而，這會為新手入門這個框架造成一定的迷惑。
因為，這有兩套操作數(shù)據(jù)庫的區(qū)別。但他們一開始不能很好地理解這樣的區(qū)別，以及這樣設計的初衷。

坦白來說，PhalApi對于數(shù)據(jù)庫這塊不是好的設計，但好在它可以使用并正常地工作。