框架總結(jié)：術(shù)語(yǔ)表和PHP開(kāi)發(fā)建議

5.3.1 術(shù)語(yǔ)表

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

(1)接口服務(wù)

通常，我們把遠(yuǎn)程第三方提供的接口稱為API。但秉承Web Service的概念，我們更愿稱接口為服務(wù)。為了同時(shí)保留這兩者的意思，我們?cè)谶@里統(tǒng)一將API稱為 接口服務(wù) 。也就是我們對(duì)應(yīng)的?service=XXX.XXX 。

(2)資源服務(wù)

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

5.3.2 PHP開(kāi)發(fā)建議

在實(shí)際項(xiàng)目開(kāi)發(fā)過(guò)程中，通過(guò)觀察不同開(kāi)發(fā)人員編寫(xiě)的PHP代碼，會(huì)很趣。因?yàn)槟銜?huì)發(fā)現(xiàn)每個(gè)人的編程風(fēng)格都不盡相同，但我們更提倡約定編程、規(guī)范的代碼和編寫(xiě)人容易理解的代碼。所以，下面就發(fā)現(xiàn)的問(wèn)題進(jìn)行說(shuō)明。

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

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

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

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

很多時(shí)候，我看到很多框架和項(xiàng)目中沒(méi)有單元測(cè)試的代碼，就算有也不是真正意義上的單元測(cè)試。可測(cè)試的代碼是美的，因?yàn)榭蓽y(cè)試的代碼表明職責(zé)單一明了，有低耦合度，可以進(jìn)行快速模擬和替換。關(guān)于單元測(cè)試，前面已有文檔詳細(xì)說(shuō)明。

所以，請(qǐng)盡量嘗試和堅(jiān)持PHPUnit單元測(cè)試，體驗(yàn)測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的樂(lè)趣，體驗(yàn)浮現(xiàn)式設(shè)計(jì)的激動(dòng)。

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

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

使用單例模式的時(shí)機(jī)包括有：提高系統(tǒng)性能、全局只能有且只有一個(gè)實(shí)例否則會(huì)導(dǎo)致問(wèn)題發(fā)生、提供一個(gè)全局的公共訪問(wèn)點(diǎn)等。

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

所以，請(qǐng)只有確切需要使用單例時(shí)才使用。

5.3.3 PhalApi框架的不足

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

但一個(gè)負(fù)責(zé)任的框架，應(yīng)該也明確指出它的不足。
這里，我們將PhalApi開(kāi)發(fā)中的不足羅列如下，希望為你進(jìn)行框架設(shè)計(jì)或者對(duì)PhalApi的使用有更好的理解。

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

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

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

顯然，上面兩個(gè)msg字段，會(huì)給開(kāi)發(fā)團(tuán)隊(duì)帶來(lái)困惑或混淆。
更好是應(yīng)該把最外層的msg改成error更為貼切，因?yàn)橹挥绣e(cuò)誤時(shí)此字段才有效。

但基于前期的大量文檔說(shuō)明，此外層的ret、data、msg三個(gè)字段已約定。所以，只能從應(yīng)用層的msg進(jìn)行重命名，如tips。

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

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

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

limit 5 OFFSET 10   #從第10個(gè)位置開(kāi)始，查詢前5個(gè)

limit 5, 10         #從第5個(gè)位置開(kāi)始，查詢前10個(gè)

但重點(diǎn)考慮到如果修復(fù)這個(gè)之前犯下的錯(cuò)誤，會(huì)對(duì)項(xiàng)目升級(jí)后有很大的沖動(dòng)。
可預(yù)料的故障有：”升級(jí)后，首頁(yè)列表無(wú)任何數(shù)據(jù)顯示“和“升級(jí)后，列表數(shù)據(jù)過(guò)多導(dǎo)致App加載崩潰”。

最后，出于對(duì)已在開(kāi)發(fā)或已上線項(xiàng)目的保護(hù)和承諾向前兼容的原則，我們不得不保留了這個(gè)污點(diǎn)。
所以，當(dāng)對(duì)底層進(jìn)行改動(dòng)時(shí)，須確保已透徹理解各操作的微妙區(qū)別。

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

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

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

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

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