應用系統架構設計

應用系統架構設計  Simonw@2005.4.24 如有轉載請註明出處。  

我們在做著表面上看似是對於各種不同應用的開發，其實背後所對應的架構設計都是相對穩定的。在一個好的架構下編程，不僅對於開發人員是一件賞心悅目的事情，更重要的是軟體能夠表現出一個健康的姿態；而架構設計的不合理，不僅讓開發人員受苦受難，軟體本身的生命週期更是受到嚴重威脅。這裡我將針對在微軟dotNet平台上做應用開發系統的一般架構流程設計做一個粗淺的討論。

 

總體設計圖 

 

展示層

展示層由UI（User Interface）和UI控制邏輯組成。

l         UI（User Interface）

UI是用戶端的使用者介面，負責從使用者方接收命令，請求，資料，傳遞給業務層處理，然後將結果呈現出來。根據用戶端的不同我們大體將應用程式分為BS（Browser-Server） 瀏覽器結構，CS（Client-Server）案頭用戶端結構。

BS的優點是無需操心用戶端，只需要部署維護好伺服器即可。CS的優點在於強大的介面互動表達能力。RIA（Rich Internet Application）是為了融合這兩種結構優點的一種技術，它依賴在用戶端一次性安裝一個通用解譯器之後即獲得強大的介面互動表達能力和無需部署具體用戶端的方便性。具體的實現技術很多，例如微軟的SmartClient， Avalon； Macromedia的Flex；以JS為基礎的Bindows；Ajax等等很多。

 

l         UI控制邏輯

UI控制邏輯負責處理UI和業務層之間的資料互動，UI之間狀態流程的控制，同時負責簡單的資料驗證和格式化等功能。具體的說在dotNet事件驅動的編程模型下，UI控制邏輯被自然的實現在了事件函數中，例如PageLoad事件函數，ButtonClick事件函數。在這些事件函數中，主要任務就是做UI控制項與業務實體的資料交換與業務調用，但面對大量的資料交換工作量與維護量就成了最大的問題。而在複雜應用的系統中，狀態與流程的管理是必須要考慮的因素，它們同樣是商務邏輯的一部分，如果不加以封裝的直接寫在事件函數中將導致業務依賴展示層。下面分別討論這兩個問題。

 

1.         1.UI與業務實體之間的資料互動

此階段負責資料交換的業務實體稱為DTO（Data Transfer Object），處理輸入時我們從UI控制項的獲得資料填入DTO再向下傳播，處理輸出時使用者發出請求業務層會將資料以DTO的形式返出再賦給UI控制項展現。因此需要一種方式來自動解決這樣的來回賦值問題。遺憾的是dotNet下的不少控制項雖然支援資料繫結但仍然沒有一個現成完整的解決辦法。我們可以自己設計一個Adapter按照某種映射關係來自動處理這樣的綁定，這樣的映射關係最好是UI控制項與DTO屬性的事先命名規範，以此種方式的約定作為映射關係無需增加任何設定檔和配置工作即可實現。

 

2.         2.狀態與流程的管理

既然是商務邏輯的一部分就不應該耦合再展示層當中。MVC（Model-View-Controller）模式提供了實現這一目標的方法。Controller是整個方案的核心，它是一個流程管理器，來自UI所有的命令與資料經過Controller分發給業務層或其他UI，這樣我們可以把流程，許可權等邏輯單獨封裝，例如設定檔中，達到最大化的業務重用。dotNet下MVC的方案並不像Java下有那麼多選擇，目前有以下幾種選擇：

微軟的UIPAB，它可以處理bs，cs下的流程跳轉，可以使得相同的業務系統有webform和winform不同的展現方式。

開源的Mavrick.Net，它只適用於Asp.Net應用程式，它對流程，國際化，頁麵包裝，xslt頁面轉換提供了很好的支援。

開源的Lattis，同樣只適用於Asp.Net應用程式。

 

業務層

