項目結構介紹

通常的項目結構

各個目錄詳細介紹：

然後接下來/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包里了。

一些註意事項

1、Contorller層參數傳遞建議不要使用HashMap，建議使用數據模型定義

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

3、Service層做實際業務邏輯，可以按照功能模塊做好定義和區分，相互可以調用 

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

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