昨天看了Idior的文章EnterLib ObjectBuild vs Castle WindsorContainer, part 1，聯想到我前面剛交付的一個系統，感觸頗爲深刻。在我那個系統的業務層只暴露了六個關鍵的接口，這些接口用於處理一些核心的運算：
>>實現運行時的URL計算；
>>在網格中打開相應的實體類；
>>在實體類中顯示到網格中的屬性轉換器；
>>在編輯器中使用相應的屬性編輯器。
實現這些接口，一共用了接近1000個內部類，有些類的實現甚至只需要一行代碼(例如從某個類派生但需要覆寫某一個方法以便更換約束子)。
爲了管理這些實現類，我建立了一個專門的枚舉，這個枚舉包括近100個項，囊括了整個業務層涉及到的所有層面。然後定義一個ServiceMasterAttribute的標籤，將這些類列到每個枚舉項上。在這個標籤的靜態構造器中，找到所有枚舉項的所有實現類，並通過專門的類進行管理，再通過Service類封裝這個管理器，得到一個簡單的API：
public static object Service.GetObject(TargetType targetType, Type expectType)
只需要將這個枚舉的定義與所有的實現類放在同一個程序集中，就完全可以將這些實現類隱藏起來。可以看出來，這種方式簡單而有效。
另外一個同事，負責整個系統的報表，採用一個自定義的控件來實現數據到HtmlTable的變換。在這個變換過程中，定義了一個接口，用於填充單元格的數據。在實現這個接口的過程中，根據項目實際又組織了六個內部接口，通過70多個類來實現這些接口，然後由這些接口通過專門的類來組織單元格填充接口。因爲系統業務層提供了一種非常方便的配置文件訪問方式，所以他採用配置文件來定位這些類，結果就冒出來一種很奇怪的現象：具體實現類必須public修飾以便配置文件管理可以拿到這些類型；而接口只是用來在內部以適配器方式接入單元格填充接口，反而只需要internal修飾。
所以，採用標籤方式所獲得的IoC具有通過配置文件所不具備的兩大優勢：
>>運行時類型檢查，設計時就可以避免拼寫錯誤這些低級的錯誤；
>>完全隱藏實現細節，只需要將接口暴露出來
標籤方式也存在一個缺點：不能通過修改配置來修改實現類，而必須重新編譯。
所以，如果你真的需要在運行時修改配置而不用重新編譯的話，就必須採用配置方式來定位類的實現。