項目結構介紹

通常的項目結構

 

各個目錄詳細介紹：

 

然后接下來/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層進行輸出或展示。