IoC避不開的一個問題是如何處理應用程序的模塊化, 因為IoC通常針對單個對象提供了良好的支持, 比如依賴管理,生命周期管理,部署時配置甚至運行時配置, 但往往一組內聚的互相協作的對象才構成應用程序基本的構建塊. 這組內聚對象間的協作關系是實現細節, 包括單個對象的構造函數和屬性也是, 如果把這些暴露出來, 固然可以提高靈活性, 但是以最后的部署階段的復雜性以及難以維護性為代價的. 以配置文件為例, 可能需要在包含了幾百個對象定義的配置文件中, 去改動七八個屬性, 變換五六個實現, 來適應不同的運行環境
兩個解決這個問題的方向, 一個是IoC框架提供模塊化支持, 以及部署時支持, 一種是IoC框架應該避開這個問題, 這本不屬于IoC的范圍, 應該交由專門的模塊化框架如OSGi去解決
在我相對熟悉的IoC框架中, Autofac試圖提供"Module"這個概念來解決一部分問題. 對象間的協作可以隱藏在Module對象中, 一些必要的參數可以通過Module的屬性設置進來, 而對使用者,對部署只需暴露Module對象即可. 這是以喪失靈活性為代價的, 替換某個內部對象的實現變成了Hack, 需要通過團隊成員間的交流, 源代碼集體所有來完成. 如果在Module對象內部枚舉擴展點的所有實現, 通過部署時的參數來挑選某個實現, 則會引入不必要的依賴, 更是得不償失
個人傾向于第二種. 誰介紹一下.Net平臺上的模塊化框架?
所以相對聚焦一點, 了解一下IoC框架在處理單個對象的時候所需要解決的問題
1, 部署時如何方便的支持產品環境和測試環境, 即在不同環境下提供同一接口的不同實現
這個甚至不需要IoC框架解決, 應用開發人員在不同環境下提供不同配置文件即可. 那問題變成了
2, 如何簡化配置, 使得框架能夠自動識別依賴
這個被稱為Auto wire, 一般根據構造函數參數或屬性的類型來匹配依賴. 那么帶來的一個問題是
3, 運行時如何動態切換同一個類型的不同實現, 比如用戶選擇了只讀模式, 那么所有的Save操作都應被忽略不做任何事, 可以通過提供Save操作的Dummy版本來實現
Auto wire根據類型匹配有一定的局限性, 即同一個運行時環境有某個接口的多個實現怎么辦. 這里實際上有一個概念, 即對象的標識. 而類型只是標識的一種. 另外一種適應性更廣的標識是字符串. 有的框架稱之為ID, 有的稱之為name. 標識的重要特征就是在一個運行時環境里是唯一的. 類型標識因此也可以轉化為字符串標識, 取其全名就可以了. (標識本身是個概念, 可以用一個類來表達, 然后有不同的子類實現, 如基于類型的標識, 基于字符串的標識等)
因此就有兩種策略: 一種是允許運行時某個對象可以重新聲明依賴的標識, 一種是運行時用同樣標識的對象替換原先的實現. 后一種相對容易實現一點, 按注冊順序Last One Win就可以了
如果同一個類型的多個實例需要同時存在, 則部署時給予不同的ID即可. 然而另一個問題是
4, 多用戶環境下, 如何保證每個用戶都有自己的對象組合而不互相干擾
IoC框架一般被稱為IoC容器. 容器這個概念是對運行時環境,上下文的封裝, 提供了一組基礎設施, 以及運行時所需的各種服務, 最重要的一點是, 它提供了在同一個進程里的隔離. 多用戶環境下, 可以創建多個彼此獨立的容器, 每個容器負責創建所需的對象, 提供所需的服務, 彼此之間互不影響. 于是帶來新的問題,
5, 對象的生命周期如何管理
很顯然, 有的對象概念上屬于全局, 在程序運行過程中不能創建多個實例, 也不能被銷毀. 有的跟用戶的一次操作, 一次請求相關聯, 同一次請求中可以復用同一個對象實例, 但不同請求必須創建不同的對象實例. 有的則每次需要訪問它的時候都得創建一個新的實例. 容器必須提供基礎設施, 讓應用開發者可以指定對象的生命周期, 并在周期結束時銷毀所有該銷毀的對象. C# 提供了 Dispose 機制, 可供利用
其它的一些問題, 比如:
- 如何支持composite, decorator, proxy模式
- 如何方便用戶注冊, 包括自動注冊
- 如何注入容器創建的對象到用戶手工創建的對象中
- 如何與現有各種框架集成
- 如何避免循環引用: Constructor/property dependencies
- Open generics injection
- List injection Unregistered resolution
- Auto-mocking
- Startable
- Strongly-typed Activation Events
- Adding to an Existing Container