建構插件式的應用程式架構(四)－服務容器

IApplication接口是派生于IServiceContainer接口的。為什麼要派生于IServiceContainer呢？我們來看看IServiceContainer的定義，它有幾個AddService方法和RemoveService方法以及從IserviceProvider繼承過來的GetService方法。Service本身是.NET設計時架構的基礎，Service提供設計時對象通路某項功能的方法實作，說起來還真拗口。就我看來，ServiceContainer機制的本質就是解耦合，就是将類型的設計時功能從類型本身剝離出來。如果你把類型的設計時功能也封裝到類型裡，這樣的類型包含了很多隻有開發人員才會用到而最終使用者根本不需要的功能，使得類型既臃腫有不便于擴充。而将設計時功能剝離出來，這樣類型就可以不依賴于特定的設計環境，之是以現在有這麼多非官方的.NET設計環境可能就是這個原因吧。

我們的插件式的應用程式架構正好也需要這樣一個松散的架構，我就移花接木把它應用到我們的架構中。

ServiceContainer是.NET提供的IserviceContainer的實作，如果沒有特殊的需要我們不必擴充它，而是直接的利用它。在上一篇文章中我們在實作IApplication接口的時候就直接使用的ServiceContainer。我們在使用Service架構的時候，總是傾向于有一個根容器，各個Service容器構成了一個Service容器樹，每一個節點的服務都可以一直向上傳遞，直到根部，而每一個節點請求Service的時候，我們總是可以從根節點獲得。我把這個根節點比喻成一個服務中心，它彙總了所有可提供的服務，當某個對象要請求服務（GetService）隻需要向根結點發送要獲得的服務，根結點就可以把服務的對象傳遞給它。

從另外一個角度看，ServiceContainer為我們的插件是應用程式提供了有力的支援，利用ServiceContainer，你不但可以獲得應用程式所提供的所有的功能，而且你還可以通過插件向應用程式添加Service，而你添加的Service又可以服務另外的Service，這樣我們的應用程式架構就更加的靈活了。但是任何東西都是有兩面性的，帶來靈活的同時也為開發人員的工作增加了複雜度，是以使用ServcieContianer開發的應用程式必須提供足夠詳細的文檔，否則開發人員可能根本不知道你到底有多少Service可以用，因為很多的Service是通過插件提供的，可能應用程式的作者都不會知道程式釋出以後會出現多少Service。