.NET簡談構件系統開發模式

轉自[王清培] http://www.cnblogs.com/wangiqngpei557/archive/2011/06/14/2080416.html

在本人的「.NET簡談插件系統開發模式」一文中咱們詳細介紹了插件系統開發模式的優越性，儘管.NET平臺或者第三方提供的平臺都爲咱們實現了底層插件原理模型，咱們能夠在上面進行開發，做爲一名有求知慾的程序員纔是一名合格的程序員；咱們不能知足系統爲咱們提供的功能，咱們要向下沉，沉的越深越好，躲開那些應用變化給咱們帶來的勞累感，因此咱們是否須要掌握一些別人不會的技術，才能讓咱們在衆多的程序員中脫穎而出呢；

咱們今天來探討「構件」系統開發模式，其實各類各樣五花八門的設計模式開發模式追求的目標都是同樣的，讓咱們開發出來的軟件系統能知足突飛猛進的變化，這樣的變化可能來自應用需求、系統支撐需求、安全需求等等，只有具有以不變應萬變的機制，咱們的軟件才能在這樣的環境中長期生存下去，軟件工程的誕生爲咱們帶來了工程化的開發管理方式，其實咱們的軟件系統不比那些高樓大廈開發簡單，相比之下要複雜的多，亞歷山大的「建築的永恆之道」就想讓咱們的建築在時間的流逝中變得更完美，更古典更適合當前的環境；咱們的軟件也是同樣，儘可能作到以不變應萬變的境界，可是這樣的境界多是咱們很難達到的，不可能一勞永逸；技術的發展太快了，人的精力有限，沒辦法學會全部的東西，只能努力去作；

構件系統模型的思想在不少書籍中都提到過，讓咱們的軟件系統能經過不斷組裝來實現更新換代，將系統的實現分解成不一樣的「構件」，本人正在用這種模式在開發一個本身的系統，以爲前期的框架的很是耗時，可是以爲這樣的框架很穩定，在不斷的維護更新下我能發揮出驚人的「機械感」，全部的零件都能拆卸、跟換、組裝、運行，自我感受很好；咱們要把本身當成一名工程師，要讓咱們設計出來的軟件就比如那些「超跑」同樣能在寬敞的大道上風靡起來，代碼可能都同樣，就要看怎麼設計了，那些跑車機械工程師們都是咱們學習的對象，他們熱愛本身的職業，咱們也要熱愛本身的職業，程序員是值得驕傲的職業，至少我這麼認爲；

構件系統開發模式，能在不斷螺旋變化中，適應新的環境或者說是惡劣的環境，咱們來看一副整體結構圖：

將系統的全部功能點分解成不一樣的構件，構件分解的粒度就要看我的技術經驗了，因爲不一樣的系統粒度也不同；咱們經過構件頭統一啓動全部的構件，這些構件都可以無限向下傳遞實現，咱們公開一組程序的詳細功能接口，而後由不一樣的構件去實現，當實現好了以後咱們經過構件裝配配置文件統一加載運行，配置文件只須要維護一層構件關係，就拿咱們上圖講，配置文件只須要維護構件1.一、1.二、1.3三個構件，而若是1.1構件未能實現它自己應該實現的功能則這部分的責任它本身負責，咱們會用同一構件接口作入口點，進入每個一級構件，後面的每一個一級構件的內部該怎麼實現就怎麼實現；

這是本人系統中的簡單的結構設計圖，咱們公佈一組構件要實現的接口，而後讓實現者去實現；構件系統和插件系統是有明顯區別，構件系統是無限實現的，請看我項目的代碼圖：

上圖中，我將全部的構件都列出，要進行這種結構設計的朋友必定要很清楚本身的每一塊的做用，不能多也不能少，多了就是禍害，少了就不完美致使每一個構件沒法串聯起來；爲了進行這種結構設計，咱們少不了配置文件；

因爲大型的系統可能存在N多個構件，咱們有必要用XML命名空間進行區分以避免節點重名衝突；系統啓動的時候咱們讀取配置文件進行構件加載，下面咱們來看一下構件是怎麼無限向下傳遞實現的；

全部的一級構件是構件頭所要負責加載運行的，而當控制權到了某一個構件內部的時候由該構件去加載它的字構件；這裏有個問題你們須要特別注意，當父構件要讓子構件去實現某些功能的時候，只須要公開一組接口就好了，讓後經過接口名稱加載子構件；

[王清培版權全部，轉載請給出署名]