代碼配置 vs. 設定檔

代碼配置 vs. 設定檔
另一個問題相對獨立，但也經常與其他問題牽涉在一起：如何佈建服務的組裝，通過設定檔還
是直接編碼組裝？對於大多數需要在多處部署的應用程式來說，一個單獨的設定檔會更合適。
設定檔幾乎都是XML 檔案，XML 也的確很適合這一用途。不過，有些時候直接在程式碼中
實現裝配會更簡單。譬如一個簡單的應用程式，也沒有很多部署上的變化，這時用幾句代碼來配
置就比XML 檔案要清晰得多。
與之相對的，有時應用程式的組裝非常複雜，涉及大量的條件步驟。一旦程式設計語言中的配置邏輯
開始變得複雜，你就應該用一種合適的語言來描述配置資訊，使程式邏輯變得更清晰。然後，你
可以編寫一個構造器（builder）類來完成裝配工作。如果使用構造器的情景不止一種，你可以
提供多個構造器類，然後通過一個簡單的設定檔在它們之間選擇。
我常常發現，人們太急於定義設定檔。程式設計語言通常會提供簡捷而強大的組態管理機制，現代
程式設計語言也可以將程式編譯成小的模組，並將其插入大型系統中。如果編譯過程會很費力，指令碼
語言也可以在這方面提供協助。
通常認為，設定檔不應該用程式設計語言來編寫，因為它們需要能夠被不懂編程的系統管理人員編
輯。但是，這種情況出現的幾率有多大呢？我們真的希望不懂編程的系統管理人員來改變一個複
雜的伺服器端應用程式的事務隔離等級嗎？只有在非常簡單的時候，非程式設計語言的設定檔才有
最好的效果。如果配置資訊開始變得複雜，就應該考慮選擇一種合適的程式設計語言來編寫設定檔。
在Java 世界裡，我們聽到了來自設定檔的不和諧音——每個組件都有它自己的設定檔，而
且格式還各各不同。如果你要使用一打這樣的組件，你就得維護一打的設定檔，那會很快讓你
煩死。

在這裡，我的建議是：始終提供一種標準的配置方式，使程式員能夠通過同一個編程介面輕鬆地
完成配置工作。至於其他的設定檔，僅僅把它們當作一種可選的功能。藉助這個編程介面，開
發者可以輕鬆地管理設定檔。如果你編寫了一個組件，則可以由組件的使用者來選擇如何管理
配置資訊：使用你的編程介面、直接操作設定檔格式，或者定義他們自己的設定檔格式，並
將其與你的編程介面相結合。