基于IoC思想設計的系統架構
作者：成曉旭
http://blog.csdn.net/CXXSoft/
(聲明：版權保留，歡迎轉載、請保證文章完整性)
1. 引言
Java領域的開發人員，可以采用spring開源框架，快速構建自己的業務應有系統，本人羨慕不已。但是在我采用的傳統開發語言、專業應用領域，都沒有這樣的好框架可以沿用。于是早有自己設計一個IoC框架，適用于本人涉及的實時監控、通信采集領域。
“他山之石、可以攻玉”。其實IoC、DI等的分析、設計理論未必非要用來構架通用的基礎開發框架，在具體的應有系統開發中借用，同樣能構建靈活的系統體系架構，尤其是對于企業戰略性的長期的產品、系統的構建，更是事半功倍。
2. 系統背景簡介
在實時監控、數據采集等通信類系統中，通常的設計都是：將數據采集或者與底層邏輯單元（比如：底層的軟件子系統、硬件終端、遠程設備）通信的邏輯功能獨立封裝在一個子系統中，實現基礎通信收發、通信方式分化、通信流程控制、底層協議規整、基礎數據整合等網絡通信、數據采集職責。
本設計是針對常見的實時監控、數據采集系統。下面以一個典型的通信采集服務器應有為例：系統的底層是硬件采集設備，硬件設備完成整個系統與外界環境或者設備的交互；上層的軟件系統完成與自己硬件設備的交互，并且對采集的數據進行分析、處理、存儲、與外部系統接口。
3. 問題
在我工作的軟件項目中，類似的應用存在于多個軟件系統中，雖然這些系統在子系統設計及職責劃分方面也如上圖一般進行了明確的分層及模塊化，但在核心的“通信采集子系統”的設計及實現上存在諸多通病，導致整個子系統的可理解性、可維護性、可測試性、對需求變動的適應性極差。集中表現在：
1. 整個系統被設計成一個“非常龐大”的“業務調度控制類”，沒有進行職責的拆分和封裝；
2. 在通信方式實現類（比如：串口通信類、語音卡控制類、TCP/IP通信類）中完成所有業務處理功能；（絕大多數板卡廠商Demo程序是這樣演示的，有意無意間誤導了很多剛剛接觸CTI、IVR系統開發的入門者）
3. 對于多任務并發，多個設備上、下行同時通信的管理非常復雜；
4. 對于需求變化的適應性非常差；
5. 系統代碼幾乎沒有可復用性了。
4. 新問題
針對上述問題，總結、分析以往經驗和教訓，以“代碼復用”為出發點重新設計了通信采集系統體系架構，并較好地解決這些突出問題，并梳理出大量可復用的功能代碼。詳細說明請參考《一個典型的采集服務器體系結構設計》一文：http://blog.csdn.net/cxxsoft/archive/2006/09/18/1236331.aspx。
但是，后來再次開發通信采集服務器，以應有于不同的業務需求時，發現原來的架構存在如下的典型問題：
1、“采集控制器”幾乎不能重用、但與新開發的采集控制模式非常相識。但是，每次新開發的“采集控制器”邏輯都非常相識，但必須修改業務采集類的類名和方法名，修改狀態機的轉換關系，修改協議調用的類名和方法名。
2、“業務采集類”的變化，會直接影響到“采集控制器”。
3、“通信協議類”的變化，會直接影響到“采集控制器”。
4、通信控制流程、時序的變化，會直接影響到“采集控制器”。并且要正確實現這些變化，必須在與此無關的“采集控制器”中，小心翼翼地扣代碼出來改。
5. IoC重構設計
開源的通用采集服務器，是在原有系統架構的基礎上，增加業務抽象接口，引用IoC的設計理念，倒置交互類之間的依賴關系，采用DI來實現類之間的依賴關聯的動態關聯。
1、 抽象“業務調度核心類”的核心邏輯流程，將所有類方法的調用設計成對接口方法的調用。
2、 抽象“采集控制類”的核心邏輯流程，將所有類方法的調用設計成對接口方法的調用。“采集控制器”類被設計成一個通用的“工控機主板”，只要遵循“主板”約定的接口，換插不同的“業務采集類”、“通信協議類”，可以實現完全不同的采集業務需求、按照完全不同的通信協議與底層模塊通信。
3、 將“采集控制類”中的狀態機管理邏輯剝離出來，將狀態機檢測和控制代碼設計成對接口方法的調用。只要遵循狀態機接口，可以靈活實現不要業務需求的狀態轉換控制，在運行期動態創建狀態機實例，并注入到“采集控制類”，完全接觸“采集控制器”與“業務狀態機類”靜態依賴。
4、 去掉“通信適配器”、“協議適配器”，增加“通信接口”、“協議接口”和“業務接口”，按照接口要求重構通信類、協議類、采集業務類，解決原來系統架構中：新增一種通信方式、通信協議時，還必須在相關的適配器中增加新類型識別代碼的設計弊端。
6. 技術基礎與規約
本設計的核心的設計原理：IOC容器根據反射機制動態創建實現約定接口的業務對象，動態注入到采集調度控制器中。采集調度控制器是一個高層次抽象的Active Class，自動不斷地調用狀態機接口方法來執行“業務采集類”要求的業務通信指令。
本設計的核心的重要設計約定：采集調度控制器只調用抽象的接口方法，那么具體的上層業務任務，如何動態的翻譯成具體的通信協議？又如何知道當前的任務如何開始，何時結束？本設計要求：業務采集類必須管理好自己的業務步驟與通信協議之間的對應關系（確實非常難以在抽象，用動態配置的方法使用起來反而更復雜），采集調度控制器只負責動態建立兩者之間的運行期對象關系。業務采集類必須實現采集調度控制器要求的指定接口方法，用以實現采集任務的發起、執行下一條指令、結束、異常重發、異常中止、故障處理等采集流程控制功能。這正好是采集調度控制器高層抽象的價值和通用性的設計基礎。
框架使用者只需按照接口約定，編碼實現具體業務需求的相關采集、狀態機、協議業務類；在配置這些類的運行期參數，采集服務器大功告成。采集服務器在允許時，會自動加載配置參數，動態創建相關的業務邏輯對象，并完成依賴注入，整個系統能按具體的業務要求完成通信、采集任務。
7. 采集服務器設計
通信采集服務器是常常是實時監控、數據采集類系統的核心，實現與底層的軟件子系統、硬件終端、遠程設備的通信、下行命令的執行、上行數據的接收、協議解析，并且完成業務數據的分析以及顯示驅動。它既是系統的通信樞紐，也是業務核心。
