看完這篇，別人的開源項目結構應該能看懂了

我爲何要寫這篇

近來，和很多初學Spring或Spring Boot的小夥伴私信交流了關於項目目錄結構劃分和代碼分層的問題。

不少小夥伴表示網上下載下來的開源項目看不懂，項目結構和代碼分層看得很蒙，不知道應該以一個什麼樣的思路去學習和吸取別人的項目。

好，今天熬夜肝了這篇文章，和你們一塊兒來交流探討一下，不足之處也請小夥伴們批評指正。

先看看阿里是怎麼約定的
我印象中，之前在看《阿里巴巴Java開發手冊》時，好像有關於工程結構和應用分層相關的內容，因而我回翻了一下，果真有：

它這裏面講的內容大概就是：關於一個正常的企業項目裏一種通用的項目結構和代碼層級劃分的指導意見。

按這本書上說的，通常分爲以下幾層：

開放接口層
終端顯示層
Web 層
Service 層
Manager 層
DAO 層
外部接口或第三方平臺
因爲書中的篇幅關係，它這地方講得比較籠統了，估計初學者看了仍是會懵，因此接下來結合實際項目代碼結構，來嘮一嘮具體的項目結構和代碼分層。

一般的項目結構

首先說在前面的是：這東西並無一套通用的標準，不一樣公司或者團隊的使用習慣和規範也不盡相同。

咱們就以當下很是火熱的Spring Boot典型項目結構爲例，建立出來的項目應該整體分爲三大層：

• 項目根目錄/src/main/java：放置項目Java源代碼
• 項目根目錄/src/main/resources：放置項目靜態資源和配置文件
• 項目根目錄/src/test/java：放置項目測試用例代碼

而位於/src/main/java目錄下的Java源代碼的組織結構你們比較關心，這地方也只能給出一個一般典型的結構，畢竟不一樣項目和團隊實踐不同，稍許有區別，但總體安排應該差很少。並且若是是多模塊的項目的話，下面的結構應該只對應其中一個模塊，其餘模塊的代碼組織也大體差很少。

各個目錄詳細介紹：

而後接下來/src/main/resources目錄，裏面主要存放靜態配置文件和頁面靜態資源等東西：

固然，這地方估計有一個不少人都會糾結的關於DTO/VO/DO等數據模型定義的區分。

這在《阿里巴巴Java開發手冊》中卻是作了一個所謂的嚴格區分，那本書上是這樣去定義的：

• DO（Data Object）：與數據庫表結構一一對應，經過DAO層向上傳輸數據源對象。
• DTO（Data Transfer Object）：數據傳輸對象，Service或Manager向外傳輸的對象。
• BO（Business Object）：業務對象。由Service層輸出的封裝業務邏輯的對象。
• AO（Application Object）：應用對象。在Web層與Service層之間抽象的複用對象模型，極爲貼近展現層，複用度不高。
• VO（View Object）：顯示層對象，一般是Web向模板渲染引擎層傳輸的對象。
• Query：數據查詢對象，各層接收上層的查詢請求。注意超過2個參數的查詢封裝，禁止使用Map類來傳輸。

老實講，看到這麼多對象的定義，我也是很蒙的。實際項目開發時，我以爲沒有必要刻意照搬去定義這麼多層對象，這樣後續作對象轉換工做都能煩skr人。

出於簡單起見，我我的以爲，只要保證業務邏輯層Service和數據庫DAO層的操做對象嚴格劃分出來，確保互相不滲透，不混用，問題應該就不大。

好比在我上面舉例的這個項目的代碼結構中，Service層處理的對象都定義在了dto包裏，而DAO層處理的對象都放在了entity包裏了。

項目結構劃分總結

若是從一個用戶訪問一個網站的狀況來看，對應着上面的項目代碼結構來分析，能夠貫穿整個代碼分層：

對應代碼目錄的流轉邏輯就是：

我想，應該看得比較清楚了吧。

因此，之後每當咱們拿到一個新的項目到手時，只要按照這個思路去看別人項目的代碼，應該基本都是能理得順的。

一些注意事項
一、Contorller層參數傳遞建議不要使用HashMap，建議使用數據模型定義

二、Controller層裏能夠作參數校驗、異常拋出等操做，但建議不要放太多業務邏輯，業務邏輯儘可能放到Service層代碼中去作

三、Service層作實際業務邏輯，能夠按照功能模塊作好定義和區分，相互能夠調用

四、功能模塊Service之間引用時，建議不要滲透到DAO層（或者mapper層），基於Service層進行調用和複用比較合理

五、業務邏輯層Service和數據庫DAO層的操做對象不要混用。Controller層的數據對象不要直接滲透到DAO層（或者mapper層）；同理數據表實體對象Entity也不要直接傳到Controller層進行輸出或展現。

一些注意事項
一、Contorller層參數傳遞建議不要使用HashMap，建議使用數據模型定義

二、Controller層裏能夠作參數校驗、異常拋出等操做，但建議不要放太多業務邏輯，業務邏輯儘可能放到Service層代碼中去作

三、Service層作實際業務邏輯，能夠按照功能模塊作好定義和區分，相互能夠調用

四、功能模塊Service之間引用時，建議不要滲透到DAO層（或者mapper層），基於Service層進行調用和複用比較合理

五、業務邏輯層Service和數據庫DAO層的操做對象不要混用。Controller層的數據對象不要直接滲透到DAO層（或者mapper層）；同理數據表實體對象Entity也不要直接傳到Controller層進行輸出或展現。