APPLET 小程序動態
我們的作品，他們的故事
Our work, their stories
Our work, their stories
微信小程序商城開發構建全棧應用
發布人:龍兵科技
18-07-04
1-1:
AOP編程思想
看書和實際編碼相輔相成。
1-2：
課程技術點：
ThinkPHP5框架，后面三個字母都是大寫， 細節 ：iOS 首字母小寫，Android 首字母大寫。
MySQL
微信
小程序 騰訊官方出的小程序作對比
1-3：
課程流程:
服務端
客戶端 （客戶使用的）
CMS? （產品的管理員使用的）
cms的功能總結：1是基礎數據的增刪改查，2是特殊操作，比如發送微信消息
1-4：
三端分離概念：
以前的網站 CMS和后端是合起來的 ，當時因為移動端還沒有興起，
現在一般情況下cms也是客戶端，不要視為服務端 ，各個端開發。結構清晰。
1-5：
實現通用的 結構良好的產品，
三端分離，
基于REST API,
全稱：REST，全稱是Resource Representational State Transfer，即：資源在網絡中以某種形式進行狀態轉移。
基于token令牌管理權限，分級 （作用域），
一套架構適配iOS,Android,小程序與單頁面，
使用ORM方式與數據庫交互，
用面向對象的方式構建前端 （ES6 ）
1-6：
知識與技術：
web框架核心知識：路由，控制器，模型
驗證器，讀取器，緩存，全局異常處理，
ORM：模型與關聯模型
1-7：
微信技術點：微信小程序開放給個人。自己注冊一個。
微信登錄
微信支付（預訂單，支付與回調通知處理）
微信模板消息（不能主動向客戶推送消息，要在特定情況下才能觸發）
1-8：
數據表設計
數據冗余的合理利用
事務與鎖在檢測庫存量中的應用
1-9:
學習要求：
靜下心來，慢慢學習。
1-10：
前置知識：
php與面向對象相關知識
thinkphp 框架的基礎知識
MYSQL數據庫的基本使用
小程序常用API
有一個小程序賬號
1-11：
泛化的web
web產品矩陣
公共服務（api）
要能寫出易維護的代碼，要讓代碼寫的美~
前端絕不等于做界面和特效，也要處理業務邏輯。
1-12：
依賴或者包管理：composer (新手盡量少用)
TP5已經為我們引入了很多插件，盡量少用到第三方，代碼侵入，不利于編程邏輯的培養。
1-13：
產品代碼會長期維護
知乎專欄：小樓昨夜又秋風
2-1：
環境，開發工具
ThinkPHP 5.07
MySQL
PHP 5.6
Apache/nginx
使用XAMPP(集成安裝包)
phpstrom
web開發者工具（VS Code 編寫前端代碼 更靈活）
Postman
Navicat
2-2：
安裝軟件
2-3：
安裝tp5 ：composer 、git 、官網下載
應用項目
核心框架
2-4：
項目獨立命名
2-5：
phpstrom快捷使用方式：
setting->keymap
alt +r 最近文件 可篩選
alt +左右鍵 切換打開的文件
con+shifr+n 搜索所有文件名字
整段注釋 con+shift+/
alt+e 代碼塊選中
新建文件 焦點放在左邊項目欄 alt+insert
類中不同的方法快速移動 alt+上下箭頭
2-6：
tp5層次結構：
入口文件
應用 包含模塊
模塊包含 mvc
2-7:
tp5自帶web服務器
下方的命令行工具 Terminal
先切換進入public目錄下
命令：php -S localhost:8080 router.php 即可（注意端口號不要與已有的web服務器沖突）
可以在這里操作git
2-8:
phpstrom斷點調試 XDebug
安裝xdebug
配置phpstrom
了解短點調試的幾個按鈕的作用
2-9：
PATH_INFO URL路徑模式：http://servername/index.php/模塊/控制器/方法/參數
url可配置是否區分大小寫
兼容模式：http://servername/index.php?s=模塊/控制器/方法/參數
缺點：太長，會暴露服務器文件結構，不能很好支持url語義化
使用路由解決以上缺點。
3-1：
命名空間：自動在新建類的時候生成，setting->directories 將application定義別名app即可。
3-2：
配置虛擬域名，簡化URL路徑。
首先 配置虛擬主機，
配置虛擬主機的小技巧：使用apache，在虛擬主機配置文件中，先將localhost配置為一個虛擬主機，否則，當你配置一個虛擬主機的時候，訪問localhost就是去訪問你配置的那個虛擬主機的路徑。
3-3：
安裝postman:
將postman的收藏功能用起來，輸入網址很麻煩。
3-4：
三種URL訪問模式：path_info , 混合，強制。
路由：route.php文件中編寫
配置式，
動態注冊，think/route類 rule方法 一旦定義路由 原有的path_info失效。
配置中，可混合，可強制。
3-5：
定義路由：
Route:rule()方法的完整參數使用：（路由表達式，路由地址，請求類型，路由參數，變量規則）
請求類型 缺省 是 *，全部的請求類型。
有簡化的寫法：
Route:get(路由表達式，路由地址) ，方法有get,post,put,delete
3-6:
獲取請求參數：
在路由定義里面/:id
在url里面，?name=xxx,
在post的body體里面，
Request類 實例化 instance,param()所有方法傳過來的參數，get(),post()
當使用get()獲取參數時，只能獲取到?后面的參數，獲取不到路由里面的參數，
就要使用到route()方法。
助手函數，input('param.')
依賴注入：在方法名中index(Request $request) 在方法里面就可以用了。
3-7：
產品功能講解與分析：
項目：零食商販
3-8：
Vavicat安裝以及數據庫初步設計：
傾向于不用外鍵約束，
4-1:
Banner(輪播圖)數據表設計分析：
有兩張圖 banner,banner_item
4-2:
Banner接口
方法：根據id獲取banner
指明路由和方法，
4-3：
validate 獨立驗證
內置規則，可自定義驗證過則。
new Validate(規則)
->batch()
->check(數據)
->getError()
但是這種獨立驗證的封裝性沒有驗證器好，以后大多數情況下都使用驗證器。
4-4：
驗證器
區別 對規則做了更好的封裝
新建validate文件夾 類 屬性 rules 使用：new 驗證類
4-5：
項目結構體系詳解：
客戶端：cms 和小程序 登錄就是獲取令牌的過程 重點
小程序 和微信服務器 以及 我們自己的服務器交互
服務端;校驗參數->controller ->model/service/logic ->核心框架 異常處理
注意：service 和 model層之間的關系 最好能靈活的同級
小程序的緩存
restful api
4-6:
自定義驗證規則：
getBanenrByID
參數 id正整數
自己寫（發生錯誤，新建文件夾的時候，把順序搞混了，導致接口訪問不到！一定要注意）
4-7：
構建接口參數校驗層：
上一節 的 也不夠精簡 復用性不高。
baseValidate基類。
goCheck 獲取參數 做校驗
攔截器 先使用tp5的默認異常
自己寫 沒什么問題
5-1：
REST之前的重要協議:SOAP
soap 重 使用xml描述數據 前端調接口的時候 流程復雜 網站后臺轉發調用
5-2：
restful api 特點解析：
api基于rest理論設計
通常來說 json來描述數據
無狀態 ，每次請求不依賴其他接口
基于資源， 使用Http動詞來操作資源
傳統：區分使用get或者post 是根據參數簡單與否來區分，現在：根據動作來區分
eg:刪除操作使用delete ，新增操作使用post ,獲取操作使用get,更新使用put.
接口名稱的定義 盡量用名詞而不是動詞 。eg:movie/id 而不是：getMovie/id.
5-3:
RESTFul API 最佳實踐：
每次http請求都應該響應一個狀態碼，錯誤碼（自定義 ：有文檔 ，可查找）和 統一描述錯誤
狀態碼：
404 資源沒找到
400 參數錯誤
200 get查詢資源成功
201 post創建資源成功
202 put更新成功了（有些設置為請求未響應）
401 無權限
403 禁止訪問
500 服務器未知錯誤 。
統一錯誤描述信息:錯誤碼，錯誤信息，當前url.
使用token令牌來授權和驗證身份，
傳統web用session和cookie，和token比較，token自己的服務器存儲管理，靈活。
版本控制。
詳細文檔。
5-4：
如何學習RESTFul API。
模仿：豆瓣開放api ，github開發者api
合理使用，切勿盲目照搬標磚REST，因為我們面向的是內部人員
6-1：
正確理解異常處理流程：
類同名的情況下別名，
異常層級關系 ->全局異常處理AOP
6-2：
固有的處理異常的思維方式和流程：
現在有個服務器錯誤，假如1/0,拋出異常 狀態碼 400
6-3：
異常的分類：
兩類：
由于用戶行為導致的異常 ，比如參數輸入錯誤 導致沒有查詢到數據 ，有的返回一個空數組，并不當成異常，有的 返回一個自定義的異常碼。
不需要記錄日志 ，
需要向用戶返回具體的錯誤信息。
第二就是服務器自身異常，記錄日志，不向客戶返回具體原因。
6-4：
實現自定義全局異常處理：
新建exception文件夾，
覆蓋和重寫，
三個類
config 要配置
6-5：
實現已定義全局異常處理 下
render()方法要處理兩種不同的異常，
新建文件記錄錯誤碼
測試兩個異常！
6-6：
日志系統：
先關掉tp5的自動日志記錄 ，太多，
有選擇的記錄日志，
6-7：
在全局異常處理中加入日志記錄，
私有方法，記錄日志，
手動初始化日志，然后記錄日志
6-8：
全局異常處理應用 上：
對于客戶端開發人員 json格式比較好，
對于服務端開發人員 網頁格式比較好
需要一個開關，
還原父類的render()方法，
配置文件，助手函數
完善goCheck()拋出的異常 定義一個新的自定義異常
6-9：
全局異常處理的應用 中：
構造函數 對成員變量操作 可選參數賦值 異常類
6-10：
全局異常處理的應用 下:
驗證器 需要驗證多個參數的時候
batch()方法
6-11：
小結與AOP思想：面向切面
AOP編程思想
看書和實際編碼相輔相成。
1-2：
課程技術點：
ThinkPHP5框架，后面三個字母都是大寫， 細節 ：iOS 首字母小寫，Android 首字母大寫。
MySQL
微信
小程序 騰訊官方出的小程序作對比
1-3：
課程流程:
服務端
客戶端 （客戶使用的）
CMS? （產品的管理員使用的）
cms的功能總結：1是基礎數據的增刪改查，2是特殊操作，比如發送微信消息
1-4：
三端分離概念：
以前的網站 CMS和后端是合起來的 ，當時因為移動端還沒有興起，
現在一般情況下cms也是客戶端，不要視為服務端 ，各個端開發。結構清晰。
1-5：
實現通用的 結構良好的產品，
三端分離，
基于REST API,
全稱：REST，全稱是Resource Representational State Transfer，即：資源在網絡中以某種形式進行狀態轉移。
基于token令牌管理權限，分級 （作用域），
一套架構適配iOS,Android,小程序與單頁面，
使用ORM方式與數據庫交互，
用面向對象的方式構建前端 （ES6 ）
1-6：
知識與技術：
web框架核心知識：路由，控制器，模型
驗證器，讀取器，緩存，全局異常處理，
ORM：模型與關聯模型
1-7：
微信技術點：微信小程序開放給個人。自己注冊一個。
微信登錄
微信支付（預訂單，支付與回調通知處理）
微信模板消息（不能主動向客戶推送消息，要在特定情況下才能觸發）
1-8：
數據表設計
數據冗余的合理利用
事務與鎖在檢測庫存量中的應用
1-9:
學習要求：
靜下心來，慢慢學習。
1-10：
前置知識：
php與面向對象相關知識
thinkphp 框架的基礎知識
MYSQL數據庫的基本使用
小程序常用API
有一個小程序賬號
1-11：
泛化的web
web產品矩陣
公共服務（api）
要能寫出易維護的代碼，要讓代碼寫的美~
前端絕不等于做界面和特效，也要處理業務邏輯。
1-12：
依賴或者包管理：composer (新手盡量少用)
TP5已經為我們引入了很多插件，盡量少用到第三方，代碼侵入，不利于編程邏輯的培養。
1-13：
產品代碼會長期維護
知乎專欄：小樓昨夜又秋風
2-1：
環境，開發工具
ThinkPHP 5.07
MySQL
PHP 5.6
Apache/nginx
使用XAMPP(集成安裝包)
phpstrom
web開發者工具（VS Code 編寫前端代碼 更靈活）
Postman
Navicat
2-2：
安裝軟件
2-3：
安裝tp5 ：composer 、git 、官網下載
應用項目
核心框架
2-4：
項目獨立命名
2-5：
phpstrom快捷使用方式：
setting->keymap
alt +r 最近文件 可篩選
alt +左右鍵 切換打開的文件
con+shifr+n 搜索所有文件名字
整段注釋 con+shift+/
alt+e 代碼塊選中
新建文件 焦點放在左邊項目欄 alt+insert
類中不同的方法快速移動 alt+上下箭頭
2-6：
tp5層次結構：
入口文件
應用 包含模塊
模塊包含 mvc
2-7:
tp5自帶web服務器
下方的命令行工具 Terminal
先切換進入public目錄下
命令：php -S localhost:8080 router.php 即可（注意端口號不要與已有的web服務器沖突）
可以在這里操作git
2-8:
phpstrom斷點調試 XDebug
安裝xdebug
配置phpstrom
了解短點調試的幾個按鈕的作用
2-9：
PATH_INFO URL路徑模式：http://servername/index.php/模塊/控制器/方法/參數
url可配置是否區分大小寫
兼容模式：http://servername/index.php?s=模塊/控制器/方法/參數
缺點：太長，會暴露服務器文件結構，不能很好支持url語義化
使用路由解決以上缺點。
3-1：
命名空間：自動在新建類的時候生成，setting->directories 將application定義別名app即可。
3-2：
配置虛擬域名，簡化URL路徑。
首先 配置虛擬主機，
配置虛擬主機的小技巧：使用apache，在虛擬主機配置文件中，先將localhost配置為一個虛擬主機，否則，當你配置一個虛擬主機的時候，訪問localhost就是去訪問你配置的那個虛擬主機的路徑。
3-3：
安裝postman:
將postman的收藏功能用起來，輸入網址很麻煩。
3-4：
三種URL訪問模式：path_info , 混合，強制。
路由：route.php文件中編寫
配置式，
動態注冊，think/route類 rule方法 一旦定義路由 原有的path_info失效。
配置中，可混合，可強制。
3-5：
定義路由：
Route:rule()方法的完整參數使用：（路由表達式，路由地址，請求類型，路由參數，變量規則）
請求類型 缺省 是 *，全部的請求類型。
有簡化的寫法：
Route:get(路由表達式，路由地址) ，方法有get,post,put,delete
3-6:
獲取請求參數：
在路由定義里面/:id
在url里面，?name=xxx,
在post的body體里面，
Request類 實例化 instance,param()所有方法傳過來的參數，get(),post()
當使用get()獲取參數時，只能獲取到?后面的參數，獲取不到路由里面的參數，
就要使用到route()方法。
助手函數，input('param.')
依賴注入：在方法名中index(Request $request) 在方法里面就可以用了。
3-7：
產品功能講解與分析：
項目：零食商販
3-8：
Vavicat安裝以及數據庫初步設計：
傾向于不用外鍵約束，
4-1:
Banner(輪播圖)數據表設計分析：
有兩張圖 banner,banner_item
4-2:
Banner接口
方法：根據id獲取banner
指明路由和方法，
4-3：
validate 獨立驗證
內置規則，可自定義驗證過則。
new Validate(規則)
->batch()
->check(數據)
->getError()
但是這種獨立驗證的封裝性沒有驗證器好，以后大多數情況下都使用驗證器。
4-4：
驗證器
區別 對規則做了更好的封裝
新建validate文件夾 類 屬性 rules 使用：new 驗證類
4-5：
項目結構體系詳解：
客戶端：cms 和小程序 登錄就是獲取令牌的過程 重點
小程序 和微信服務器 以及 我們自己的服務器交互
服務端;校驗參數->controller ->model/service/logic ->核心框架 異常處理
注意：service 和 model層之間的關系 最好能靈活的同級
小程序的緩存
restful api
4-6:
自定義驗證規則：
getBanenrByID
參數 id正整數
自己寫（發生錯誤，新建文件夾的時候，把順序搞混了，導致接口訪問不到！一定要注意）
4-7：
構建接口參數校驗層：
上一節 的 也不夠精簡 復用性不高。
baseValidate基類。
goCheck 獲取參數 做校驗
攔截器 先使用tp5的默認異常
自己寫 沒什么問題
5-1：
REST之前的重要協議:SOAP
soap 重 使用xml描述數據 前端調接口的時候 流程復雜 網站后臺轉發調用
5-2：
restful api 特點解析：
api基于rest理論設計
通常來說 json來描述數據
無狀態 ，每次請求不依賴其他接口
基于資源， 使用Http動詞來操作資源
傳統：區分使用get或者post 是根據參數簡單與否來區分，現在：根據動作來區分
eg:刪除操作使用delete ，新增操作使用post ,獲取操作使用get,更新使用put.
接口名稱的定義 盡量用名詞而不是動詞 。eg:movie/id 而不是：getMovie/id.
5-3:
RESTFul API 最佳實踐：
每次http請求都應該響應一個狀態碼，錯誤碼（自定義 ：有文檔 ，可查找）和 統一描述錯誤
狀態碼：
404 資源沒找到
400 參數錯誤
200 get查詢資源成功
201 post創建資源成功
202 put更新成功了（有些設置為請求未響應）
401 無權限
403 禁止訪問
500 服務器未知錯誤 。
統一錯誤描述信息:錯誤碼，錯誤信息，當前url.
使用token令牌來授權和驗證身份，
傳統web用session和cookie，和token比較，token自己的服務器存儲管理，靈活。
版本控制。
詳細文檔。
5-4：
如何學習RESTFul API。
模仿：豆瓣開放api ，github開發者api
合理使用，切勿盲目照搬標磚REST，因為我們面向的是內部人員
6-1：
正確理解異常處理流程：
類同名的情況下別名，
異常層級關系 ->全局異常處理AOP
6-2：
固有的處理異常的思維方式和流程：
現在有個服務器錯誤，假如1/0,拋出異常 狀態碼 400
6-3：
異常的分類：
兩類：
由于用戶行為導致的異常 ，比如參數輸入錯誤 導致沒有查詢到數據 ，有的返回一個空數組，并不當成異常，有的 返回一個自定義的異常碼。
不需要記錄日志 ，
需要向用戶返回具體的錯誤信息。
第二就是服務器自身異常，記錄日志，不向客戶返回具體原因。
6-4：
實現自定義全局異常處理：
新建exception文件夾，
覆蓋和重寫，
三個類
config 要配置
6-5：
實現已定義全局異常處理 下
render()方法要處理兩種不同的異常，
新建文件記錄錯誤碼
測試兩個異常！
6-6：
日志系統：
先關掉tp5的自動日志記錄 ，太多，
有選擇的記錄日志，
6-7：
在全局異常處理中加入日志記錄，
私有方法，記錄日志，
手動初始化日志，然后記錄日志
6-8：
全局異常處理應用 上：
對于客戶端開發人員 json格式比較好，
對于服務端開發人員 網頁格式比較好
需要一個開關，
還原父類的render()方法，
配置文件，助手函數
完善goCheck()拋出的異常 定義一個新的自定義異常
6-9：
全局異常處理的應用 中：
構造函數 對成員變量操作 可選參數賦值 異常類
6-10：
全局異常處理的應用 下:
驗證器 需要驗證多個參數的時候
batch()方法
6-11：
小結與AOP思想：面向切面
