軟體的體系架構摘要

標籤：

摘錄原文連結：天極網

 常見的軟體體系架構

　　l 三層體系架構

　　在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。分層式結構一般分為三層，從下至上分別為：資料訪問層、商務邏輯層(又或成為領域層)、展示層，：

　　

　　圖2 三層體系架構

　　資料訪問層：有時候也稱為是持久層，其功能主要是負責資料庫的訪問。簡單的說法就是實現對資料表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那麼就會包括對象和資料表之間的mapping，以及對象實體的持久化。

　　商務邏輯層(BusinessRules)：是整個系統的核心，它與這個系統的業務(領域)有關。以STS系統為例，商務邏輯層的相關設計，均和銷售跟蹤的邏輯相關。在結構上它封裝了資料訪問層的相關操作。該層主要由實現具體商務邏輯的類組成。

　　展示層(WebUI)：是系統的UI部分，負責使用者與整個系統的互動。在這一層中，理想的狀態是不應包括系統的商務邏輯。展示層中的邏輯代碼，僅與介面元素有關。在當前項目中，是利用ASP.NET來設計的，因此包含了許多Web控制項和相關邏輯。

　　l 五層體系架構

　　SaaS軟體體系架構也可以分為五層，從上而下分別為：使用者介面層(表現層)、商務邏輯層、通用層、應用程式框架層、遠端存取(WebService)層、資料訪問層，：

　　

　　圖3 基於微軟的.NET架構設計

　　使用者介面層(UI)

　　使用者介面層是使用者直接操作的介面。該層由介面外觀、表單控制項、架構及其它部分構成。使用者介面層負責使用者與整個系統的互動。在這一層中，理想的 狀態是不應包括系統的商務邏輯。展示層中的邏輯代碼，僅與介面元素有關。在當前項目中，是利用ASP.NET來設計的，因此包含了許多Web控制項和相關邏 輯。

　　² 介面外觀包括skip(皮膚)、Images(圖片)、css(樣式表)

　　² 表單控制項主要包括常用表單、使用者自訂控制項。

　　² 架構主要包括Master Page、Frame Page。

　　² 其它主要包括JavaScript檔案、Dll檔案、Report報表、Schema建資料庫、Model開發模板。

　　商務邏輯層(BusinessRules)

　　是整個系統的核心，它與這個系統的業務(領域)有關。以STS系統為例，商務邏輯層的相關設計，均和銷售跟蹤的邏輯相關。在結構上它封裝了資料訪問層的相關操作。該層主要由實現具體商務邏輯的類組成。

　　² BLFactory 商務邏輯工廠

　　² IBL 商務邏輯介面

　　² BusinessRules 商務邏輯實現

　　通用層

　　通用層貫穿整個項目的展示層和商務邏輯層。主要存放該項目中較為通用的常量定義和泛型服務(Service)，這裡指的Service是當前項目商務邏輯上通用的方法，我們把它們寫在對應的靜態類中。以服務的形式提供。

　　CommonLayer：存放通用的常量及方法。

　　資料訪問層

　　該層結構是最複雜的，主要由以下層組成：資料訪問工廠層(DALFactory)，資料提供者層(IDAL)，自訂查詢層(PersistenceFacade)，臨時層(DataAccessLayer)，資料持久層(PersistenceLayer)。

　　下面由下向上介紹：

　　² PersistenceLayer層，這是架構設計的最底層(除應用程式框架層外)。它主要負責用ORM思想將物理資料庫物件化。簡單來說就是將資料庫表映射 為實體類，將相應的欄位對應為類的屬性。這樣一來物理資料庫對於開發人員是完全透明的，應用ORM的思想我們徹底擺脫了物理資料庫。並且獨立於資料庫具體實 現。

　　² 具體實現我們應用著名的開源項目Castle下的輕量級資料訪問組件ActiveRecorder實現。

　　² PersistenceFacade層和IDAL，這裡定義了項目中用到的所有查詢方法。與PersistenceLayer層定義的資料實體相對應。在 這些字定義的查詢類中可以應用ActiverRecorder提供的三種查詢方法(ActiverRecorderBase提供的簡單介面，簡單查詢 SimpleQuery，自訂查詢CustomerQuery)的任意組合。並且這裡的每一個類都要實現IDAL介面層定義的相關介面。

　　² DALFactory層，做為資料訪問的工廠，通過.Net的反射機制調用IDAL和PersistenceFacade組成的資料訪問組件中的相關操作。

