我們?cè)谧鲋砻嫔峡此剖菍?duì)于各種不同應(yīng)用的開發(fā)，其實(shí)背后所對(duì)應(yīng)的架構(gòu)設(shè)計(jì)都是相對(duì)穩(wěn)定的。在一個(gè)好的架構(gòu)下編程，不僅對(duì)于開發(fā)人員是一件賞心悅目的事情，更重要的是軟件能夠表現(xiàn)出一個(gè)健康的姿態(tài)；而架構(gòu)設(shè)計(jì)的不合理，不僅讓開發(fā)人員受苦受難，軟件本身的生命周期更是受到嚴(yán)重威脅。這里我將針對(duì)在微軟dotNET平臺(tái)上做應(yīng)用開發(fā)的系統(tǒng)架構(gòu)設(shè)計(jì)做一個(gè)粗淺的討論。

總體設(shè)計(jì)圖

表示層

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

• UI（User Interface）

       UI是客戶端的用戶界面，負(fù)責(zé)從用戶方接收命令，請(qǐng)求，數(shù)據(jù)，傳遞給業(yè)務(wù)層處理，然后將結(jié)果呈現(xiàn)出來。根據(jù)客戶端的不同我們大體將應(yīng)用程序分為BS（Browser-Server） 瀏覽器結(jié)構(gòu)，CS（Client-Server）桌面客戶端結(jié)構(gòu)。

       BS的優(yōu)點(diǎn)是無需操心客戶端，只需要部署維護(hù)好服務(wù)器即可。CS的優(yōu)點(diǎn)在于強(qiáng)大的界面交互表達(dá)能力。RIA（Rich InterNET Application）是為了融合這兩種結(jié)構(gòu)優(yōu)點(diǎn)的一種技術(shù)，它依賴在客戶端一次性安裝一個(gè)通用解釋器之后即獲得強(qiáng)大的界面交互表達(dá)能力和無需部署具體客戶端的方便性。具體的實(shí)現(xiàn)技術(shù)很多，例如微軟的SmartClient， Avalon； Macromedia的Flex；以JS為基礎(chǔ)的Bindows；Ajax等等很多。 

• UI控制邏輯

       UI控制邏輯負(fù)責(zé)處理UI和業(yè)務(wù)層之間的數(shù)據(jù)交互，UI之間狀態(tài)流程的控制，同時(shí)負(fù)責(zé)簡單的數(shù)據(jù)驗(yàn)證和格式化等功能。具體的說在dotNET事件驅(qū)動(dòng)的編程模型下，UI控制邏輯被自然的實(shí)現(xiàn)在了事件函數(shù)中，例如PageLoad事件函數(shù)，ButtonClick事件函數(shù)。在這些事件函數(shù)中，主要任務(wù)就是做UI控件與業(yè)務(wù)實(shí)體的數(shù)據(jù)交換與業(yè)務(wù)調(diào)用，但面對(duì)大量的數(shù)據(jù)交換工作量與維護(hù)量就成了最大的問題。而在復(fù)雜應(yīng)用的系統(tǒng)中，狀態(tài)與流程的管理是必須要考慮的因素，它包含了界面與業(yè)務(wù)兩方面。如果不加以封裝的直接寫在事件函數(shù)中將導(dǎo)致業(yè)務(wù)依賴表示層。下面分別討論這兩個(gè)問題。 

