1 系統體系架構設計
軟件開發中系統體系架構決定了一個系統穩定性、健壯性、可擴展性、兼容性和可用性，它是系統的靈魂。體系架構是架構師所關注的核心。良好的體系架構是系統成功的開端，否則，再好的代碼與設計也無濟於事。
2 當前.net主要的開發框架簡介
l Castle
Castle是針對.NET平台的一個開源項目，從數據訪問框架ORM到IOC容器，再到WEB層的MVC框架、AOP，基本包括了整個開發過程中的所有東西，為我們快速的構建企業級的應用程序提供了很好的服務。其中關鍵的技術是ActiveRecord，Facilities，MonoRail等等。
優點：體現了ORM、IOC、ActiveRecorder思想，MVC框架。
不足：框架層次划分不太清楚。
l PetShop
PetShop是微軟用它來展示.Net企業系統開發的能力。PetShop4.0，這個實例是Microsoft針對SQL Server 2005 以及Visual Studio 2005發布的。其中運用了一些新的技術。緩存數據與數據庫的更新同步，新的Web控件，以及母版的應用，異步通訊，消息隊列。這些都是很實用的技術。PetShop中大量運用了抽象工廠模式，由於采用了Master Pages，Membership，以及Profile，表現層的編碼量減少了25%，數據層的編碼量減少了36%。
圖1 PetShop4.0的體系架構
PetShop4.0在數據訪問層(DAL)中，采用DAL Interface抽象出數據訪問邏輯，並以DAL Factory作為數據訪問層對象的工廠模塊。對於DAL Interface而言，分別有支持MS-SQL的SQL Server DAL和支持Oracle的Oracle DAL具體實現。而Model模塊則包含了數據實體對象。可以看到，在數據訪問層中，完全采用了“面向接口編程”思想。抽象出來的IDAL模塊，脫離了與具體數據庫的依賴，從而使得整個數據訪問層利於數據庫遷移。DALFactory模塊專門管理DAL對象的創建，便於業務邏輯層訪問。SQLServerDAL和OracleDAL模塊均實現IDAL模塊的接口，其中包含的邏輯就是對數據庫的Select，Insert，Update和Delete操作。因為數據庫類型的不同，對數據庫的操作也有所不同，代碼也會因此有所區別。
此外，抽象出來的IDAL模塊，除了解除了向下的依賴之外，對於其上的業務邏輯層，同樣僅存在弱依賴關系。
優點：體現了工廠模式ORM，IOC思想，.Net企業級開發。
不足：沒有ORM思想。
l Nhibernate
Hibernate是一個目前應用的最廣泛的開放源代碼的對象關系映射框架，它對Java的JDBC(類似於ADO.Net)進行了非常輕量級的對象封裝，使得程序員可以隨心所欲的使用對象編程思維來操縱數據庫，目前在國內Java開發界已經頗為流行。而NHibernate，如同NUnit，NAnt一樣，是基於.Net的Hibernate實現。主要體現了ORM的思想，解決了分層開發中的持久層的問題，在N層開發中非常重要。
優點：體現了ORM，持久層。
不足：配置復雜，過份信賴於XML文件。
所用技術總結：
OR Mapping思想，分層架構思想，Castle-ActiveRecorder，Atlas，反射，設計模式(單例模式，簡單工廠模式，策略模式)，XML，IOC，框架。
3 當前J2ee主要的開發框架簡介
l Struts 框架
Struts框架是一開源產品，基於模型-視圖-控制器(MVC)設計范例來開發Web應用軟件。它使用並且擴展了Java Servlet API，最初由Craig McClanahan創建。在2000年5月，它被捐贈到Apache Foundation。Struts框架展示了一個強有力的定制標簽庫，平鋪顯示，表單檢驗和I18N(國際化)。另外，Struts支持許多描述層，包括JSP，XML/XSLT使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫，JavaServerFaces(JSF)和Velocity;還支持一些模型層，包括JavaBeans和EJB。
下面是Struts的核心內容：
JSP(TagLib)――>ActionForm――>Action ――> Event――>EJBAction――>EJB――>DAO――>Database
JSP(TagLib) (forward) <――Action<――EventResponse<――
優點：基於MVC模式，結構很好，基於JSP。
不足：擴展性不太好，邏輯復雜的大型項目不適用，框架層次划分不太清楚。
l Spring框架
Spring框架是一個分層的Java/J2EE應用程序框架，基於Expert One-on-One J2EE設計和發行的代碼。Spring框架提供一種簡單的開發技術，用於自動化處理工程中大量的屬性文件和助理類。
Spring是一個開源框架，由Rod Johnson創建並且在他的著作《J2EE設計開發編程指南》里進行了描述。它是為了解決企業應用開發的復雜性而創建的。Spring使使用基本的JavaBeans來完成以前只可能由EJB完成的事情變得可能了。然而，Spring的用途不僅限於服務器端的開發。從簡單性、可測試性和松耦合的角度而言，任何Java應用都可以從Spring中受益。
Spring框架包括的主要特色有：
1 強有力的基於JavaBeans的配置管理，使用Inversion-of-Control(IoC)原則。
2 一個核心bean工廠，可用在任何環境，從applets到J2EE容器程序。
3 通用的抽象層適合於數據庫事務管理，允許可插入的事務管理器，並且不需要處理低層次的問題就可容易地划分各事務的界限。
4 一個很有意義的異常處理的JDBC抽象層。
5 與Hibernate集成到一起，DAO實現支持以及事務策略。
優點：體現了J2EE、容器、輕量級、控制反轉、面向切面的思想。
不足：結構復雜，不易理解。
l Hibernate框架
Hibernate是一個開放源代碼的對象關系映射(ORM)框架，它對JDBC進行了非常輕量級的對象封裝，它提供一個易用的框架來實現把一個面向對象的域模型映射到一傳統的關系數據庫，使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫。它不僅負責從Java類到數據庫表格(以及來自Java數據類型的SQL數據類型)的映射，而且還提供數據查詢和檢索能力，並能大大減少花在SQL和JDBC手工數據處理上的開發時間。最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任。
Hibernate的目標是減輕開發者的與大量普通的數據持續性相聯系的編程任務。Hibernate還能夠適應開發進程，無論它是剛開始設計還是來自一現成的數據庫。Hibernate可以自動生成SQL，使開發者擺脫了手工處理結果集和進行對象轉化的繁瑣任務，並能使應用程序移植到所有的SQL數據庫。它還能提供透明的持續性，對持續性類的唯一的要求的是實現一個無參數的構造器。
優點：主要應用在EJB層，可配置性強，靈活，簡化了數據庫操作。
不足：難以配置。
4 常見的軟件體系架構
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系統相互影響的架構視圖。
7 小結
本文介紹了SaaS的體系架構設計方法。通過對.net主要的開發框架簡介和J2ee主要的開發框架簡介可以分析出各自的優勢與不足。
同時介紹了軟件體系架構的分層模式，通過具體分層體現了軟件體系架構的核心價值，架構的模型可以在我們的開發中應用。