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