1.UI與業(yè)務(wù)實(shí)體之間的數(shù)據(jù)交互

       此階段負(fù)責(zé)數(shù)據(jù)交換的業(yè)務(wù)實(shí)體我把它稱為DTO（Data Transfer Object），但需要說明的是這里的DTO并不是只包含數(shù)據(jù)的業(yè)務(wù)對(duì)象，它仍然包含必要的方法是完整的業(yè)務(wù)實(shí)體。處理輸入時(shí)我們從UI控件的獲得數(shù)據(jù)填入DTO再向下傳播，處理輸出時(shí)用戶發(fā)出請(qǐng)求業(yè)務(wù)層會(huì)將數(shù)據(jù)以DTO的形式返出再賦給UI控件展現(xiàn)。因此需要一種方式來自動(dòng)解決這樣的來回賦值問題。Java下Structs的Formbean對(duì)此問題提供了一定支持，而遺憾的是dotNET下的不少控件雖然支持?jǐn)?shù)據(jù)綁定但仍然沒有一個(gè)現(xiàn)成完整的解決辦法。一種比較簡單的方式是自己設(shè)計(jì)一個(gè)Adapter按照某種映射關(guān)系來自動(dòng)處理這樣的綁定，這樣的映射關(guān)系最好是UI控件與DTO屬性的事先命名約定，以此種方式的約定作為映射關(guān)系無需增加任何配置文件和配置工作即可實(shí)現(xiàn)。例如你的一個(gè)輸入人名的Textbox命名為txtUserName，而我的業(yè)務(wù)實(shí)體屬性命名為UserName，這樣就可以通過字符串的查找來找到對(duì)應(yīng)。 

2.狀態(tài)與流程的管理

       復(fù)雜業(yè)務(wù)方面的狀態(tài)與流程可以通過一些工作流引擎來解決，微軟最近獨(dú)立發(fā)布了自己的工作流引擎有興趣的朋友可以去看看。一般更多的情況是需要解決界面上狀態(tài)與流程的管理。耦合再表示層中是不可取的辦法。MVC（Model-View-Controller）模式提供了實(shí)現(xiàn)這一目標(biāo)的方法。Controller是整個(gè)方案的核心，它是一個(gè)流程管理器，來自UI所有的命令與數(shù)據(jù)經(jīng)過Controller分發(fā)給業(yè)務(wù)層或其他UI，這樣我們可以把流程，權(quán)限等邏輯單獨(dú)封裝，例如配置文件中，達(dá)到最大化的業(yè)務(wù)重用。dotNET下MVC的方案并不像Java下有那么多選擇，目前有以下幾種選擇：

微軟的UIPAB，它可以處理bs，cs下的流程跳轉(zhuǎn)，可以使得相同的業(yè)務(wù)系統(tǒng)有webform和winform不同的展現(xiàn)方式。

開源的Mavrick.NET，它只適用于ASP.NET應(yīng)用程序，它對(duì)流程，國際化，頁面包裝，xslt頁面轉(zhuǎn)換提供了很好的支持。

開源的Lattis，功能比較單一，同樣只適用于ASP.NET應(yīng)用程序。

業(yè)務(wù)層

       業(yè)務(wù)層封裝了實(shí)際業(yè)務(wù)邏輯，包含數(shù)據(jù)驗(yàn)證，事物處理，權(quán)限處理等業(yè)務(wù)相關(guān)操作，是整個(gè)應(yīng)用系統(tǒng)的核心。因此設(shè)計(jì)一個(gè)能夠真實(shí)反映實(shí)際需要的業(yè)務(wù)層是非常必要的，我們將實(shí)際業(yè)務(wù)具體分為業(yè)務(wù)數(shù)據(jù)與業(yè)務(wù)操作兩部分。 

