一、基本介紹

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

成都創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、薛城網(wǎng)站定制設(shè)計、自適應品牌網(wǎng)站建設(shè)、H5響應式網(wǎng)站、購物商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為薛城等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

信息時代，數(shù)據(jù)是十分重要的，數(shù)據(jù)操作是十分敏感的，因此?GOFrame?框架對于數(shù)據(jù)操作管理的工程化思路是嚴謹?shù)?。我們提供了必要的ORM抽象、必要的DAO封裝、必要的工程化規(guī)范約束。同時，我們并不會采用八股文設(shè)計，而是依舊保持簡便、靈活、易擴展的工程設(shè)計思路。

二、工程化痛點

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

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

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

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

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

• 在model中既有業(yè)務(wù)相關(guān)的數(shù)據(jù)結(jié)構(gòu)（業(yè)務(wù)模型），又有數(shù)據(jù)集合對應的數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)模型），如何高效隔離和管理呢？
• 在業(yè)務(wù)流程中，將數(shù)據(jù)模型當做業(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ù)

您有可能認為這么做是對的，但是不明確的數(shù)據(jù)結(jié)構(gòu)都意味著成本和風險。任何的操作，都應當能夠明確輸入/輸出，否則都是不嚴謹?shù)模瑢Υ龜?shù)據(jù)的操作尤其應當嚴謹。

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

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

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

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

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

三、工程化改進

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

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

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

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

3、自動化的DAO代碼管理

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

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

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

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

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

名稱欄目：創(chuàng)新互聯(lián)GoFrame教程：GoFrameDAO對象封裝設(shè)計-工程封裝設(shè)計
文章來源：http://uogjgqi.cn/article/dhpephi.html