本篇內容來自於Maven最佳实践：划分模块。我覺得解釋得很不錯，所以特別抄下來放在這裡。
Maven可以使用多模組將原本一個大專案切成多個模組專案，而Maven多模組專案(multi-module project)主要目的就是讓專案更容易維護，更好管理，更好重用。
多模組的畫分可提供以下好處：
- 方便重用。假如今天有一個新的後台專案，因為service，dao，util都為獨立的專案，可各自打包成jar，所以新的專案可直接加到依賴中，不用再依賴一整個war。例如util模組，可逐漸發展成一個公司的基礎工具類，提供給所有專案使用。
- 專案的依賴可由父專案的pom來統一管理，不用每個專案各自維護自己的依賴。而各模組仍可依需求在自己的pom設定依賴。
- 不用每次都build整個專案，你只需要build你所在的專案即可，節省build的時間。
- 某些模組，例如util為被所有人依賴的底層重要的模組，如果不想開放給所有人修改，你可以將此專案拉出來另外做成一個專案，並設定svn的訪問權限，但仍可提供jar給別人使用。
例如原本有一個網路應用程式專案(WebApp)，其結構是常見的三層架構，分別為web，service，dao，及util工具類。web包含controller負責接收前端送來的請求；service處理業務邏輯；dao負責存取資料庫；util類則提供一些共用的工具類。
以上各類放在各自的package中，分別為：
- com.abc.web
- com.abc.service
- com.abc.dao
- com.abc.util
一開始此專案僅是一般使用者使用的前台，但隨著專案的進行，需要建一個新的後台給管理人員使用。而在開發後台的過程中逐漸會發現很多時候都是寫和前台類似的程式碼，因為後台是管理和前台一樣的資料，處理類似的業務，差別多在畫面的呈現和資料的操控，所以前台有很多程式可以重用，例如處理業務邏輯的service，存取資料庫的dao，及工具類util。若前後台各自獨立，不但需要多一倍的人力，又資料源及業務幾乎相同，當資料庫設計有異動，或業務邏輯改變時，前後台的程式碼都因此被影響需要修改。若前台和後台專案程式碼各自獨立，代表需要兩組人力來維護，造成維護成本的提高。
為了避免以上情況，或許後台可以透過依賴前台的war來達到共用程式碼，然而一來在Maven配置中對war的依賴設定不如依賴jar般簡單，又後台專案僅需要依賴賴service，dao，util，並不需要web部分，因此依賴整包war顯得冗贅。
一個專案會有多名人員開發，如果你的同事在dao修改了程式碼並提交到SVN上造成編譯失敗，雖然你是開發service層的部分也因此受到影響。你必須等到開發dao的同事修復後才能繼續進行。
還有就是專案開發中會引入很多依賴函式庫，如果每一個專案都各自引入自己的依賴，會造成依賴版本上的混亂而難以管理。
而隨著專案越大，build的時間越來越長，儘管你可能只是負責一其中一小塊業務，但仍要build整個專案。
或是一些底層的util只想讓資深工程師負責維護，然而屬於同個專案的架構下，仍有被其他人修改的可能等。
而透過Maven的多模組專案將大模組專案畫分成多個小的模組專案，並透過一個母專案來管理，即能解決以上問題。
Maven多模組專案會有一個父專案(parent)，父模組下聚合(aggregate)多個子模組(child module)專案，不論父或子專案都有各自的pom.xml。
上述專案若改為多模組專案，則結構如下
myapp
|
+--web
| |
| +-pom.xml
|
+--service
| |
| +-pom.xml
|
+--dao
| |
| +-pom.xml
|
+--util
| |
| +-pom.xml
|
+--pom.xml
父專案為myapp，負責聚合子模組，僅管理模組間的依賴，所以package為pom的形式。而servce，dao，util模組的package形式為jar。
子模組中的依賴關係為單向的，依賴關係為：
- web依賴service。
- service依賴dao。
- dao依賴util。
因為Maven的依賴有傳遞性(transitive dependency)，因為dao依賴util，因此web和service也都因此依賴util。
參考：
沒有留言:
張貼留言