　　² DataAccessLayer臨時層。首先聲明這層是完全沒有必要的。因為我們在項目中是可以不寫任何Sql語句的。所有的Sql都用Hql代替。設計 這層的目的是為了允許項目組中的人員的技術過渡。此層可以通過Sql操作資料庫(不推薦)。架構穩定後本層將不再提供。

　　應用程式框架層(Framework)

　　本層的目的是技術沉澱。將項目之間通用的東西移入應用程式框架層達到代碼重用的目的。本層以後可以黑盒化。可以包括通用的組件。

　　² Framework：積累一些可以抽象出來的方法及控制項

　　² MSMQMessag：訊息處理隊列的實現

　　² Pager：通用翻頁類

　　² Report：通用報表類

　　² Controls：控制項處理類

　　² DataFormat：資料格式轉換類

　　² WebUI：頁面處理類

　　² Validate：資料校正

　　² Object：對象之間的轉換及訪問

　　5 分層式體繫結構的好處

　　1、開發人員可以只關注整個結構中的其中某一層;

　　2、可以很容易的用新的實現來換原有層次的實現;

　　3、可以降低層與層之間的依賴;

　　4、有利於標準化;

　　5、利於各層邏輯的複用。

　　概括來說，分層式設計可以達至如下目的：分散關注、鬆散耦合、邏輯複用、標準定義。

　　一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。例如UI人員只需考慮使用者介面的體驗與操作，領域的設計人員可以僅關注商務邏輯的設計，而資料庫設計人員也不必為繁瑣的使用者互動而頭疼了。每個開發人員的任務得到了確認，開發進度就可以迅速的提高。

　　鬆散耦合的好處是顯而易見的。如果一個系統沒有分層，那麼各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發生改變，則牽 一發而動全身，對項目的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴充，在複用性上也是優勢明顯。每個功能模組一旦定義好統一的接 口，就可以被各個模組所調用，而不用為相同的功能進行重複地開發。

　　進行好的分層式結構設計，標準也是必不可少的。只有在一定程度的標準化基礎上，這個系統才是可擴充的，可替換的。而層與層之間的通訊也必然保證了介面的標準化。

　　“金無足赤，人無完人”，分層式結構也不可避免具有一些缺陷：

　　1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中介層來完成。

　　2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在展示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的商務邏輯層和資料訪問層中都增加相應的代碼。

　　6 軟體架構視圖

　　Philippe Kruchten在其著作《Rational統一過程引論》中寫道：

　　一個架構視圖是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了於此方面無關的實體。

　　也就是說，架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力範圍，因此採用“分而治之”的辦法從不同視角分別設計;同時，也為軟體架構的理解、交流和歸檔提供了方便。

　　

　　圖4 Philippe Kruchten提出的4+1視圖方法

　　該方法的不同架構視圖承載不同的架構設計決策，支援不同的目標和用途：

　　l 邏輯視圖：當採用物件導向的設計方法時，邏輯視圖即物件模型。

　　l 開發視圖：描述軟體在開發環境下的靜態組織。

　　l 處理視圖：描述系統的並發和同步方面的設計。

　　l 物理視圖：描述軟體如何映射到硬體，反映系統在分布方面的設計。

　　

　　圖5 運用4+1視圖方法針對不同需求進行架構設計

　　邏輯視圖。邏輯視圖關注功能，不僅包括使用者可見的功能，還包括為實現使用者功能而必須提供的“協助工具功能模組”;它們可能是邏輯層、功能模組等。

　　開發視圖。開發視圖關注程式包，不僅包括要編寫的來源程式，還包括可以直接使用的第三方SDK和現成架構、類庫，以及開發的系統將運行於其上的系統軟體或中介軟體。開發視圖和邏輯視圖之間可能存在一定的映射關係：比如邏輯層一般會映射到多個程式包等。

　　處理視圖。處理視圖關注進程、線程、對象等運行時概念，以及相關的並發、同步、通訊等問題。處理視圖和開發視圖的關係：開發視圖一般偏重程式包 在編譯時間期的靜態依賴關係，而這些程式運行起來之後會表現為對象、線程、進程，處理視圖比較關注的正是這些運行時單元的互動問題。

　　物理視圖。物理視圖關注“目標程式及其依賴的運行庫和系統軟體”最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠 性、延展性等要求。物理視圖和處理視圖的關係：處理視圖特別關注目標程式的動態執行情況，而物理視圖重視目標程式的靜態位置問題;物理視圖是綜合考慮軟 件系統和整個IT系統相互影響的架構視圖。

軟體的體系架構摘要