建站
咨詢
售后
建站咨詢
新聞中心
一、基本介紹
我們都知道，開發(fā)業(yè)務項目離不開數(shù)據(jù)庫操作組件的使用，數(shù)據(jù)庫是絕大部分業(yè)務項目的核心，這也是"CRUD工程師"戲稱的由來。業(yè)務項目在進行數(shù)據(jù)庫操作時，比較low的方式是直接?Open/New?然后各種?SQL?字符串操作一把梭。稍微正常一點的項目可能會考慮物色或者自己封裝一層ORM抽象，提高CRUD效率，降低數(shù)據(jù)操作風險。再嚴謹一點的項目可能會在項目工程管理上考慮下，再進一步增加?DAO/DTO/VO?之類的設計模式和概念。
成都創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、薛城網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5響應式網(wǎng)站、購物商城網(wǎng)站建設、集團公司官網(wǎng)建設、外貿(mào)網(wǎng)站建設、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為薛城等各大城市提供網(wǎng)站開發(fā)制作服務。
信息時代，數(shù)據(jù)是十分重要的，數(shù)據(jù)操作是十分敏感的，因此?GOFrame?框架對于數(shù)據(jù)操作管理的工程化思路是嚴謹?shù)摹Ｎ覀兲峁┝吮匾腛RM抽象、必要的DAO封裝、必要的工程化規(guī)范約束。同時，我們并不會采用八股文設計，而是依舊保持簡便、靈活、易擴展的工程設計思路。
二、工程化痛點
在一些嚴謹?shù)臉I(yè)務項目中，已經(jīng)有了?ORM&DAO?抽象、并且項目已有初步工程化設計的前提，依舊存在以下常見的痛點。
1、數(shù)據(jù)集合與代碼結構不同步
當在代碼中手動維護數(shù)據(jù)集合對應的數(shù)據(jù)結構時，這個坑就算挖好了，就看后面誰掉進去了。
2、數(shù)據(jù)模型與業(yè)務模型模糊不清
混淆了數(shù)據(jù)模型與業(yè)務的職責，并將數(shù)據(jù)模型與業(yè)務邏輯、接口定義形成了耦合，耦合越大，相關方法、接口維護的成本越高，對數(shù)據(jù)模型改動產(chǎn)生的風險也越大。常見痛點：
- 在model中既有業(yè)務相關的數(shù)據(jù)結構（業(yè)務模型），又有數(shù)據(jù)集合對應的數(shù)據(jù)結構（數(shù)據(jù)模型），如何高效隔離和管理呢？
- 在業(yè)務流程中，將數(shù)據(jù)模型當做業(yè)務流程的輸入?yún)?shù)使用。甚至，將數(shù)據(jù)模型直接嵌入到API接口輸入數(shù)據(jù)結構定義中（總是想法設法將數(shù)據(jù)模型用到業(yè)務模型中）。
3、DAO層沉淀太多的業(yè)務邏輯封裝
您是否有一種感覺，只要是數(shù)據(jù)操作，都有理由往?DAO?里面丟？
4、將數(shù)據(jù)模型作為ORM/DAO操作的參數(shù)
您有可能認為這么做是對的，但是不明確的數(shù)據(jù)結構都意味著成本和風險。任何的操作，都應當能夠明確輸入/輸出，否則都是不嚴謹?shù)?，對待?shù)據(jù)的操作尤其應當嚴謹。
5、數(shù)據(jù)操作權限開放，項目任何地方都可以隨意調(diào)用
數(shù)據(jù)的操作權限應當盡可能收口，如果過于開放那么當業(yè)務及人員復雜之后，項目的維護成本和風險都會曲線增加。
6、從頂層業(yè)務到底層數(shù)據(jù)集合操作，通篇使用同一個數(shù)據(jù)結構
常見的問題，是設計一個大的結構體，例如數(shù)據(jù)模型（更有甚者，將屬性全部設計為指針或者?interface{}?），從頂層業(yè)務到底層數(shù)據(jù)操作層層透傳，方法邏輯根據(jù)是否輸入特定的屬性來判斷傳參。會造成什么問題呢：
- 方法參數(shù)定義不明確，不明確的定義意味著會增加額外的協(xié)作成本，額外的不明確風險
- 同一數(shù)據(jù)結構與多數(shù)方法形成耦合，數(shù)據(jù)結構的任一變動將會影響所有相關方法
- 相關方法無法充分復用（特別是?
service?層的方法）
三、工程化改進
1、自動化的數(shù)據(jù)模型管理
通過工具自動化實現(xiàn)數(shù)據(jù)集合到數(shù)據(jù)模型的代碼生成，避免人工維護造成的不同步。
2、數(shù)據(jù)與業(yè)務模型的隔離
將數(shù)據(jù)模型通過?entity?包維護，業(yè)務模型通過?model?包維護，通過不同的包職責來做區(qū)分。數(shù)據(jù)模型由工具化維護，業(yè)務模型根據(jù)業(yè)務場景由開發(fā)者定義和維護。
3、自動化的DAO代碼管理
通過工具自動化實現(xiàn)數(shù)據(jù)集合的?DAO?代碼生成，提高生產(chǎn)效率。?DAO?中只有自動化生成的基礎數(shù)據(jù)操作，不封裝特定業(yè)務邏輯。
4、DO數(shù)據(jù)轉換模型的引入
避免數(shù)據(jù)模型直接被當做?DAO?參數(shù)使用，避免踩坑。?GoFrame?框架引入了?DO?包，在?DAO?操作時自動化轉換為數(shù)據(jù)集合對應的數(shù)據(jù)結構，提高?DAO?操作的效率，降低操作風險。
5、對數(shù)據(jù)操作權限進行收口
由于數(shù)據(jù)操作已經(jīng)由?DAO?包進行了統(tǒng)一維護，通過將?DAO?包遷移到了?Service?層的?internal?目錄下，實現(xiàn)項目工程下僅僅只有?Service?層的代碼可以通過?DAO?執(zhí)行數(shù)據(jù)操作。
文章名稱：創(chuàng)新互聯(lián)GoFrame教程：GoFrameDAO對象封裝設計-工程封裝設計
轉載來源：http://m.5511xx.com/article/dhpephi.html
