完美世界前传下载,完美世界有声小说全集

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

【架構設計】你的應用該如何分層呢？

前言

最近review公司的代碼，發(fā)現(xiàn)現(xiàn)在整個代碼層級十分混亂，一個service類的長度甚至達到了5000多行。而且各種分層模型DTO、VO亂用，最終出現(xiàn)邏輯不清晰、各模塊相互依賴、代碼擴展性差、改動一處就牽一發(fā)而動全身等問題。

創(chuàng)新互聯(lián)專注于中大型企業(yè)的成都網(wǎng)站設計、做網(wǎng)站和網(wǎng)站改版、網(wǎng)站營銷服務，追求商業(yè)策劃與數(shù)據(jù)分析、創(chuàng)意藝術與技術開發(fā)的融合，累計客戶上1000+，服務滿意度達97%。幫助廣大客戶順利對接上互聯(lián)網(wǎng)浪潮，準確優(yōu)選出符合自己需要的互聯(lián)網(wǎng)運用，我們將一直專注品牌網(wǎng)站建設和互聯(lián)網(wǎng)程序開發(fā)，在前進的路上，與客戶一起成長！

我們在吸取了阿里巴巴的分層規(guī)范以及網(wǎng)上的一些經(jīng)驗后，重新梳理總結了屬于我們項目的分層規(guī)范。

三層架構VS四層架構

我們公司原來的分層采用的是傳統(tǒng)的三層架構，比如在構建項目的時候，我們通常會建立三個目錄：Web、Service 和 Dao，它們分別對應了表現(xiàn)層、邏輯層還有數(shù)據(jù)訪問層。

這樣導致一個很大的問題，隨著業(yè)務越來越復雜，邏輯層也就是service層越來越龐大，所以出現(xiàn)了前面說的5000多行的類，可想而知維護成本有多大。

參照阿里發(fā)布的《阿里巴巴 Java 開發(fā)手冊 v1.4.0（詳盡版）》，我們可以將原先的三層架構細化成下面的樣子：

終端顯示層：各端模板渲染并執(zhí)行顯示的層。當前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
開放接口層：將Service 層方法封裝成開放接口，同時進行網(wǎng)關安全控制和流量控制等。
Web 層：主要是對訪問控制進行轉發(fā)，各類基本參數(shù)校驗，或者不復用的業(yè)務簡單處理等。
Service 層：業(yè)務邏輯層。
Manager 層：通用業(yè)務處理層。主要實現(xiàn)下面的功能，1）對第三方平臺封裝的層，預處理返回結果及轉化異常信息，適配上層接口。2）對 Service 層通用能力的下沉，如緩存方案、中間件通用處理。3）與 DAO 層交互，對多個 DAO 的組合復用。
DAO 層：數(shù)據(jù)訪問層，與底層 MySQL、Oracle、Hbase 等進行數(shù)據(jù)交互。
外部接口或第三方平臺：包括其它部門RPC 開放接口，基礎平臺，其它公司的 HTTP 接口。

在這個分層架構中主要增加了 Manager 層，它可以將Service層中的一些通用能力比如操作緩存、消息隊列的操作下沉，也可以將通過feign調用其他服務的接口進行一層包裝，再提供給Service調用，這也就是所謂的防腐層。

VO、DTO、BO、DO區(qū)別

前面講解了整體的一個分層架構，那么在不同的層級之間必然需要一些模型對象進行流轉傳遞，VO，BO，DO，DTO, 那么他們之間有什么區(qū)別呢？

VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數(shù)據(jù)封裝起來。
DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，用于展示層與服務層之間的數(shù)據(jù)傳輸對象。
BO（Business Object）：業(yè)務對象，把業(yè)務邏輯封裝為一個對象，這個對象可以包括一個或多個其它的對象。
DO（Domain Object）?：領域對象，阿里巴巴規(guī)范中引入，此對象與數(shù)據(jù)庫表結構一一對應，通過 DAO 層向上傳輸數(shù)據(jù)源對象。

VO和DTO什么區(qū)別？?

VO?比較容易混淆的是DTO，DTO?是展示層與服務層之間傳遞數(shù)據(jù)的對象，可以這樣說，對于絕大部分的應用場景來說，DTO和VO?的屬性值基本是一致的，而且他們通常都是POJO?，那么既然有了VO?，為什么還需要DTO呢？