業務層封裝了實際商務邏輯，包含資料驗證，事物處理，許可權處理等業務相關操作，是整個應用系統的核心。因此設計一個能夠真實反映實際需要的業務層是非常必要的，我們將實際業務具體分為業務資料與業務操作兩部分。

 

l         業務資料

業務資料又是商務邏輯的核心，最終業務資料將以一種固定的格式表現於記憶體中，在系統的各個層次間傳輸，充當DTO角色。表達業務資料的方式一般分為兩種Table Model和Domain Model。

Table Model是將資料庫中的表直接映射成為業務資料對象，這樣的優點是適合於機器操作，ADO.NET直接提供了這種操作的便利，但對於複雜業務關係的表達就很不直觀。只適合於業務需求與資料表對應關係很直接的需要快速開發的情況。通常我們選用Dataset或者強型別Dataset（Strong Typed Dataset），強型別Dataset支援編譯時間的類型檢查，效率上要略高於普通Dataset。Dataset有很多方便的特性：無需自己編寫維護類，支援序列化，資料副本儲存，支援資料集合，對控制項綁定支援效果好，微軟提供了相應的產生工具以及持久方案。但缺點也是明顯，複雜資料表現不直觀，做為DTO在各個層次間傳輸，尤其是分布式環境，龐大的體積，相對緩慢的執行個體化對於效能造成很大壓力。

Domain Model則是根據實際業務按照現實方式用OO思想建模，這樣很適合業務複雜的系統。通常採用自訂資料實體（Custom Data Entity）方式表達。自訂資料實體，有著良好的效能，編譯時間的類型檢查，資料表現方式非常直觀符合實際業務的操作方式等優點，但需要自己定義維護類，在分布式環境下需要自己編寫序列化方法。

綜合各種因素考慮，雖然業務簡單對應直接的系統我們以Table Model建模開發效率很高但難免保證系統日後不會變的複雜，因此出於複用性，擴充性，效能等方面選用Domain Model建模為佳。

 

l         業務操作

業務操作負責對業務資料進行各種業務相關的處理，例如驗證，流向，整合，事物，許可權等，但它不負責有關對資料來源的操作。它與業務資料的關係設計有2種方式。

分離業務資料與業務操作，將業務資料單獨封裝到只有資料get，set的資料類中，這個資料類只充當DTO。將業務操作封裝到獨立的service類中與業務資料一起充當業務層。這樣當系統不複雜的時候顯的簡單直觀，而隨著系統日益複雜，service類會變的雜亂，而將本身耦合緊密的資料與操作分離對於複用也是不利的因素。具體可參考Martin Fowler 的貧血的Domain Model一文，但我並不傾向於業務層直接存取資料來源。

整合業務資料與業務操作，將業務資料與相關的業務操作封裝在一起稱為業務實體，業務實體作為統一的業務層為展示層提供服務，同時也負責作為DTO在各個層次間傳輸，我傾向於這樣完整的Domain Model設計方式，每個業務實體都可以做為一個單獨組件形式存在，對於組件化複用有著莫大的好處。

 

l         業務模組間的依賴

各個業務模組之間的依賴，有時候會是難以解決的問題，尤其是一些可以重複利用的業務組件，例如許可權管理，郵件發送等等。管理好這些各種不同的業務組件是我們的目標，IoC容器為我們提供了最完美的方案，通過它將不同的模組注入到系統中我們可以在不知道這個組件存在的情況下調用它。但目前只有不成熟的Spring.Net一個選擇，我們只有一聲歎息，因此也就不多討論了。

 

業務資料訪問層

業務資料訪問層是一個針對具體應用系統的專屬層，它為業務層提供與資料來源互動的最小操作方式，僅僅是業務層需要的資料提供者，業務層完全依賴業務資料訪問層所提供的服務。這些服務負責從業務層接收資料或返回業務實體，它屏蔽了實際業務資料與機器儲存方式的差別。當然，資料層選用抽象的解決方案同樣可以達到這個效果，但業務資料訪問層最大的特點就是針對具體業務做抽象，而抽象的資料層訪問方案是針對通用做抽象。往往業務中針對具體的設計生命力會變的更強，這樣我們可以最大限度的保持了上層代碼的複用性，當需要更換儲存策略如果資料層訪問差別太大，通過更換資料層無法解決問題的時候我們最多隻需要更換業務資料訪問層，而無需改變業務層。

 

