本文所提到的所有內容的前提是使用一些開源框架搭建簡單的J2EE（J2EE培訓 ）應用時，對配置的運用方面的一些總結出來的最佳實踐。
1. 盡最大的可能簡化你的配置
這一點似乎是基本原則，沒有人會願意多寫一行代碼，配置也是代碼，多一行配置，就意味著多一行的維護量。簡化配置的主要途徑大致有:
1) 盡可能減少配置文件的數量
2) 使用語義鮮明的Annotation來代替復雜的XML文件配置
3) 使用CoC來代替配置文件
4) 使用一些特殊的技巧來簡化配置文件的內容
2. 分離關注點，讓配置文件各盡其用
這一點似乎與第一點有所背離，不過事實上，分離關注點對於配置文件的可維護性是非常重要的一點。
舉一個針對Spring+Hibernate的配置場景作為例子。通常我們需要一個Spring的配置文件(applicationContext.XML)，來配置DataSource和SessionFactory，由於Spring本身提供了針對Hibernate的Global屬性進行配置的選項，所以，其實我們可以通過如下的配置文件，對Spring+Hibernate完成配置：
com/demo2do/demo/entity/User.hbm.XML
com/demo2do/demo/entity/Order.hbm.XML
com/demo2do/demo/entity/Admin.hbm.XML
org.hibernate.dialect.MySQLDialect
true
在這裡，我們發現，一個SessionFactory的配置實在太長了，一旦我們需要對其中的某些配置進行改動，就需要用肉眼去觀察我們所需要修改的配置片段。在項目開發過程中，我們會發現，這個文件的這個配置片段修改頻度會非常高，因為在一個團隊中，每個人都可能需要增加一個持久化類，或者對hibernate進行一些全局化的配置修改。結果，這段配置可能會在版本管理上造成merge的混亂。
所以，我們可以在這個基礎上對這段配置進行重構，重構的原則就在於把Hibernate的配置和Spring的配置進行關注點分離。我們選擇hibernate.propertIEs對Hibernate的一些Global的選項進行指定。同時使用指定持久化類hbm配置文件路徑的方式，批量定義持久化類。重構後的配置文件變成了2個：
classpath*:persist/system
classpath*:persist/role
classpath*:persist/activity
classpath*:persist/extension
classpath*:persist/user
######################
### Query Language ###
######################
#################
### Platforms ###
#################
## MySQL
hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
hibernate.connection.url jdbc:MySQL://127.0.0.1:3306/test
hibernate.connection.username root
hibernate.connection.passWord root
## Oracle
#hibernate.dialect org.hibernate.dialect.OracleDialect
….
此時，我們可以發現，程序員可以獨立工作，不需要為增加持久化類修改公共配置而煩惱，hibernate.propertIEs也更加清晰的反映hibernate相關的配置。
一個典型的目錄結構如下：
如果你用這種方式來管理你的配置文件，有一個極大的好處就在於，不必再擔心你團隊的成員為找不到配置文件而發愁，他們被集中存放，集中管理了。
當然，任何事情不能做得過於偏激，有時候，我們需要package level的配置文件，例如struts的validation，類型轉化定義，i18n配置文件，等等。這些package level的配置文件，我們完全沒有必要把他們集中到一起，因為他們在各自的package中承擔著各自的作用。實際上，如果把他們集中到一起，反而會造成這樣那樣的問題，這些問題將會在第五點最佳實踐中有所涉及。
4. 選擇合理的配置類型，XML or Annotation or PropertIEs？
之前已經談到了盡可能簡化配置，其中的重要途徑是使用Annotation來代替XML進行配置。在這裡我想提出的是，XML和Annotation甚至是PropertIEs文件，他們都各自有各自的特點，我們可以根據實際情況，選擇最合適的方式進行配置。
比如說在Spring2.5中，XML配置可以被用作全局的，公共的配置，這些配置包括：DataSource定義、SessionFactory定義、事務定義等等。而Annotation可以被用作Bean定義，而無需在XML文件中一一指定。此時，兩者結合將成為一個比較好的選擇。
再比如Hibernate的全局配置，可以使用hibernate.properties，也可以使用hibernate.cfg.xml。但是properties文件無法指定持久化類，不過propertIEs文件在定義全局配置時，顯然比XML的語義性更強，也更容易編輯(你只要把Hibernate發行包中的模板propertIEs復制一份過來改一下就行了)
而hibernate的持久化類的配置，Annotation和XML的比較上，Annotation似乎更占上風。雖然個人不喜歡在Domain Object上加過多的Annotation，不過不得不說，在降低維護成本上，Annotation占有了絕對的優勢。可惜，hibernate的Annotation最大的缺點，就在於它的Annotation所定義的屬性，與XML定義的屬性是互相不兼容的，因而帶來了一定的學習成本。
5. 在團隊工作中，盡可能不要把團隊操作度很高的配置放到一個文件中
這條最佳實踐其實應該成為一條很重要的最佳實踐。因為merge代碼或者merge配置文件而給程序員帶來痛苦的情況是數不勝數的。因此，解決這個問題的最佳方案就是盡量把團隊操作度很高的配置文件拆分開。
在項目中，那些配置的團隊操作度很高呢？我大致考慮了以下一些情況：
1) 持久化類的配置在SessionFactory中的定義
2) web層的配置文件(struts-config.XML)等
3) 涉及到i18n的資源類文件
4) Spring中的Bean定義
第一條，如果使用XML進行持久化類的配置，那麼可以通過指定路徑來解決這個問題。如果你使用的是Annotation，那麼很不幸，當前還沒有可以通過指定帶有Annotation的持久化類的package的方式來簡化配置。當然，要自己實現一個似乎也並不困難，有興趣的朋友可以自己嘗試一下。
第二條，在Struts2中，已經提供了一些0配置的方案，通過使用這些方案，大家可以最大程度上降低配置的公用性。同時Struts2也支持將XML文件分開定義，每個程序員可以工作在自己那個模塊所在的XML文件上。
第三條，之前很多的做法，是在classpath下定義一個統一的資源文件，所有的資源信息都寫在一起，這會造成操作沖突的幾率很大。比較合適的做法，就是在Action的package level定義與這個Action相關的一些資源，這也是Struts比較推薦的做法。
第四條，如果你使用Spring2.5，可以使用Annotation來代替Bean定義。
6. 適度使用Annotation和CoC
這條是值得討論的。有關XML和Annotation的是是非非，在其他的帖子中經常有討論。我的觀點在於，對於公用的全局的配置，使用XML，而單獨的Bean相關的配置，使用Annotation。對於Domain Object的配置，個人傾向使用XML配置進行關注點分離。
談到CoC，這是一個懶人的時代，RoR中的一些約定大於配置的觀念也開始深入人心。不過在Java世界，這一點似乎還沒有完全被推開。甚至有人問我，這家伙寫的東西，怎麼連個配置文件都沒有，我哪裡知道誰對應誰呢。所以CoC，我想也有個度，甚至有時候，需要一定的Reference Doc進行說明，否則，過度的CoC，也會給許多人帶來困惑。
