GoFrame DAO對象封裝設(shè)計(jì)-工程封裝設(shè)計(jì)

一、基本介紹

我們都知道，開發(fā)業(yè)務(wù)項(xiàng)目離不開數(shù)據(jù)庫操作組件的使用，數(shù)據(jù)庫是絕大部分業(yè)務(wù)項(xiàng)目的核心，這也是"CRUD工程師"戲稱的由來。業(yè)務(wù)項(xiàng)目在進(jìn)行數(shù)據(jù)庫操作時(shí)，比較low的方式是直接?Open/New?然后各種?SQL?字符串操作一把梭。稍微正常一點(diǎn)的項(xiàng)目可能會考慮物色或者自己封裝一層ORM抽象，提高CRUD效率，降低數(shù)據(jù)操作風(fēng)險(xiǎn)。再嚴(yán)謹(jǐn)一點(diǎn)的項(xiàng)目可能會在項(xiàng)目工程管理上考慮下，再進(jìn)一步增加?DAO/DTO/VO?之類的設(shè)計(jì)模式和概念。

信息時(shí)代，數(shù)據(jù)是十分重要的，數(shù)據(jù)操作是十分敏感的，因此?GoFrame?框架對于數(shù)據(jù)操作管理的工程化思路是嚴(yán)謹(jǐn)?shù)摹Ｎ覀兲峁┝吮匾腛RM抽象、必要的DAO封裝、必要的工程化規(guī)范約束。同時(shí)，我們并不會采用八股文設(shè)計(jì)，而是依舊保持簡便、靈活、易擴(kuò)展的工程設(shè)計(jì)思路。

二、工程化痛點(diǎn)

在一些嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)項(xiàng)目中，已經(jīng)有了?ORM&DAO?抽象、并且項(xiàng)目已有初步工程化設(shè)計(jì)的前提，依舊存在以下常見的痛點(diǎn)。

1、數(shù)據(jù)集合與代碼結(jié)構(gòu)不同步

當(dāng)在代碼中手動維護(hù)數(shù)據(jù)集合對應(yīng)的數(shù)據(jù)結(jié)構(gòu)時(shí)，這個坑就算挖好了，就看后面誰掉進(jìn)去了。

2、數(shù)據(jù)模型與業(yè)務(wù)模型模糊不清

混淆了數(shù)據(jù)模型與業(yè)務(wù)的職責(zé)，并將數(shù)據(jù)模型與業(yè)務(wù)邏輯、接口定義形成了耦合，耦合越大，相關(guān)方法、接口維護(hù)的成本越高，對數(shù)據(jù)模型改動產(chǎn)生的風(fēng)險(xiǎn)也越大。常見痛點(diǎn)：

• 在model中既有業(yè)務(wù)相關(guān)的數(shù)據(jù)結(jié)構(gòu)（業(yè)務(wù)模型），又有數(shù)據(jù)集合對應(yīng)的數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)模型），如何高效隔離和管理呢？
• 在業(yè)務(wù)流程中，將數(shù)據(jù)模型當(dāng)做業(yè)務(wù)流程的輸入?yún)?shù)使用。甚至，將數(shù)據(jù)模型直接嵌入到API接口輸入數(shù)據(jù)結(jié)構(gòu)定義中（總是想法設(shè)法將數(shù)據(jù)模型用到業(yè)務(wù)模型中）。

3、DAO層沉淀太多的業(yè)務(wù)邏輯封裝

 您是否有一種感覺，只要是數(shù)據(jù)操作，都有理由往?DAO?里面丟？

4、將數(shù)據(jù)模型作為ORM/DAO操作的參數(shù)

您有可能認(rèn)為這么做是對的，但是不明確的數(shù)據(jù)結(jié)構(gòu)都意味著成本和風(fēng)險(xiǎn)。任何的操作，都應(yīng)當(dāng)能夠明確輸入/輸出，否則都是不嚴(yán)謹(jǐn)?shù)?，對待?shù)據(jù)的操作尤其應(yīng)當(dāng)嚴(yán)謹(jǐn)。

5、數(shù)據(jù)操作權(quán)限開放，項(xiàng)目任何地方都可以隨意調(diào)用

數(shù)據(jù)的操作權(quán)限應(yīng)當(dāng)盡可能收口，如果過于開放那么當(dāng)業(yè)務(wù)及人員復(fù)雜之后，項(xiàng)目的維護(hù)成本和風(fēng)險(xiǎn)都會曲線增加。

6、從頂層業(yè)務(wù)到底層數(shù)據(jù)集合操作，通篇使用同一個數(shù)據(jù)結(jié)構(gòu)

常見的問題，是設(shè)計(jì)一個大的結(jié)構(gòu)體，例如數(shù)據(jù)模型（更有甚者，將屬性全部設(shè)計(jì)為指針或者?interface{}?），從頂層業(yè)務(wù)到底層數(shù)據(jù)操作層層透傳，方法邏輯根據(jù)是否輸入特定的屬性來判斷傳參。會造成什么問題呢：

• 方法參數(shù)定義不明確，不明確的定義意味著會增加額外的協(xié)作成本，額外的不明確風(fēng)險(xiǎn)
• 同一數(shù)據(jù)結(jié)構(gòu)與多數(shù)方法形成耦合，數(shù)據(jù)結(jié)構(gòu)的任一變動將會影響所有相關(guān)方法
• 相關(guān)方法無法充分復(fù)用（特別是?service?層的方法）

三、工程化改進(jìn)

1、自動化的數(shù)據(jù)模型管理

通過工具自動化實(shí)現(xiàn)數(shù)據(jù)集合到數(shù)據(jù)模型的代碼生成，避免人工維護(hù)造成的不同步。

2、數(shù)據(jù)與業(yè)務(wù)模型的隔離

將數(shù)據(jù)模型通過?entity?包維護(hù)，業(yè)務(wù)模型通過?model?包維護(hù)，通過不同的包職責(zé)來做區(qū)分。數(shù)據(jù)模型由工具化維護(hù)，業(yè)務(wù)模型根據(jù)業(yè)務(wù)場景由開發(fā)者定義和維護(hù)。

3、自動化的DAO代碼管理

通過工具自動化實(shí)現(xiàn)數(shù)據(jù)集合的?DAO?代碼生成，提高生產(chǎn)效率。?DAO?中只有自動化生成的基礎(chǔ)數(shù)據(jù)操作，不封裝特定業(yè)務(wù)邏輯。

4、DO數(shù)據(jù)轉(zhuǎn)換模型的引入

避免數(shù)據(jù)模型直接被當(dāng)做?DAO?參數(shù)使用，避免踩坑。?GoFrame?框架引入了?DO?包，在?DAO?操作時(shí)自動化轉(zhuǎn)換為數(shù)據(jù)集合對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，提高?DAO?操作的效率，降低操作風(fēng)險(xiǎn)。

5、對數(shù)據(jù)操作權(quán)限進(jìn)行收口

由于數(shù)據(jù)操作已經(jīng)由?DAO?包進(jìn)行了統(tǒng)一維護(hù)，通過將?DAO?包遷移到了?Service?層的?internal?目錄下，實(shí)現(xiàn)項(xiàng)目工程下僅僅只有?Service?層的代碼可以通過?DAO?執(zhí)行數(shù)據(jù)操作。