微信小程式商城構建全棧應用(有原始碼)---轉載
環境:
- TP 5.07
- 應用專案
- 核心框架
- 下載
- Composer
- git
- 直接下載
- PHP 5.6
- PostMan(Fd)
- phpstorm(減少滑鼠使用率)
- 快速切換檔案 alt + 左右
- ctrl + shift + n 查詢檔案
- 查詢使用過檔案(recent files) alt + r
- ctrl + shift + f(查詢)/r
- alt + 1 快速選中程式碼塊
- 焦點位於檔案目錄,alt + insert
- 主題切換 ctrl + ~
- F12 類檔案跳轉
- ctrl + alt + o 刪除無用空間
- 外掛
- Key promoter
- AceJump模式後(預設是Ctrl+J),再按任一個字元,外掛就會在螢幕中這個字元的所有出現位置都打上標籤,你只要再按一下標籤的字元,就能把游標移到該位置上。
- 單元測試(業務程式碼過長)
- Extend Selection ,預設快捷鍵是Ctrl+W。
XDEBUG(一定要注意配置內容)
不過還是沒有一個靜態ide key
zend_extension = F:\phpStudy\php\php-7.0.12-nts\ext\php_xdebug-2.5.4-7.0-vc14-nts.dll
[xdebug]
xdebug.remote_enable = off
xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = off
xdebug.profiler_output_name = cachegrind.out .%t.%p
xdebug.profiler_output_dir = "F:/phpStudy/php/tmp"
xdebug.show_local_vars=0
xdebug.idekey=PHPStorm
xdebug.remote_enable = On
xdebug.remote_host=localhost
xdebug.remote_port=9001
xdebug.remote_handler=dbgp
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
PATH_INFO URL
多模組與模組名稱空間
app\ 是 TP5應用程式,也就是根的名稱空間
自動建立名稱空間
配置虛擬域名簡化URL路徑
外部Url
public注意隱私性
-
- 虛擬域名
- Apache伺服器重寫
路由模式
- route.php配置
- 動態註冊
Route::rule('路由表示式','路由地址','請求型別','路由引數(陣列)','變數規則(陣列)')
- 1
- 請求型別
- GET
- POST
- DELETE
- PUT
- *
獲取請求引數(3種)
Route::get('hello/:id','simple/Test/hello');
然後在方法中接受引數
?name=wangchunlong
- 1
- 2
- 3
通過Request(不區分HTTP請求型別)
$all = Request::instance()->param();
$all = Request::instance()->get();
$all = Request::instance()->route(); 路徑中的引數
var_dump($all)
- 1
- 2
- 3
- 4
助手函式
獲取所有引數
input('param.')
- 1
- 2
依賴注入
業務需求
搭建架構(重要)
獨立驗證
批量驗證batch()
- 1
驗證器(封裝性更好)
程式架構
REST
英文:Representational State Transfer,又稱具象(表述性)狀態傳輸
一種風格,約束,設計理念
基於資源
https://www.zhihu.com/question/27785028 (回答的很詳細)
REST模式與複雜的SOAP和XML-RPC相比更加簡潔
SOAP
SOAP(Simple Object Access Protocol,即簡單物件訪問協議)是交換資料的一種協議規範,使用在計算機網路Web服務(web service)中,交換帶結構資訊。SOAP為了簡化網頁伺服器(Web Server)從XML資料庫中提取資料時,節省去格式化頁面時間,以及不同應用程式之間按照HTTP通訊協議,遵從XML格式執行資料互換,使其抽象於語言實現、平臺和硬體。
RESTFul API
REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。
使用 RPC 樣式架構構建的基於 SOAP 的 Web 服務成為實現 SOA 最常用的方法。RPC 樣式的 Web 服務客戶端將一個裝滿資料的信封(包括方法和引數資訊)通過 HTTP 傳送到伺服器。伺服器開啟信封並使用傳入引數執行指定的方法。方法的結果打包到一個信封並作為響應發回客戶端。客戶端收到響應並開啟信封。每個物件都有自己獨特的方法以及僅公開一個 URI 的 RPC 樣式 Web 服務,URI 表示單個端點。它忽略 HTTP 的大部分特性且僅支援 POST 方法。
- 通常使用JSON描述資料
- 無狀態
URL定位資源,用HTTP動詞(GET,POST,DELETE,DETC)描述操作。
- HTTP動詞(幕等性,資源安全性)
- POST:建立
- PUT: 更新
- GET:查詢
- DELETE:刪除
- 200 GET查詢成功
- 201 POST建立成功(有可能包涵PUT)
- 202 PUT更新成功(請求傳送,但是伺服器還沒有處理)
- 404 資源沒找到
- 400 引數錯誤
- 401 未授權
- 403 資源禁止
- 500 伺服器未知錯誤(伺服器原因,未知Bug)
模仿
- 外部開發
- 豆瓣API
- GitHub開發者API
- 切勿盲目照搬標準REST
全域性異常處理(AOP)
在執行時,動態地將程式碼切入到類的指定方法、指定位置上的程式設計思想就是面向切面的程式設計。
Exception流程
固有的處理異常的思維模式與流程
- 記錄日誌狀態不要去配置檔案config裡面去寫變數,一般是讀取Config::get().
- 如果要記錄變數(資料狀態),可以使用資料庫或者是Redis,TP5自帶快取,全部變數
- 除錯方法:類名追蹤,檢視繼承關係,F12
- HTTPException和Exception不是繼承關係
資料庫與ORM
- ORM
- 簡化程式碼編寫
- 可以跨資料庫
- 模型和資料訪問層是兩個不同的概念,模型處理業務,Db查詢資料庫,模型建立於Db
- 不要因為模型效能差(慢),放棄模型
- 高階語言都有效能損耗,框架也有,為什麼使用框架?開發週期,效率
- 使用面向物件設計模型
- 模型底層還是資料訪問層,自動,強化
原生sql語句
$result = Db::query('select * from banner_item where banner_id=?',[$id]);
return $result;
- 1
- 2
構造器操作資料庫
- Db資料庫操作入口物件(連線,增刪改查…)
- 工廠模式(根據配置檔案來選擇不同驅動Drivers,進而區分不同資料庫)
- 例項化Collection物件(PDO)
- 惰性連線,使用時才連結
- 查詢Query(隱藏差異性,差異沒有解決,也就是面向物件的封裝性)
- 對CURD的一種封裝(建立、更新、讀取和刪除)
- 鏈式操作
- Builder(四種不同型別)把query封裝語句翻譯成原生sql語句,返回給collection,執行
- 適配不同型別的資料庫
- Drivers(thinkphp-db-connector) -
$result = Db::table('banner_item')->where('banner_id','=',$id)->find(); 返回一維陣列,一條資料裡面所有的屬性
$result = Db::table('banner_item')->where('banner_id','=',$id)->select(); 返回二維陣列
- 1
- 2
閉包
$result = Db::table('banner_item')
->where(function($query) ues ($id){
$query->where('banner_id','=',$id)
})->select();
- 1
- 2
- 3
- 4
- 5
- 6
- table和where操作返回的只是query物件,輔助方法,鏈式方法。
- find,select,update,delete,insert才會執行sql語句
- 非鏈式呼叫方法直到執行sql語句才會自動回收,清除狀態
- where(欄位名,表示式(不區分大小寫,預設值=),查詢條件),where寫法:表示式,陣列法(不靈活,略),閉包
- fetchSql() 返回sql語句,也就是查詢構造器最終生成的sql程式碼
- 開啟sql日誌,確定開啟debug和sqldebug,然後在log級別中新增sql字串。前提是type:file,全域性
使用模型和關聯模型操作資料庫ORM(object relation mapping物件關係對映,一個表就是一個物件)
表與表不再是外來鍵的關係,而是物件與物件之間的作用關係
模型:資料查詢,業務邏輯……..(一個業務,根據功能劃分,不只有一個物件,有可能多個物件)
模型(模型層)不只有一層,可以劃分多層,還有model,service,
Db(資料訪問層)的劣勢就是不能很好的處理業務邏輯
Db是模型的基石
關聯模型->重表
繼承Model
資料庫表名和模型名(檔名)一一對應
如果要自定義的話,需要新增 protected $table = '表名';
- 1
- 2
- 3
自動生成banner模型
php think make:model 應用名api/模組名
- 1
- 2
靜態呼叫(推薦)呼叫簡潔,模型本質
$banner = BannerModel::get($id);
例項物件呼叫
$banner = new BannerModel(); 具體資料記錄
$banner = $banner->get($id);
- 1
- 2
- 3
- 4
- 5
- get 返回一個模型物件,model特有
- find 返回一個模型物件,Db
- all 一組,model特有
- select 一組,Db
開閉原則(對修改關閉、對擴充套件開發)
資料冗餘(數量不可控查詢,多次使用,減少巢狀查詢,減少伺服器壓力)
- 缺點
- 寫入時需要多次寫入
- 更新也要同時修改(資料不一致)
介面粒度與介面分層
- 架構
- 分層(底層粒度小->高層粒度大)
- 基礎層-業務層-頁面層
- 粒度過大,複用性不好
- 粒度過小,客戶端呼叫不方便,呼叫過多HTTP請求
- 請求非同步?資料合併
Token令牌
- 合法性
- 有效性
- 有許可權
- openid 使用者身份的唯一標識,功能,一定
- code 數字碼
- session_key 拿到並且解密資訊
如果直接Post傳遞,令牌A傳遞B使用者Body資訊,令牌A可以修改B的資訊。
hasOne,belongsTo區分 一對一,使用表Model如果包含連線外來鍵,使用belongsTo
下單與支付(最複雜)
客戶端Token驗證
專案原始碼
本文轉載自:https://blog.csdn.net/qq_33936481/article/details/75267295