回到目錄

關(guan)于Lind.DDD框(kuang)架里API框(kuang)架的技術點說明

講解：張占嶺

花名：倉儲大叔

主要框(kuang)架(jia)：Lind.DDD

目錄

1. 關于Lind.DDD.Authorization
2. 關于授權的原理
3. 關于ApiValidateModelConfig
4. 關于Lind.DDD.CacheConfigFile
5. 如何為你的API項(xiang)目注(zhu)入授權模塊
6. 關于服務端收取過濾器ApiValiadateFilter
7. 如何在客戶端生產加密授權串
8. 關于請求類與響應類
9. 客戶端如何做分頁

關于Lind.DDD.Authorization

Lind.DDD為我們(men)提交了強大的API校(xiao)驗組件，只需要(yao)在全局或者要(yao)授權的controller上添加(jia)對應的(de)過濾器即(ji)可完成授(shou)權(quan)的(de)過程，這樣(yang)，你的(de)API就安全多(duo)了。

關于授權的原理

客戶端在向API服務端獲(huo)取數據時(shi)，需要先申(shen)請一(yi)個appkey作為自己的標識，當然這也是雙方約定的，我們可以叫做公鑰，而真正做數據校驗的不是它，它只是一個唯一標識，對外公開，真正做數據加密的叫passKey，它是保存在雙(shuang)方內部的(de)，不對外(wai)公(gong)開，所以叫密鑰，在客戶端向API服務端(duan)通(tong)訊時，需要將這個passKey連同參數和appkey傳到(dao)服務端(duan)，由服務端(duan)做相(xiang)(xiang)同(tong)的(de)校驗碼生產邏輯，最(zui)后(hou)兩者進行(xing)比(bi)較，相(xiang)(xiang)同(tong)即驗證通過。

關于ApiValidateModelConfig

ApiValidateModelConfig主要在服務端存儲所有被收取的客戶端的信息，它是一個列表集合，由AppKey,AppName,PassKey,ExpireDate等元素組成(cheng)，它們具體的含(han)義如下：

而這個實體在服務端校驗時，會從配置文件XML中反射出來，以遍(bian)進行比較(jiao)，當然，你的配(pei)置文件如果(guo)沒有修改，它會直接從內(nei)存里進行獲取，這個邏輯(ji)由CacheConfig控(kong)制。

關于Lind.DDD.CacheConfigFile

它在早期的大叔框架里就已經出來了，主要用于做配置文件緩存的，當緩存文件被修改后，它的信息將重新被加載，否則將從內在中來進行獲取，這個文件需要管理員在服務端進行維護，在添加和刪除配置時，需要做修改，當然，我們也完全可以把它持久化到其它數據庫里，如sqlserver,redis等介質。

如何為你的API項目注(zhu)入授權模塊

為API項目注入授權(quan)功能很是容易，直接在對應的controller上添加過濾器Lind.DDD.Authorization.Api.ApiValiadateFilter即可。

或者在Global.asax里添加全局的(de)過(guo)濾，也(ye)是(shi)可以的(de)，值得注意(yi)的(de)是(shi)，如(ru)果(guo)你添加的(de)是(shi)全局過(guo)濾器，如(ru)果(guo)希(xi)望(wang)有一些Controller不被授權(quan)，即(ji)可以被匿名訪(fang)問(wen)，那你也只需要為(wei)指定(ding)的控制器添加AllowAnonymous特性(xing)即(ji)可。

關于服務端收取過濾器ApiValiadateFilter

ApiValiadateFilter是(shi)服務端的收取核心組(zu)件，它會攔截指定(ding)的api控制器，然后進行授(shou)權檢查，如(ru)果(guo)沒(mei)有(you)被標示AllowAnonymous，它將會進(jin)行(xing)校驗，具體就是將請求參(can)數進(jin)行(xing)排(pai)序，組件，并連同(tong)passkey(由客(ke)戶端傳來的appKey進行查(cha)詢(xun)，得到的(de)ApiValidateModel實(shi)體)生(sheng)成新的(de)MD5加密串，與客戶端傳(chuan)過來的密鑰進行對比(bi)，匹配(pei)即有效，否則返(fan)回(hui)403無(wu)權訪問，最新的api校驗(yan)的新功(gong)能如下(xia)：

一、統一校驗模塊

二、統(tong)一(yi)參數組合的生(sheng)成

三、UTC時(shi)間(jian)戳的引入，參數有效(xiao)性校驗（1小時有效）

四、雙(shuang)方約(yue)定的密(mi)鑰，請求(qiu)的防偽(wei)造

如何在客戶端生產加密授權串

Lind.DDD框(kuang)架為我們提供了生成請求密(mi)鑰的方法，你(ni)需要做的只是將所有參數添(tian)加到(dao)字典，然后調用對(dui)應的方法即可，這(zhe)對(dui)于.net開(kai)發(fa)人員來說(shuo)，絕對是(shi)個(ge)福音！

關于請求類與響應類

API服(fu)務端與客戶(hu)端約定了請求與響應的模型，它們都(dou)是抽象類，提供最(zui)基(ji)礎(chu)的功能，下面簡單(dan)說(shuo)一下：

l 請求對象(xiang)

對應于DTO請(qing)求類，它繼承自(zi)抽象類RequestBase，它(ta)提供了傳輸標(biao)示，分頁，排序，篩選字段等功(gong)能。

l 響(xiang)應對象

對應(ying)于(yu)DTO響(xiang)應(ying)類，它繼承自抽象(xiang)類ResponseBase，它提供了RequestBase里的傳輸標示，標明了是否(fou)為同一個請求，響(xiang)應(ying)的字段等。

l 響應返回對(dui)象(xiang)

對(dui)應于DTO的(de)返回(hui)結果(guo)，它(ta)(ta)(ta)由密封(feng)類(lei)ResponseMessage提供，返回(hui)它(ta)(ta)(ta)的(de)實例即可，它(ta)(ta)(ta)會提供返回(hui)狀態碼，唯一標識，返回(hui)對(dui)象，錯誤碼和錯誤信息等。

客戶端如何做分頁

分頁對于每個項目來說都是必要的，對于面向服務的API來說了是(shi)必須的，我們Lind.DDD對分頁一定(ding)進行了封(feng)裝，在這里(li)為大家簡(jian)單說一下(xia)。

統一的DTO請求基類(lei)RequestBase，它主要(yao)實現請求方調用時的字段過(guo)濾（ContainFields），分頁控制（Page)，傳(chuan)輸標(biao)示(GuidKey)，按字(zi)段排序(xu)時(shi)（Sort），請求(qiu)方只(zhi)需要(yao)傳輸相應的(de)參數(shu)即可，代碼如下：

在服務端進行分頁方法實現時，返回統一的Lind.DDD.Paging.PagedList<T>對象，而在業務方(fang)法處理時，只需要調用請求類(lei)的GetPageParameters()方法(fa)即可(ke)(ke)拿到(dao)客戶端傳(chuan)來(lai)的分(fen)頁對(dui)(dui)象(xiang)，而(er)從數據(ju)庫查出來(lai)的對(dui)(dui)象(xiang)也(ye)可(ke)(ke)以使用MapToPage<T>()這個方法(fa)來(lai)映射(she)成(cheng)指(zhi)的DTO對(dui)(dui)象(xiang)，代碼如下：

感謝各位對Lind.DDD框架(jia)的關注，讓我(wo)們一起把框架(jia)做(zuo)的更好！

感謝各位！

回到目錄