業務資料訪問層由DAO（Data Access Object）層和系統服務層兩部分組成。DAO層為每個業務實體提供最基本的資料訪問服務，系統服務層為系統全域提供與業務關係不大的通用資料訪問服務，這兩層處於系統中的同一個層次位置。

 

業務層與業務資料訪問層關係圖

 

 

資料層

資料層的宗旨就是為資料來源提供一個可供外界訪問的介面，我們應該選用一種能夠提供資料來源無關的抽象資料提供者並通過在其下掛接各種不同的DataProviador來訪問資料來源的資料層組件，這樣做便於移植到不同的資料來源上。目前有以下3種資料層方案：

 

1.        1. 封裝ADO.Net

這些資料訪問組件都是基於ADO.Net的淺封裝，它的優點在於封裝層次低所以速度最快，我們可以手動組織sql語句用來適應複雜的操作以及個性的最佳化等。缺點是無法直接處理自訂資料實體方式的業務實體物件，需要將業務實體中的資料屬性以參數形式傳入傳出。這樣的方式雖然最為保險，但隨著系統規模增大，開發效率，品質，，後期的維護，二次開發都變成尤為突出的問題，對開發人員的要求會變的越來越高。另外對於事物操作封裝不是很好，無法提供聲明性事物，經常會在業務層出現訪問資料層的需要。這樣的組件目前應用的很廣泛，例如微軟在EnterpriseLibrary中提供的DAAB（Data Access Application Block），還有以前的DAAB3.1。EnterpriseLibrary是個成熟的產品，包括了資料訪問，異常，日誌，緩衝，加密，配置,安全等組件做為泛型服務非常適合。

 

2.        2. OR-Mapping組件

ORM是最好的資料持久解決方案，它的優點在於能夠以物件導向的方式操縱資料，因此可以直接處理自訂資料實體的業務對象，我們根本不用操心sql語句以及底層儲存方式，這樣極大的簡化的代碼提高了開發效率，對於日後維護擴充都帶來極大的便利。缺點在於屏蔽了底層使得我們無法針對具體資料來源做最佳化，而且對於複雜關聯的sql操作有些力不從心，同時效能也差一些但輔助以緩衝情況會好很多，而在dotNet下最大的問題就是沒有一個成熟便宜的ORM產品供我們使用，全部都是beta版本和商業版本。這些版本或多或少都存在一些問題，以至於真正應用中需要經過仔細考察。例如NHibernate，Gentle.Net，XPO，Grove.Net等等非常多。

 

3.        3. DataMapper（SqlMapper）

SqlMapper為以上兩種方式提供了一個折中的選擇，它可以以物件導向的方式直接處理自訂資料實體的業務對象，同時可以根據與資料來源與業務實體的映射關係執行手寫的sql語句，這樣完全使得我們可以針對具體資料來源做最佳化，對於複雜操作同樣可以勝任。目前只有iBatis.Net一個產品，它是一個java移至的開源項目，已經比較成熟，可以在無需編譯的情況下隨意替換DAO。

 

 

至此，整個架構方案的討論已經完成，我們可以看出dotNet下可供選擇的解決方案是那麼的有限，反看Java世界，有那麼多成熟可供利用的組件架構，流口水中...不過dotNet也正在走向成熟，我們需要時間等待。這個架構設計的思路只代表了我個人的理解，而且也並不是說所有的開發都是這麼一套方案，在具體環境中需要做具體的調整。希望能起到一個拋磚引玉的作用。我的郵箱是i-simon AT msn.com，由於我經驗尚淺，有不正確或不足的地方歡迎指正討論，另外本文將根據技術的最新進展持續更新。

應用系統架構設計-補全版：http://simonw.cnblogs.com/archive/2005/10/27/263145.html