應用系統架構設計-補全篇
[email protected] 如有轉載請註明出處
原文地址：http://simonw.cnblogs.com/archive/2005/10/27/263145.html
我們在做着表面上看似是對於各種不同應用的開發，其實背後所對應的架構設計都是相對穩定的。在一個好的架構下編程，不僅對於開發人員是一件賞心悅目的事情，更重要的是軟件能夠表現出一個健康的姿態；而架構設計的不合理，不僅讓開發人員受苦受難，軟件本身的生命週期更是受到嚴重威脅。這裏我將針對在微軟dotNet平臺上做應用開發的系統架構設計做一個粗淺的討論。
總體設計圖
表示層
表示層由UI（User Interface）和UI控制邏輯組成。
· UI（User Interface）
UI是客戶端的用戶界面，負責從用戶方接收命令，請求，數據，傳遞給業務層處理，然後將結果呈現出來。根據客戶端的不同我們大體將應用程序分爲BS（Browser-Server） 瀏覽器結構，CS（Client-Server）桌面客戶端結構。
BS的優點是無需操心客戶端，只需要部署維護好服務器即可。CS的優點在於強大的界面交互表達能力。RIA（Rich Internet Application）是爲了融合這兩種結構優點的一種技術，它依賴在客戶端一次性安裝一個通用解釋器之後即獲得強大的界面交互表達能力和無需部署具體客戶端的方便性。具體的實現技術很多，例如微軟的SmartClient， Avalon； Macromedia的Flex；以JS爲基礎的Bindows；Ajax等等很多。
· UI控制邏輯
UI控制邏輯負責處理UI和業務層之間的數據交互，UI之間狀態流程的控制，同時負責簡單的數據驗證和格式化等功能。具體的說在dotNet事件驅動的編程模型下，UI控制邏輯被自然的實現在了事件函數中，例如PageLoad事件函數，ButtonClick事件函數。在這些事件函數中，主要任務就是做UI控件與業務實體的數據交換與業務調用，但面對大量的數據交換工作量與維護量就成了最大的問題。而在複雜應用的系統中，狀態與流程的管理是必須要考慮的因素，它包含了界面與業務兩方面。如果不加以封裝的直接寫在事件函數中將導致業務依賴表示層。下面分別討論這兩個問題。
1.UI與業務實體之間的數據交互
此階段負責數據交換的業務實體我把它稱爲DTO（Data Transfer Object），但需要說明的是這裏的DTO並不是只包含數據的業務對象，它仍然包含必要的方法是完整的業務實體。處理輸入時我們從UI控件的獲得數據填入DTO再向下傳播，處理輸出時用戶發出請求業務層會將數據以DTO的形式返出再賦給UI控件展現。因此需要一種方式來自動解決這樣的來回賦值問題。Java下Structs的Formbean對此問題提供了一定支持，而遺憾的是dotNet下的不少控件雖然支持數據綁定但仍然沒有一個現成完整的解決辦法。一種比較簡單的方式是自己設計一個Adapter按照某種映射關係來自動處理這樣的綁定，這樣的映射關係最好是UI控件與DTO屬性的事先命名約定，以此種方式的約定作爲映射關係無需增加任何配置文件和配置工作即可實現。例如你的一個輸入人名的Textbox命名爲txtUserName，而我的業務實體屬性命名爲UserName，這樣就可以通過字符串的查找來找到對應。
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應用程序。
業務層
業務層封裝了實際業務邏輯，包含數據驗證，事物處理，權限處理等業務相關操作，是整個應用系統的核心。因此設計一個能夠真實反映實際需要的業務層是非常必要的，我們將實際業務具體分爲業務數據與業務操作兩部分。
· 業務數據
業務數據又是業務邏輯的核心，最終業務數據將以一種固定的格式表現於內存中，在系統的各個層次間傳輸，充當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建模爲佳。
· 業務操作
業務操作負責對業務數據進行各種業務相關的處理，例如驗證，流向，整合，事物，權限等，但它不負責有關對數據源的操作。它與業務數據的關係設計有2種方式。
分離業務數據與業務操作，將業務數據單獨封裝到只有數據get，set的數據類中，這個數據類只充當DTO。將業務操作封裝到獨立的service類中與業務數據一起充當業務層。這樣當系統不復雜的時候顯的簡單直觀，而隨着系統日益複雜，service類會變的雜亂，而將本身耦合緊密的數據與操作分離對於複用也是不利的因素。具體可參考Martin Fowler 的貧血的Domain Model一文。
整合業務數據與業務操作，將業務數據與相關的業務操作封裝在一起稱爲業務實體，業務實體作爲統一的業務層爲表示層提供服務，同時也負責作爲DTO在各個層次間傳輸，我傾向於這樣完整的Domain Model設計方式，每個業務實體都可以做爲一個單獨組件形式存在，對於組件化複用有着莫大的好處。
業務數據訪問層
業務數據訪問層是一個針對具體應用系統的專屬層，它爲業務層提供與數據源交互的最小操作方式，僅僅是業務層需要的數據訪問接口，業務層完全依賴業務數據訪問層所提供的服務。這些服務負責從業務層接收數據或返回業務實體，它屏蔽了實際業務數據與機器存儲方式的差別。當然，數據層選用抽象的解決方案同樣可以達到這個效果，但業務數據訪問層最大的特點就是針對具體業務做抽象，而抽象的數據層訪問方案是針對通用做抽象。往往業務中針對具體的設計生命力會變的更強，這樣我們可以最大限度的保持了上層代碼的複用性，當需要更換存儲策略如果數據層訪問差別太大，通過更換數據層無法解決問題的時候我們最多只需要更換業務數據訪問層，而無需改變業務層。
業務數據訪問層由DAO（Data Access Object）層和系統服務層兩部分組成。DAO層爲每個業務實體提供最基本的數據訪問服務，系統服務層爲系統全局提供與業務關係不大的通用數據訪問服務，這兩層處於系統中的同一個層次位置。
業務層與業務數據訪問層關係圖
數據層
數據層的宗旨就是爲數據源提供一個可供外界訪問的接口，我們應該選用一種能夠提供數據源無關的抽象數據訪問接口並通過在其下掛接各種不同的DataProviador來訪問數據源的數據層組件，這樣做便於移植到不同的數據源上。目前有以下3種數據層方案：
1. 封裝ADO.Net
這些數據訪問組件都是基於ADO.Net的淺封裝，它的優點在於封裝層次低所以速度最快，我們可以手動組織sql語句用來適應複雜的操作以及個性的優化等。缺點是無法直接處理自定義數據實體方式的業務實體對象，需要將業務實體中的數據屬性以參數形式傳入傳出。這樣的方式雖然最爲保險，但隨着系統規模增大，開發效率，質量，，後期的維護，二次開發都變成尤爲突出的問題，對開發人員的要求會變的越來越高。另外對於事物操作封裝不是很好，無法提供聲明性事物，經常會在業務層出現訪問數據層的需要。這樣的組件目前應用的很廣泛，例如微軟在EnterpriseLibrary中提供的DAAB（Data Access Application Block），還有以前的DAAB3.1。EnterpriseLibrary是個成熟的產品，包括了數據訪問，異常，日誌，緩存，加密，配置,安全等組件做爲通用服務非常適合。
2. OR-Mapping組件
ORM是最好的數據持久解決方案，它的優點在於能夠以面向對象的方式操縱數據，因此可以直接處理自定義數據實體的業務對象，我們根本不用操心sql語句以及底層存儲方式，這樣極大的簡化的代碼提高了開發效率，對於日後維護擴展都帶來極大的便利。缺點在於屏蔽了底層使得我們無法針對具體數據源做優化，而且對於複雜關聯的sql操作有些力不從心，同時性能也差一些但輔助以緩存情況會好很多，而在dotNet下最大的問題就是沒有一個成熟便宜的ORM產品供我們使用，全部都是beta版本和商業版本。這些版本或多或少都存在一些問題，以至於真正應用中需要經過仔細考察。例如NHibernate，Gentle.Net，XPO，Grove.Net等等非常多。
3. DataMapper（SqlMapper）
SqlMapper爲以上兩種方式提供了一個折中的選擇，它可以以面向對象的方式直接處理自定義數據實體的業務對象，同時可以根據與數據源與業務實體的映射關係執行手寫的sql語句，這樣完全使得我們可以針對具體數據源做優化，對於複雜操作同樣可以勝任。目前只有iBatis.Net一個產品，它是一個java移至的開源項目，已經比較成熟，可以在無需編譯的情況下隨意替換DAO。
各層間的依賴關係
依賴關係圖：
在對各層的討論之後，我們來總結一下各層間的依賴關係。說到依賴就離不開復用這個詞，複用對軟件開發流程的幾乎每個階段都有着重要的意義。在設計階段它代表着更清晰的設計，在開發階段它代表着更高的工作效率和代碼質量，在測試階段它代表着更輕易的捕獲bug，在維護和再開發階段它代表着更小的工作量。更好的複用需要設計更好的依賴關係。
從圖中可以看出表示層與業務數據訪問層都依賴於業務層，而業務層是相對獨立的，這樣設計的優點就是最大限度的減少了變動對整個系統所帶來的影響。最壞的情況就是業務的改變，業務改變其他依賴業務層的地方必須改變（在這裏我們忽略了一些針對多種業務而設計的其他層組件，這些組件是可以適應有限的業務變更而本身不用變更的。），這個我們沒有辦法控制。但像表示層與業務數據訪問層等其他非業務方面的改動不會影響到其他地方。
有人應該注意到了圖中的配置文件。在沒有它的時候，業務層是依賴於業務數據訪問層的，細心的讀者應該能從業務層與業務數據訪問層關係圖中發現這個問題。這樣雙向依賴的關係是以後造成無法複用的根本所在。因此需要抽象出業務數據訪問接口，讓業務層去依賴這個接口，而不是業務數據訪問層。但光聲明接口是不夠的，因爲在實例化的時候仍然需要具體的下層類，所以依舊無法擺脫依賴關係。於是把依賴轉移出來，這又引出了依賴倒置（Dependency Inversion Principle）的概念，具體可以參見Martin Fowler的相關論述。IoC（Inversion of Control）容器爲我們提供了完美的方案，通過它將不同的模塊注入到系統中我們可以在不知道這個組件存在的情況下調用它。這樣的方式同樣適合於權限管理，郵件發送等等其他組件。Spring.Net和Castle是dotNet下的兩個優秀的IoC容器Spring.Net是Java下Spring的移植版本，Castle相對更要成熟。但是當你使用的組件並不是很多而不願使用配置這些複雜而強大的產品時，你就要手工完成這些工作，你需要把業務層使用那些數據訪問組件寫在配置文件中，然後通過工廠（Factory）解析配置文件應用反射（Reflection）技術實例化出你的組件。
最後再說點關於AOP（Aspect-OrientedProgramming）的話題，在一些非常通用的組件或者系統功能間我們可以使用AOP技術來打散系統其他部分對他們的依賴。像權限管理，系統日誌，異常處理等。拿權限管理來舉例，通常我們是在需要做權限檢測的函數內部的開頭來加一行權限檢測代碼，通過則執行後續代碼否則跳出。這樣寫破壞了業務的純潔性，業務的存在於權限並沒有什麼關係，而且使業務代碼依賴權限組件，當我需要去除權限而另做新系統的時候這是見很麻煩的事情。AOP的好處在於可以以聲明方式來處理這些問題，例如你只需在需要驗證的函數前加上一行屬性的描述或者在配置文件中寫上那些函數需要驗證，執行時AOP組件會按照你預先定製的先後順序執行你的代碼，這樣我們可以輕鬆的剝離這些組件而絲毫不會對現有系統造成任何影響。
關於Service層的討論
Service層是一個構建於表示層於業務層之間的層，它是對業務層的一個淺封裝而不應該封裝過多的業務邏輯，否則會造成不必要的麻煩。然而它並不是任何時候都有必要存在。一種情況下當你的UI所要展現的東西和你的業務實體並不是那麼完全吻合的時候，例如你的界面需要顯示若干個業務實體的一部分，但這並不是業務本身，只是一種展現方式。這時候你需要Service層來做一個展現邏輯的轉換。或者當你在做分佈式系統的時候可以利用Service層來實現一個粗粒度的服務接口。也可以以SOA（Service-oriented Architecture）的方式來理解Service層，我們最終使用的是系統所提供的服務而不是業務對象，所以需要將將業務對象以清晰的方式組織起來形成清晰的服務暴露在外。更多的情況在於你結合實際該如何使用。
結束語
至此，整個架構方案的討論已經完成，我們可以看出dotNet下可供選擇的解決方案是那麼的有限，反看Java世界，有那麼多成熟可供利用的組件框架，甚是着急。不過dotNet也正在走向成熟，我們需要時間等待。以上提供的方案僅代表了一種基本的思路，在具體環境中需要做具體的調整。希望能起到一個拋磚引玉的作用。我的聯繫方式見Blog，由於經驗不足，有不正確的地方歡迎指正討論。
