在一些專案開發中，為了使專案具有靈活配置的特性通常會使用配置檔案，把一些常用的屬性資料通過配置檔案的方式引入系統。然而，當這些屬性檔案中資料變得越來越多的時候，問題還是出現了。
加入配置檔案的資料總結起來大致有以下幾類：系統屬性（比如系統首頁位址等）、通用屬性（比如性別等）、行業屬性（比如官銜等）、以及使用者自定義屬性等。剛開始的時候，可能專案比較小，而且只是針對單一客戶的，當客戶有了修改這些屬性資料的需求時，就直接去修改屬性配置檔案，誰也不願意去考慮這寫資料儲存在屬性配置檔案中到底合適不合適。可是，隨著專案逐漸完善，不同模組之間的屬性配置檔案個數越來越多，檔案也變得越來越大，維護的工作量也相應增多，屬性配置檔案的問題就暴露出來了。
無論是使用properties檔案，還是xml檔案，或者其他的屬性配置檔案，當檔案個數變多，資料量變大之後，維護起來都很費勁。尤其是專案面臨產品化的時候，乙個專案做成熟之後，可能會被很多客戶使用，不同的客戶有不同的屬性配置需求，如果有幾百甚至幾千個客戶，屬性檔案修改的工作量可想而知，給專案實施增加了不少難度。其實，最嚴峻的問題還不在這裡，由於屬性配置檔案裡儲存的資料都是由固定格式要求的，如果格式錯亂就不能正常解析，所以在修改屬性配置檔案的時候還需要額外小心，否則可能就會造成系統異常。
對於屬性配置檔案暴露出來的問題，我個人認為，需要把系統屬性相關的資料進行分類處理。我們不能單純地認為因為屬性配置檔案有問題就不能用，更重要的是要搞清楚哪些資料才適合放在屬性配置檔案裡。對於系統屬性，如果是個性化的系統屬性盡量不要放在屬性配置檔案中，包括行業屬性，因為不同的地區可能同乙個行業的業務也多多少少有差別，這些資料可以通過系統中的系統維護模組運算元據庫來維護。而對於通用屬性，相對比較固定，則可以通過屬性配置檔案來維護。可能對於一些小專案來說，系統維護模組還沒有，但是對於乙個成熟的專案，我個人認為，還是有必要包含系統維護模組的，提供一些維護系統的常用功能。
SUG UAP專案中配置檔案解析
等檔案，這些天做專案也沒少更改這些檔案下面就簡單的介紹一下，算對自己工作的乙個總結。datasource.xml 眾所周知的資料庫配置檔案，在這個平台下也是這樣 中的位址是本地的資料庫位址 使用者名稱和密碼。在公司工作的時候使用的資料庫在伺服器上，回家後加班工作需要使用資料庫只好把資料庫搞到本地乙份...
SpringBoot專案中獲取配置檔案的配置資訊
假如我們配置檔案.yaml的資訊是 myconfig username abc password 123或者.properties myconfig.username abc myconfig.password 123類需要被spring掃瞄到 component public class myco...
專案中讀取配置檔案工具類
public class calcitedruidpropertyutil catch ioexception e 根據key獲取value public static string getdruidprop string key classpath路徑即 target classes目錄 1.cl...