##5.3.1 術語表
我們并不想“制造”一些新的術語來增加大家的學習成本,但為了更高效地進行專業交流,我們將PhalApi框架中所用到的一些概念進行提煉并羅列如下。
###(1)接口服務
通常,我們把遠程第三方提供的接口稱為API。但秉承Web Service的概念,我們更愿稱接口為服務。為了同時保留這兩者的意思,我們在這里統一將API稱為 **接口服務** 。也就是我們對應的?service=XXX.XXX 。
###(2)資源服務
在使用DI依賴注入進行注冊的組件,我們也傾向稱之為服務,同時也是一些服務端上可用的資源,如數據庫、緩存、加解密等。因此統稱為 **資源服務** 。
##5.3.2 PHP開發建議
在實際項目開發過程中,通過觀察不同開發人員編寫的PHP代碼,會很趣。因為你會發現每個人的編程風格都不盡相同,但我們更提倡約定編程、規范的代碼和編寫人容易理解的代碼。所以,下面就發現的問題進行說明。
###(1)濫用的靜態方法
很多框架和很多項目都說自己在使用面向對象編程,但其實很多時候是在類中全部使用靜態方法的偽面向對象。這里可能會引發爭議,因為有些同學會認為靜態類方法比成員函數更快速,而且也確實有相關的數據表明是快了一點點(嚴格上來講,很微小)。但作為代價,我們失去的更多。如我們沒能使用動態,也不方便在單元測試時使用樁、短件、模擬等技巧。更為重要的是,失去了高層的概念提煉和規約層的約定,不利于接口和實現地分離。
所以,請只有在需要的時候才使用靜態static方法,如工具類或實用操作。
###(2)非真正意義上的單元測試
很多時候,我看到很多框架和項目中沒有單元測試的代碼,就算有也不是真正意義上的單元測試。可測試的代碼是美的,因為可測試的代碼表明職責單一明了,有低耦合度,可以進行快速模擬和替換。關于單元測試,前面已有文檔詳細說明。
所以,請盡量嘗試和堅持PHPUnit單元測試,體驗測試驅動開發的樂趣,體驗浮現式設計的激動。
###(3)無處不在的單例模式
很多同學在學習了設計模式后,都很想試用一把,所以往往在很多時候是為了“用設計模式”而用設計模式,而不考慮是否合適,是否真的需要。尤其對于單例模式,這種情況更為普遍。
使用單例模式的時機包括有:提高系統性能、全局只能有且只有一個實例否則會導致問題發生、提供一個全局的公共訪問點等。
然而其他很多情況則不需要。例如很多情況,實例為某容器所持有,則只需要在容器內做數量控制即可,不需要被持有的實例再作單例控制。
所以,請只有確切需要使用單例時才使用。
##5.3.3 PhalApi框架的不足
在我們不斷維護、演進PhalApi框架的同時,我們也在使用這個框架進行了很多項目的開發,與此同時也在閱讀各方面的書籍以獲得更深層次的理解。
在這樣實踐、思考、再設計的不斷反饋迭代后,我們看到了PhalApi確實在某方面表現得出色。
但一個負責任的框架,應該也明確指出它的不足。
這里,我們將PhalApi開發中的不足羅列如下,希望為你進行框架設計或者對PhalApi的使用有更好的理解。
###(1)接口結果中msg應該改名為error
我們推薦的接口返回格式為:
```javascript
{
"ret": 200,
"data": {
"code": 0, //對操作碼進行說明
.... //更多結果的說明
"msg": ""
},
"msg": ""
}
```
顯然,上面兩個msg字段,會給開發團隊帶來困惑或混淆。
更好是應該把最外層的msg改成error更為貼切,因為只有錯誤時此字段才有效。
但基于前期的大量文檔說明,此外層的ret、data、msg三個字段已約定。所以,只能從應用層的msg進行重命名,如tips。
###(2)對NotORM中limit操作的錯誤優化
前期,由于沒有深刻留意MySql中OFFSET關鍵字的作用,導致了做了一些不精確的優化。
可注意以下的微妙區別:
```javascript
limit 5 OFFSET 10 #從第10個位置開始,查詢前5個
limit 5, 10 #從第5個位置開始,查詢前10個
```
但重點考慮到如果修復這個之前犯下的錯誤,會對項目升級后有很大的沖動。
可預料的故障有:”升級后,首頁列表無任何數據顯示“和“升級后,列表數據過多導致App加載崩潰”。
最后,出于對已在開發或已上線項目的保護和承諾向前兼容的原則,我們不得不保留了這個污點。
所以,當對底層進行改動時,須確保已透徹理解各操作的微妙區別。
###(3)對數據庫操作封裝的欠缺
一直以來,數據庫支持這塊都是比較欠缺的。所以我們使用了NotORM。
但我們為了能更好把NotORM與PhalApi整合,將它調整成更適合我們的使用方式,我們又為NotORM提供了一個封裝層,類似代理。
然而,這會為新手入門這個框架造成一定的迷惑。
因為,這有兩套操作數據庫的區別。但他們一開始不能很好地理解這樣的區別,以及這樣設計的初衷。
坦白來說,PhalApi對于數據庫這塊不是好的設計,但好在它可以使用并正常地工作。
- 歡迎使用PhalApi!
- 接口,從簡單開始!
- [1.1]-下載與安裝
- [1.2]-創建一個自己的項目
- [1.3]-在線體驗
- [1.4]-文檔、幫助和官網
- [1.10]-對PhalApi框架的抉擇
- [1.11]-快速入門(backup)
- [1.12]-參數規則:接口參數規則配置
- [1.13]-統一的接口請求方式:_sevice=XXX.XXX
- [1.14]-統一的返回格式和結構:ret-data-msg
- [1.15]-數據庫操作:基于NotORM的使用及優化
- [1.16]-配置讀取:內外網環境配置的完美切換
- [1.17]-日記紀錄:簡化版的日記接口
- [1.18]-快速函數:人性化的關懷
- [1.19]-DI服務速查:各資源服務一覽表
- [1.20]-DB操作:數據庫基本操作速查
- [1.21]-類的自動加載:遵循PEAR包的命名規范
- [1.22]-簽名驗證:自定義簽名規則
- [1.23]-請求和響應:GET和POST兩者皆可得及超越JSON格式返回
- [1.24]-緩存策略:更靈活地可配置化的多級緩存
- [1.25]-國際化翻譯:為走向國際化提前做好翻譯準備
- [1.26]-數據安全:數據對稱加密方案
- [1.27]-精益開發:更富表現力的Model層和重量級數據獲取的應對方案
- [1.28]-COOKIE:對COOKIE原生態的支持及記憶加密升級版
- [1.29]-開放與封閉:多入口和統一初始化
- [1.30]-保持的力量:接口開發最佳實踐
- [1.31]-新型計劃任務:以接口形式實現的計劃任務
- [2.11]-核心思想:DI依賴注入-讓資源更可控
- [2.12]-海量數據:可配置的分庫分表
- [2.13]-接口調試:在線SQL語句查看與性能優化
- [2.14]-測試驅動開發:意圖導向編程下的接口開發
- [2.15]-演進:新型計劃任務續篇
- [2.16]-領域驅動設計:應對復雜領域業務的Domain層
- [2.17]-微服務:Api接口服務層
- [2.18]-定制化:資源服務的再實現
- [2.19]-擴展庫:可重用的擴展類庫
- [2.20]-約定編程:架構明顯的編程風格
- [2.21]-服務器統一部署方案簡明版:CentOs---Nginx---php-fpm---MySql-[--Memcached]
- [2.22]-更多工具:精益項目和團隊建設
- [3.1]-擴展類庫:微信開發
- [3.2]-擴展類庫:代理模式下phprpc協議的輕松支持
- [3.3]-擴展類庫:基于PHPMailer的郵件發送
- [3.4]-擴展類庫:優酷開放平臺接口調用
- [3.5]-擴展類庫:七牛云存儲接口調用
- [3.6]-擴展類庫:新型計劃任務
- [3.8]-擴展類庫:用戶、會話和第三方登錄集成
- [3.9]-擴展類庫:swoole支持下的長鏈接和異步任務實現
- [3.11]-擴展類庫:基于FastRoute的快速路由
- [4.2]-開發實戰2:模擬優酷開放平臺接口項目開發
- [4.3]-開發實戰3:一個簡單的小型項目開發(奔跑吧兄弟投票活動)
- [5.1]-架構與思想:PhalApi核心設計和思想解讀
- [5.2]-雜談:扯一些PhalApi的前世和今生
- [5.3]-框架總結:術語表和PHP開發建議
- [5.4]-許可
- [5.5]-聯系和加入我們
- [5.6]-更新日記
- [5.8]-致框架貢獻者:加入PhalApi開源指南
- [6.1]-基于接口查詢語言的SDK包
- [6.2]-SDK包(JAVA版)
- [6.3]-SDK包(PHP版)
- [6.4]-SDK包(Objective-C版)
- [6.5]-SDK包(javascript版)
- [6.6]-SDK包(Ruby版)
- [8.1]-PhalApi視頻教程
- 附錄1:接口文檔參考模板