• 業(yè)務(wù)數(shù)據(jù)

       業(yè)務(wù)數(shù)據(jù)又是業(yè)務(wù)邏輯的核心，最終業(yè)務(wù)數(shù)據(jù)將以一種固定的格式表現(xiàn)于內(nèi)存中，在系統(tǒng)的各個(gè)層次間傳輸，充當(dāng)DTO角色。表達(dá)業(yè)務(wù)數(shù)據(jù)的方式一般分為兩種Table Model和Domain Model。

       Table Model是將數(shù)據(jù)庫中的表直接映射成為業(yè)務(wù)數(shù)據(jù)對(duì)象，這樣的優(yōu)點(diǎn)是適合于機(jī)器操作，ADO.NET直接提供了這種操作的便利，但對(duì)于復(fù)雜業(yè)務(wù)關(guān)系的表達(dá)就很不直觀。只適合于業(yè)務(wù)需求與數(shù)據(jù)表對(duì)應(yīng)關(guān)系很直接的需要快速開發(fā)的情況。通常我們選用Dataset或者強(qiáng)類型Dataset（Strong Typed Dataset），強(qiáng)類型Dataset支持編譯時(shí)的類型檢查，效率上要略高于普通Dataset。Dataset有很多方便的特性：無需自己編寫維護(hù)類，支持序列化，數(shù)據(jù)副本保存，支持?jǐn)?shù)據(jù)集合，對(duì)控件綁定支持效果好，微軟提供了相應(yīng)的生成工具以及持久方案。但缺點(diǎn)也是明顯，復(fù)雜數(shù)據(jù)表現(xiàn)不直觀，做為DTO在各個(gè)層次間傳輸，尤其是分布式環(huán)境，龐大的體積，相對(duì)緩慢的實(shí)例化對(duì)于性能造成很大壓力。

       Domain Model則是根據(jù)實(shí)際業(yè)務(wù)按照現(xiàn)實(shí)方式用OO思想建模，這樣很適合業(yè)務(wù)復(fù)雜的系統(tǒng)。通常采用自定義數(shù)據(jù)實(shí)體（Custom Data Entity）方式表達(dá)。自定義數(shù)據(jù)實(shí)體，有著良好的性能，編譯時(shí)的類型檢查，數(shù)據(jù)表現(xiàn)方式非常直觀符合實(shí)際業(yè)務(wù)的操作方式等優(yōu)點(diǎn)，但需要自己定義維護(hù)類，在分布式環(huán)境下需要自己編寫序列化方法。

       綜合各種因素考慮，雖然業(yè)務(wù)簡單對(duì)應(yīng)直接的系統(tǒng)我們以Table Model建模開發(fā)效率很高但難免保證系統(tǒng)日后不會(huì)變的復(fù)雜，因此出于復(fù)用性，擴(kuò)展性，性能等方面選用Domain Model建模為佳。 

• 業(yè)務(wù)操作

       業(yè)務(wù)操作負(fù)責(zé)對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行各種業(yè)務(wù)相關(guān)的處理，例如驗(yàn)證，流向，整合，事物，權(quán)限等，但它不負(fù)責(zé)有關(guān)對(duì)數(shù)據(jù)源的操作。它與業(yè)務(wù)數(shù)據(jù)的關(guān)系設(shè)計(jì)有2種方式。

       分離業(yè)務(wù)數(shù)據(jù)與業(yè)務(wù)操作，將業(yè)務(wù)數(shù)據(jù)單獨(dú)封裝到只有數(shù)據(jù)get，set的數(shù)據(jù)類中，這個(gè)數(shù)據(jù)類只充當(dāng)DTO。將業(yè)務(wù)操作封裝到獨(dú)立的service類中與業(yè)務(wù)數(shù)據(jù)一起充當(dāng)業(yè)務(wù)層。這樣當(dāng)系統(tǒng)不復(fù)雜的時(shí)候顯的簡單直觀，而隨著系統(tǒng)日益復(fù)雜，service類會(huì)變的雜亂，而將本身耦合緊密的數(shù)據(jù)與操作分離對(duì)于復(fù)用也是不利的因素。具體可參考Martin Fowler 的貧血的Domain Model一文。

       整合業(yè)務(wù)數(shù)據(jù)與業(yè)務(wù)操作，將業(yè)務(wù)數(shù)據(jù)與相關(guān)的業(yè)務(wù)操作封裝在一起稱為業(yè)務(wù)實(shí)體，業(yè)務(wù)實(shí)體作為統(tǒng)一的業(yè)務(wù)層為表示層提供服務(wù)，同時(shí)也負(fù)責(zé)作為DTO在各個(gè)層次間傳輸，我傾向于這樣完整的Domain Model設(shè)計(jì)方式，每個(gè)業(yè)務(wù)實(shí)體都可以做為一個(gè)單獨(dú)組件形式存在，對(duì)于組件化復(fù)用有著莫大的好處。