例如服務層有一個getUser?的方法返回一個系統(tǒng)用戶，其中有一個屬性是gender(性別)，對于服務層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會反駁，在服務層直接就返回“帥哥美女”不就行了嗎？對于大部分應用來說，這不是問題，但設想一下，如果需求允許客戶可以定制風格，而不同風格對于“性別”的表現(xiàn)方式不一樣，又或者這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現(xiàn)層的要求有所不同，那么，問題就來了。再者，回到設計層面上分析，從職責單一原則來看，服務層只負責業(yè)務，與具體的表現(xiàn)形式無關，因此，它返回的DTO，不應該出現(xiàn)與表現(xiàn)形式的耦合。

BO和DTO的區(qū)別??

從用途上進行根本的區(qū)別，BO是業(yè)務對象，DTO是數(shù)據(jù)傳輸對象，雖然BO也可以排列組合數(shù)據(jù)，但它的功能是對內的，但在提供對外接口時，BO對象中的某些屬性對象可能用不到或者不方便對外暴露，那么此時DTO只需要在BO的基礎上，抽取自己需要的數(shù)據(jù)，然后對外提供。在這個關系上，通常不會有數(shù)據(jù)內容的變化，內容變化要么在BO內部業(yè)務計算的時候完成，要么在解釋VO的時候完成。

我們項目根據(jù)實際情況總結了分層領域模型的規(guī)范：

前端傳入的參數(shù)統(tǒng)一使用DTO接收
由于公司是TO B項目，只有一個電腦web端，所以返回給展示層或者Feign返回的對象建議直接用DTO返回，特殊情況采用VO返回
由于歷史原因，和數(shù)據(jù)庫模型對應的不采用DO結尾，直接用原始對象，比如學生表student直接使用Student對象
目前很多代碼存在繼承關系，比如DTO、VO繼承數(shù)據(jù)庫對象，這個堅決不允許

項目目錄結構最佳實踐

可以參考github上面的https://github.com/alvinlkk/mall4cloud這個項目，它是一個極度遵守阿里巴巴代碼規(guī)約的項目。

這里面有個關于Feign設計的亮點, 主要是為了避免服務提供方修改了接口，而調用方?jīng)]有修改導致異常的問題。

將feign接口抽取出一個獨立的模塊

服務中依賴feign模塊，實現(xiàn)FeignClient

我們來看下整體的一個結構。

mall4cloud
├─mall4cloud-api -- 內網(wǎng)接口
│  ├─mall4cloud-api-auth  -- 授權對內接口
│  ├─mall4cloud-api-biz  -- biz對內接口
│  ├─mall4cloud-api-leaf  -- 美團分布式id生成接口
│  ├─mall4cloud-api-multishop  -- 店鋪對內接口
│  ├─mall4cloud-api-order  -- 訂單對內接口
│  ├─mall4cloud-api-platform  -- 平臺對內接口
│  ├─mall4cloud-api-product  -- 商品對內接口
│  ├─mall4cloud-api-rbac  -- 用戶角色權限對內接口
│  ├─mall4cloud-api-search  -- 搜索對內接口
│  └─mall4cloud-api-user  -- 用戶對內接口
├─mall4cloud-auth  -- 授權校驗模塊
├─mall4cloud-biz  -- mall4cloud 業(yè)務代碼。如圖片上傳/短信等
├─mall4cloud-common -- 一些公共的方法
│  ├─mall4cloud-common-cache  -- 緩存相關公共代碼
│  ├─mall4cloud-common-core  -- 公共模塊核心（公共中的公共代碼）
│  ├─mall4cloud-common-database  -- 數(shù)據(jù)庫連接相關公共代碼
│  ├─mall4cloud-common-order  -- 訂單相關公共代碼
│  ├─mall4cloud-common-product  -- 商品相關公共代碼
│  ├─mall4cloud-common-rocketmq  -- rocketmq相關公共代碼
│  └─mall4cloud-common-security  -- 安全相關公共代碼
├─mall4cloud-gateway  -- 網(wǎng)關
├─mall4cloud-leaf  -- 基于美團leaf的生成id服務
├─mall4cloud-multishop  -- 商家端
├─mall4cloud-order  -- 訂單服務
├─mall4cloud-payment  -- 支付服務
├─mall4cloud-platform  -- 平臺端
├─mall4cloud-product  -- 商品服務
├─mall4cloud-rbac  -- 用戶角色權限模塊
├─mall4cloud-search  -- 搜索模塊
└─mall4cloud-user  -- 用戶服務

網(wǎng)站題目：【架構設計】你的應用該如何分層呢？
本文鏈接：http://fisionsoft.com.cn/article/coijpps.html