軟體體繫結構風格是描述某一特定應用領域中系統組織方式的慣用模式,層次系統風格即為其中一種,本文描述了一種適用於B/S、C/S混合情境的、基於層次系統風格的系統架構解決方案。
一、 層次架構
整個系統可劃分為儲存層、規約層、實現層、注入層、Web展示應用程式層、Web服務應用程式層、Client應用程式層共計七個層次,其中儲存層一般對應關聯式資料庫,其餘六層是我們關注的重點。
圖1:層次架構圖示
將系統整體視作一個解決方案(Solution),觀察可知,該解決方案主要包括下述九個開發項目(Project):
- Demo.Core:核心程式集,包含商務邏輯介面、資料提供者和實體類;
- Demo.Managers:商務邏輯層的具體實現;
- Demo.Daos:資料訪問層的具體實現,必要時可根據資料庫類型進一步細分;
- Demo.IoC:依賴注入的實現,推薦採用Spring.NET,也可以引入原廠模式以反射的方式實現;
- Demo.Controllers:基於MVC思想設計與Web介面對應的控制器,為ajax互動提供支援,不推薦採用SOAP方式;
- Demo.WebUI:瀏覽器端介面,包含html、css、js和圖片,遵循統一的介面規範;
- Demo.WebService:對外發布的web服務,供用戶端(Client)或其它應用程式調用,推薦使用SOAP方式,可專門為.NET調用者封裝WCF服務;
- Demo.ServiceProxy:web服務代理,它將實現商務邏輯介面封裝Web Service的調用,是實現層的一個特例,供用戶端(Client)或其它應用程式直接引用;
- Demo.ClientUI:PC用戶端使用者介面,同理可引入Demo.MobileUI用作手機用戶端。
單元測試並未納入上述層次架構,在實際應用中應該再添加一個Demo.UnitTest開發項目,該項目將針對Demo.Core中定義的介面編寫測試案例,這些測試案例將用作Demo.Managers、Demo.Daos項目具體介面實作類別的驗收標準。
二、 編譯依賴
“層次架構”中涉及的九個開發項目之間存在一定的編譯依賴關係,如所示,箭頭標明了依賴性:
圖2:編譯依賴圖示
Demo.Core不依賴其他項目;Demo.Managers 、Demo.Daos、Demo.IoC均依賴於Demo.Core;Demo.Controllers、Demo.WebService依賴於 Demo.Core和Demo.IoC;Demo.WebUI依賴於Demo.Controllers;Demo.ServiceProxy需要添加 Demo.WebService中web服務的引用,並非編譯依賴,故以虛線表示;Demo.ClientUI依賴於Demo.Core和 Demo.IoC。
此外,Demo.WebUI、Demo.WebService的正常運行需要Demo.Managers和Demo.Daos的支撐,Demo.ClientUI的正常運行需要Demo.ServiceProxy的支撐,這種支撐將以IoC的方式配置注入,因而不存在編譯依賴關係。
三、 應用發布
Web展示應用程式層、Web服務應用程式層、Client應用程式層可統稱應用程式層,因而在應用發布商,存在Web網站、Web服務網站、Client程式三個執行個體,且前兩個可以二合為一。
圖3:應用發布圖示
四、 外部參考
在應用系統開發過程中,對外部程式集的引用是一種典型現象,這裡將其歸納為實現層協助工具輔助、商務邏輯路由、面向切面附加三類。
- 實現層協助工具輔助:在資料訪問層(Demo.Daos)引入Spring.Data或Hibernate處理資料的存取。
- 商務邏輯路由:假設系統直接使用LDAP使用者庫,則可以添加一個實現了商務邏輯介面的適配器,將使用者處理請求轉交給LDAP伺服器處理。
- 面向切面附加:面向切面即AOP,假設系統需要添加日誌功能記錄所有的商務邏輯操作,則可以添加一個商務邏輯介面實作類別(AgentManager),該類持有另外一個介面實作類別的引用(RealManager),AgentManager並未真正實現介面要求的方法,而是轉交給RealManager處理,轉交前後可加入日誌記錄代碼。
五、 架構演變
某些情況下,我們可能需要在用戶端本機快取部分資料,此時Client程式將包含真正的商務邏輯和資料訪問功能(上文Client涉及的業務請求是由服務代理轉交Web Service處理的),Client應用程式層架構將演變為結構。
圖4:Client演變圖示
儲存層一般採用檔案級的資料庫(例如SQLite),規約層、注入層、實現層的Demo.Managers 和Demo.Daos均為通用項目。注入層將同時控制注入遠端處理邏輯(Demo.ServiceProxy)和本地處理邏輯,Demo.ClientUI根據需要自由選擇,或者直接做一個商務邏輯適配器實現自動路由。
六、 結束語
本文旨在闡述一種松耦合的架構方案,指導思想是面向介面、生產者/消費者模式,規約層以介面為核心定義標準,實現層定位為生產者,應用程式層為消費者。在實際應用中,上文涉及的開發項目(Project)均可進行適度的合并或拆分。