業(yè)務(wù)數(shù)據(jù)訪問層

       業(yè)務(wù)數(shù)據(jù)訪問層是一個(gè)針對(duì)具體應(yīng)用系統(tǒng)的專屬層，它為業(yè)務(wù)層提供與數(shù)據(jù)源交互的最小操作方式，僅僅是業(yè)務(wù)層需要的數(shù)據(jù)訪問接口，業(yè)務(wù)層完全依賴業(yè)務(wù)數(shù)據(jù)訪問層所提供的服務(wù)。這些服務(wù)負(fù)責(zé)從業(yè)務(wù)層接收數(shù)據(jù)或返回業(yè)務(wù)實(shí)體，它屏蔽了實(shí)際業(yè)務(wù)數(shù)據(jù)與機(jī)器存儲(chǔ)方式的差別。當(dāng)然，數(shù)據(jù)層選用抽象的解決方案同樣可以達(dá)到這個(gè)效果，但業(yè)務(wù)數(shù)據(jù)訪問層最大的特點(diǎn)就是針對(duì)具體業(yè)務(wù)做抽象，而抽象的數(shù)據(jù)層訪問方案是針對(duì)通用做抽象。往往業(yè)務(wù)中針對(duì)具體的設(shè)計(jì)生命力會(huì)變的更強(qiáng)，這樣我們可以最大限度的保持了上層代碼的復(fù)用性，當(dāng)需要更換存儲(chǔ)策略如果數(shù)據(jù)層訪問差別太大，通過更換數(shù)據(jù)層無法解決問題的時(shí)候我們最多只需要更換業(yè)務(wù)數(shù)據(jù)訪問層，而無需改變業(yè)務(wù)層。 

       業(yè)務(wù)數(shù)據(jù)訪問層由DAO（Data Access Object）層和系統(tǒng)服務(wù)層兩部分組成。DAO層為每個(gè)業(yè)務(wù)實(shí)體提供最基本的數(shù)據(jù)訪問服務(wù)，系統(tǒng)服務(wù)層為系統(tǒng)全局提供與業(yè)務(wù)關(guān)系不大的通用數(shù)據(jù)訪問服務(wù)，這兩層處于系統(tǒng)中的同一個(gè)層次位置。

業(yè)務(wù)層與業(yè)務(wù)數(shù)據(jù)訪問層關(guān)系圖

數(shù)據(jù)層

       數(shù)據(jù)層的宗旨就是為數(shù)據(jù)源提供一個(gè)可供外界訪問的接口，我們應(yīng)該選用一種能夠提供數(shù)據(jù)源無關(guān)的抽象數(shù)據(jù)訪問接口并通過在其下掛接各種不同的DataProviador來訪問數(shù)據(jù)源的數(shù)據(jù)層組件，這樣做便于移植到不同的數(shù)據(jù)源上。目前有以下3種數(shù)據(jù)層方案： 

1.         封裝ADO.NET

       這些數(shù)據(jù)訪問組件都是基于ADO.NET的淺封裝，它的優(yōu)點(diǎn)在于封裝層次低所以速度最快，我們可以手動(dòng)組織sql語句用來適應(yīng)復(fù)雜的操作以及個(gè)性的優(yōu)化等。缺點(diǎn)是無法直接處理自定義數(shù)據(jù)實(shí)體方式的業(yè)務(wù)實(shí)體對(duì)象，需要將業(yè)務(wù)實(shí)體中的數(shù)據(jù)屬性以參數(shù)形式傳入傳出。這樣的方式雖然最為保險(xiǎn)，但隨著系統(tǒng)規(guī)模增大，開發(fā)效率，質(zhì)量，，后期的維護(hù)，二次開發(fā)都變成尤為突出的問題，對(duì)開發(fā)人員的要求會(huì)變的越來越高。另外對(duì)于事物操作封裝不是很好，無法提供聲明性事物，經(jīng)常會(huì)在業(yè)務(wù)層出現(xiàn)訪問數(shù)據(jù)層的需要。這樣的組件目前應(yīng)用的很廣泛，例如微軟在EnterpriseLibrary中提供的DAAB（Data Access Application Block），還有以前的DAAB3.1。EnterpriseLibrary是個(gè)成熟的產(chǎn)品，包括了數(shù)據(jù)訪問，異常，日志，緩存，加密，配置,安全等組件做為通用服務(wù)非常適合。 

