建站
咨詢
售后
建站咨詢
新聞中心
前言
最近review公司的代碼，發(fā)現(xiàn)現(xiàn)在整個(gè)代碼層級十分混亂，一個(gè)service類的長度甚至達(dá)到了5000多行。而且各種分層模型DTO、VO亂用， 最終出現(xiàn)邏輯不清晰、各模塊相互依賴、代碼擴(kuò)展性差、改動(dòng)一處就牽一發(fā)而動(dòng)全身等問題。
創(chuàng)新互聯(lián)專注于中大型企業(yè)的成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站和網(wǎng)站改版、網(wǎng)站營銷服務(wù)，追求商業(yè)策劃與數(shù)據(jù)分析、創(chuàng)意藝術(shù)與技術(shù)開發(fā)的融合，累計(jì)客戶上1000+，服務(wù)滿意度達(dá)97%。幫助廣大客戶順利對接上互聯(lián)網(wǎng)浪潮，準(zhǔn)確優(yōu)選出符合自己需要的互聯(lián)網(wǎng)運(yùn)用，我們將一直專注品牌網(wǎng)站建設(shè)和互聯(lián)網(wǎng)程序開發(fā)，在前進(jìn)的路上，與客戶一起成長！
我們在吸取了阿里巴巴的分層規(guī)范以及網(wǎng)上的一些經(jīng)驗(yàn)后，重新梳理總結(jié)了屬于我們項(xiàng)目的分層規(guī)范。
三層架構(gòu)VS四層架構(gòu)
我們公司原來的分層采用的是傳統(tǒng)的三層架構(gòu)，比如在構(gòu)建項(xiàng)目的時(shí)候，我們通常會(huì)建立三個(gè)目錄：Web、Service 和 Dao，它們分別對應(yīng)了表現(xiàn)層、邏輯層還有數(shù)據(jù)訪問層。
這樣導(dǎo)致一個(gè)很大的問題，隨著業(yè)務(wù)越來越復(fù)雜，邏輯層也就是service層越來越龐大，所以出現(xiàn)了前面說的5000多行的類，可想而知維護(hù)成本有多大。
參照阿里發(fā)布的《阿里巴巴 Java 開發(fā)手冊 v1.4.0（詳盡版）》，我們可以將原先的三層架構(gòu)細(xì)化成下面的樣子：
- 終端顯示層：各端模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動(dòng)端展示等。
- 開放接口層：將Service 層方法封裝成開放接口，同時(shí)進(jìn)行網(wǎng)關(guān)安全控制和流量控制等。
- Web 層：主要是對訪問控制進(jìn)行轉(zhuǎn)發(fā)，各類基本參數(shù)校驗(yàn)，或者不復(fù)用的業(yè)務(wù)簡單處理等。
- Service 層：業(yè)務(wù)邏輯層。
- Manager 層：通用業(yè)務(wù)處理層。主要實(shí)現(xiàn)下面的功能，1） 對第三方平臺封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息，適配上層接口。2） 對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。3） 與 DAO 層交互，對多個(gè) DAO 的組合復(fù)用。
- DAO 層：數(shù)據(jù)訪問層，與底層 MySQL、Oracle、Hbase 等進(jìn)行數(shù)據(jù)交互。
- 外部接口或第三方平臺：包括其它部門RPC 開放接口，基礎(chǔ)平臺，其它公司的 HTTP 接口。
在這個(gè)分層架構(gòu)中主要增加了 Manager 層，它可以將Service層中的一些通用能力比如操作緩存、消息隊(duì)列的操作下沉，也可以將通過feign調(diào)用其他服務(wù)的接口進(jìn)行一層包裝，再提供給Service調(diào)用，這也就是所謂的防腐層。
VO、DTO、BO、DO區(qū)別
前面講解了整體的一個(gè)分層架構(gòu)，那么在不同的層級之間必然需要一些模型對象進(jìn)行流轉(zhuǎn)傳遞，VO，BO，DO，DTO, 那么他們之間有什么區(qū)別呢？
- VO（View Object）：視圖對象，用于展示層，它的作用是把某個(gè)指定頁面（或組件）的所有數(shù)據(jù)封裝起來。
- DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，用于展示層與服務(wù)層之間的數(shù)據(jù)傳輸對象。
- BO（Business Object）：業(yè)務(wù)對象，把業(yè)務(wù)邏輯封裝為一個(gè)對象，這個(gè)對象可以包括一個(gè)或多個(gè)其它的對象。
- DO（Domain Object）?：領(lǐng)域?qū)ο螅⒗锇桶鸵?guī)范中引入，此對象與數(shù)據(jù)庫表結(jié)構(gòu)一一對應(yīng)，通過 DAO 層向上傳輸數(shù)據(jù)源對象。
VO和DTO什么區(qū)別？?
VO?比較容易混淆的是DTO，DTO?是展示層與服務(wù)層之間傳遞數(shù)據(jù)的對象，可以這樣說，對于絕大部分的應(yīng)用場景來說，DTO和VO?的屬性值基本是一致的，而且他們通常都是POJO?，那么既然有了VO?，為什么還需要DTO呢？
例如服務(wù)層有一個(gè)getUser?的方法返回一個(gè)系統(tǒng)用戶，其中有一個(gè)屬性是gender(性別)，對于服務(wù)層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會(huì)反駁，在服務(wù)層直接就返回“帥哥美女”不就行了嗎？對于大部分應(yīng)用來說，這不是問題，但設(shè)想一下，如果需求允許客戶可以定制風(fēng)格，而不同風(fēng)格對于“性別”的表現(xiàn)方式不一樣，又或者這個(gè)服務(wù)同時(shí)供多個(gè)客戶端使用（不同門戶），而不同的客戶端對于表現(xiàn)層的要求有所不同，那么，問題就來了。再者，回到設(shè)計(jì)層面上分析，從職責(zé)單一原則來看，服務(wù)層只負(fù)責(zé)業(yè)務(wù)，與具體的表現(xiàn)形式無關(guān)，因此，它返回的DTO，不應(yīng)該出現(xiàn)與表現(xiàn)形式的耦合。
BO和DTO的區(qū)別??
從用途上進(jìn)行根本的區(qū)別，BO是業(yè)務(wù)對象，DTO是數(shù)據(jù)傳輸對象，雖然BO也可以排列組合數(shù)據(jù)，但它的功能是對內(nèi)的，但在提供對外接口時(shí)，BO對象中的某些屬性對象可能用不到或者不方便對外暴露，那么此時(shí)DTO只需要在BO的基礎(chǔ)上，抽取自己需要的數(shù)據(jù)，然后對外提供。在這個(gè)關(guān)系上，通常不會(huì)有數(shù)據(jù)內(nèi)容的變化，內(nèi)容變化要么在BO內(nèi)部業(yè)務(wù)計(jì)算的時(shí)候完成，要么在解釋VO的時(shí)候完成。
我們項(xiàng)目根據(jù)實(shí)際情況總結(jié)了分層領(lǐng)域模型的規(guī)范：
- 前端傳入的參數(shù)統(tǒng)一使用DTO接收
- 由于公司是TO B項(xiàng)目，只有一個(gè)電腦web端，所以返回給展示層或者Feign返回的對象建議直接用DTO返回，特殊情況采用VO返回
- 由于歷史原因，和數(shù)據(jù)庫模型對應(yīng)的不采用DO結(jié)尾，直接用原始對象，比如學(xué)生表
student直接使用Student對象 - 目前很多代碼存在繼承關(guān)系，比如DTO、VO繼承數(shù)據(jù)庫對象，這個(gè)堅(jiān)決不允許
項(xiàng)目目錄結(jié)構(gòu)最佳實(shí)踐
可以參考github上面的https://github.com/alvinlkk/mall4cloud這個(gè)項(xiàng)目，它是一個(gè)極度遵守阿里巴巴代碼規(guī)約的項(xiàng)目。
這里面有個(gè)關(guān)于Feign設(shè)計(jì)的亮點(diǎn), 主要是為了避免服務(wù)提供方修改了接口，而調(diào)用方?jīng)]有修改導(dǎo)致異常的問題。
- 將feign接口抽取出一個(gè)獨(dú)立的模塊
- 服務(wù)中依賴feign模塊，實(shí)現(xiàn)FeignClient
我們來看下整體的一個(gè)結(jié)構(gòu)。
mall4cloud
├─mall4cloud-api -- 內(nèi)網(wǎng)接口
│ ├─mall4cloud-api-auth -- 授權(quán)對內(nèi)接口
│ ├─mall4cloud-api-biz -- biz對內(nèi)接口
│ ├─mall4cloud-api-leaf -- 美團(tuán)分布式id生成接口
│ ├─mall4cloud-api-multishop -- 店鋪對內(nèi)接口
│ ├─mall4cloud-api-order -- 訂單對內(nèi)接口
│ ├─mall4cloud-api-platform -- 平臺對內(nèi)接口
│ ├─mall4cloud-api-product -- 商品對內(nèi)接口
│ ├─mall4cloud-api-rbac -- 用戶角色權(quán)限對內(nèi)接口
│ ├─mall4cloud-api-search -- 搜索對內(nèi)接口
│ └─mall4cloud-api-user -- 用戶對內(nèi)接口
├─mall4cloud-auth -- 授權(quán)校驗(yàn)?zāi)K
├─mall4cloud-biz -- mall4cloud 業(yè)務(wù)代碼。如圖片上傳/短信等
├─mall4cloud-common -- 一些公共的方法
│ ├─mall4cloud-common-cache -- 緩存相關(guān)公共代碼
│ ├─mall4cloud-common-core -- 公共模塊核心（公共中的公共代碼）
│ ├─mall4cloud-common-database -- 數(shù)據(jù)庫連接相關(guān)公共代碼
│ ├─mall4cloud-common-order -- 訂單相關(guān)公共代碼
│ ├─mall4cloud-common-product -- 商品相關(guān)公共代碼
│ ├─mall4cloud-common-rocketmq -- rocketmq相關(guān)公共代碼
│ └─mall4cloud-common-security -- 安全相關(guān)公共代碼
├─mall4cloud-gateway -- 網(wǎng)關(guān)
├─mall4cloud-leaf -- 基于美團(tuán)leaf的生成id服務(wù)
├─mall4cloud-multishop -- 商家端
├─mall4cloud-order -- 訂單服務(wù)
├─mall4cloud-payment -- 支付服務(wù)
├─mall4cloud-platform -- 平臺端
├─mall4cloud-product -- 商品服務(wù)
├─mall4cloud-rbac -- 用戶角色權(quán)限模塊
├─mall4cloud-search -- 搜索模塊
└─mall4cloud-user -- 用戶服務(wù)
分享題目：【架構(gòu)設(shè)計(jì)】你的應(yīng)用該如何分層呢？
標(biāo)題路徑：http://m.5511xx.com/article/coijpps.html