2.         OR-Mapping組件

       ORM是最好的數(shù)據(jù)持久解決方案，它的優(yōu)點(diǎn)在于能夠以面向?qū)ο蟮姆绞讲倏v數(shù)據(jù)，因此可以直接處理自定義數(shù)據(jù)實(shí)體的業(yè)務(wù)對(duì)象，我們根本不用操心sql語句以及底層存儲(chǔ)方式，這樣極大的簡化的代碼提高了開發(fā)效率，對(duì)于日后維護(hù)擴(kuò)展都帶來極大的便利。缺點(diǎn)在于屏蔽了底層使得我們無法針對(duì)具體數(shù)據(jù)源做優(yōu)化，而且對(duì)于復(fù)雜關(guān)聯(lián)的sql操作有些力不從心，同時(shí)性能也差一些但輔助以緩存情況會(huì)好很多，而在dotNET下最大的問題就是沒有一個(gè)成熟便宜的ORM產(chǎn)品供我們使用，全部都是beta版本和商業(yè)版本。這些版本或多或少都存在一些問題，以至于真正應(yīng)用中需要經(jīng)過仔細(xì)考察。例如NHibernate，Gentle.NET，XPO，Grove.NET等等非常多。 

3.         DataMapper（SqlMapper）

       SqlMapper為以上兩種方式提供了一個(gè)折中的選擇，它可以以面向?qū)ο蟮姆绞街苯犹幚碜远x數(shù)據(jù)實(shí)體的業(yè)務(wù)對(duì)象，同時(shí)可以根據(jù)與數(shù)據(jù)源與業(yè)務(wù)實(shí)體的映射關(guān)系執(zhí)行手寫的sql語句，這樣完全使得我們可以針對(duì)具體數(shù)據(jù)源做優(yōu)化，對(duì)于復(fù)雜操作同樣可以勝任。目前只有iBatis.NET一個(gè)產(chǎn)品，它是一個(gè)Java移至的開源項(xiàng)目，已經(jīng)比較成熟，可以在無需編譯的情況下隨意替換DAO。

各層間的依賴關(guān)系

依賴關(guān)系圖：

       在對(duì)各層的討論之后，我們來總結(jié)一下各層間的依賴關(guān)系。說到依賴就離不開復(fù)用這個(gè)詞，復(fù)用對(duì)軟件開發(fā)流程的幾乎每個(gè)階段都有著重要的意義。在設(shè)計(jì)階段它代表著更清晰的設(shè)計(jì)，在開發(fā)階段它代表著更高的工作效率和代碼質(zhì)量，在測(cè)試階段它代表著更輕易的捕獲bug，在維護(hù)和再開發(fā)階段它代表著更小的工作量。更好的復(fù)用需要設(shè)計(jì)更好的依賴關(guān)系。 

       從圖中可以看出表示層與業(yè)務(wù)數(shù)據(jù)訪問層都依賴于業(yè)務(wù)層，而業(yè)務(wù)層是相對(duì)獨(dú)立的，這樣設(shè)計(jì)的優(yōu)點(diǎn)就是最大限度的減少了變動(dòng)對(duì)整個(gè)系統(tǒng)所帶來的影響。最壞的情況就是業(yè)務(wù)的改變，業(yè)務(wù)改變其他依賴業(yè)務(wù)層的地方必須改變（在這里我們忽略了一些針對(duì)多種業(yè)務(wù)而設(shè)計(jì)的其他層組件，這些組件是可以適應(yīng)有限的業(yè)務(wù)變更而本身不用變更的。），這個(gè)我們沒有辦法控制。但像表示層與業(yè)務(wù)數(shù)據(jù)訪問層等其他非業(yè)務(wù)方面的改動(dòng)不會(huì)影響到其他地方。 

       有人應(yīng)該注意到了圖中的配置文件。在沒有它的時(shí)候，業(yè)務(wù)層是依賴于業(yè)務(wù)數(shù)據(jù)訪問層的，細(xì)心的讀者應(yīng)該能從業(yè)務(wù)層與業(yè)務(wù)數(shù)據(jù)訪問層關(guān)系圖中發(fā)現(xiàn)這個(gè)問題。這樣雙向依賴的關(guān)系是以后造成無法復(fù)用的根本所在。因此需要抽象出業(yè)務(wù)數(shù)據(jù)訪問接口，讓業(yè)務(wù)層去依賴這個(gè)接口，而不是業(yè)務(wù)數(shù)據(jù)訪問層。但光聲明接口是不夠的，因?yàn)樵趯?shí)例化的時(shí)候仍然需要具體的下層類，所以依舊無法擺脫依賴關(guān)系。于是把依賴轉(zhuǎn)移出來，這又引出了依賴倒置（Dependency Inversion Principle）的概念，具體可以參見Martin Fowler的相關(guān)論述。IoC（Inversion of Control）容器為我們提供了完美的方案，通過它將不同的模塊注入到系統(tǒng)中我們可以在不知道這個(gè)組件存在的情況下調(diào)用它。這樣的方式同樣適合于權(quán)限管理，郵件發(fā)送等等其他組件。Spring.NET和Castle是dotNET下的兩個(gè)優(yōu)秀的IoC容器Spring.NET是Java下Spring的移植版本，Castle相對(duì)更要成熟。但是當(dāng)你使用的組件并不是很多而不愿使用配置這些復(fù)雜而強(qiáng)大的產(chǎn)品時(shí)，你就要手工完成這些工作，你需要把業(yè)務(wù)層使用那些數(shù)據(jù)訪問組件寫在配置文件中，然后通過工廠（Factory）解析配置文件應(yīng)用反射（Reflection）技術(shù)實(shí)例化出你的組件。 

       最后再說點(diǎn)關(guān)于AOP（ASPect-OrientedProgramming）的話題，在一些非常通用的組件或者系統(tǒng)功能間我們可以使用AOP技術(shù)來打散系統(tǒng)其他部分對(duì)他們的依賴。像權(quán)限管理，系統(tǒng)日志，異常處理等。拿權(quán)限管理來舉例，通常我們是在需要做權(quán)限檢測(cè)的函數(shù)內(nèi)部的開頭來加一行權(quán)限檢測(cè)代碼，通過則執(zhí)行后續(xù)代碼否則跳出。這樣寫破壞了業(yè)務(wù)的純潔性，業(yè)務(wù)的存在于權(quán)限并沒有什么關(guān)系，而且使業(yè)務(wù)代碼依賴權(quán)限組件，當(dāng)我需要去除權(quán)限而另做新系統(tǒng)的時(shí)候這是見很麻煩的事情。AOP的好處在于可以以聲明方式來處理這些問題，例如你只需在需要驗(yàn)證的函數(shù)前加上一行屬性的描述或者在配置文件中寫上那些函數(shù)需要驗(yàn)證，執(zhí)行時(shí)AOP組件會(huì)按照你預(yù)先定制的先后順序執(zhí)行你的代碼，這樣我們可以輕松的剝離這些組件而絲毫不會(huì)對(duì)現(xiàn)有系統(tǒng)造成任何影響。

關(guān)于Service層的討論

       Service層是一個(gè)構(gòu)建于表示層于業(yè)務(wù)層之間的層，它是對(duì)業(yè)務(wù)層的一個(gè)淺封裝而不應(yīng)該封裝過多的業(yè)務(wù)邏輯，否則會(huì)造成不必要的麻煩。然而它并不是任何時(shí)候都有必要存在。一種情況下當(dāng)你的UI所要展現(xiàn)的東西和你的業(yè)務(wù)實(shí)體并不是那么完全吻合的時(shí)候，例如你的界面需要顯示若干個(gè)業(yè)務(wù)實(shí)體的一部分，但這并不是業(yè)務(wù)本身，只是一種展現(xiàn)方式。這時(shí)候你需要Service層來做一個(gè)展現(xiàn)邏輯的轉(zhuǎn)換。或者當(dāng)你在做分布式系統(tǒng)的時(shí)候可以利用Service層來實(shí)現(xiàn)一個(gè)粗粒度的服務(wù)接口。也可以以SOA（Service-oriented Architecture）的方式來理解Service層，我們最終使用的是系統(tǒng)所提供的服務(wù)而不是業(yè)務(wù)對(duì)象，所以需要將將業(yè)務(wù)對(duì)象以清晰的方式組織起來形成清晰的服務(wù)暴露在外。更多的情況在于你結(jié)合實(shí)際該如何使用。

結(jié)束語

it知識(shí)庫：應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。