實(shí)戰(zhàn)項(xiàng)目分析

1、實(shí)戰(zhàn)項(xiàng)目分析最近接到一個(gè)臨時(shí)任務(wù)：幫外國(guó)某知名公司分析一個(gè)項(xiàng)目架構(gòu)。這個(gè)項(xiàng)目是兩年前開(kāi)發(fā)的，并且經(jīng)過(guò)了幾次升級(jí)。主 要功能是管理客戶、合作伙伴資料，提供在線業(yè)務(wù)等等，具體細(xì)節(jié)不用多說(shuō)。據(jù)客戶說(shuō)，他們?cè)谑褂帽鞠到y(tǒng)的過(guò)程中發(fā)現(xiàn)了很多的問(wèn)題，覺(jué)得已經(jīng)不再滿足他們的需求，希望我們能幫助他們?cè)u(píng)估 一下當(dāng)前的系統(tǒng)有哪些架構(gòu)上的問(wèn)題，并幫助他們發(fā)現(xiàn)未來(lái)可能發(fā)生的問(wèn)題，從而決定是否需要開(kāi)發(fā)新的系統(tǒng)客戶提供了很詳細(xì)的文檔，包括業(yè)務(wù)說(shuō)明，系統(tǒng)架構(gòu)，技術(shù)要點(diǎn)，部署方案等等?？赐晡臋n，對(duì)系統(tǒng)和客戶期望有了 一定的了解之后，開(kāi)始干活兒！系統(tǒng)是采用.Net技術(shù)構(gòu)建的，基于.Net Framework 2.0,使用了 AS

2、P.NET, WinForm, WebService 等技術(shù)，并使用了 Enterprise Library 中的 Data Access， Cache， Log 等功能。我本人負(fù)責(zé)的是架構(gòu)的分析。結(jié)合文檔和源代碼，沒(méi)用1個(gè)小時(shí)，系統(tǒng)架構(gòu)就很清晰了。其中發(fā)現(xiàn)了一些很普遍的問(wèn)題，在這里跟大家分享一下：1. 分層架構(gòu)分層架構(gòu)是絕大部分企業(yè)軟件都普遍采用的方案，但由于架構(gòu)師水平的參差不齊，導(dǎo)致很簡(jiǎn)單的一個(gè)分層，出現(xiàn)了很 大的差異。大家都知道“3層架構(gòu)”或者多層架構(gòu)”。有點(diǎn)理論里分3層，有點(diǎn)理論里分 5層，還有分7層的。其實(shí)，在我看來(lái)分 幾層不重要，重要的是分層的目的。分層是為了什么的？簡(jiǎn)單的說(shuō)就一句

3、話：為了便于維護(hù)。大家都知道，軟件開(kāi)發(fā)中變化”才是永恒的。開(kāi)發(fā)周期是死的（盡管可以一拖再拖，但總有一個(gè)發(fā)布的截至日期吧！），但后期的維護(hù)卻是很不變得。不管是發(fā)布補(bǔ)丁也好，更新版本也好，其實(shí)都是為了能適應(yīng)軟件發(fā)布之后面臨的各種各樣 的變化”。好，我們回到分層上來(lái)。分層，就是為了使系統(tǒng)結(jié)構(gòu)更清晰，系統(tǒng)耦合性變小，使修改一處代碼時(shí)，對(duì)其它的部分影 響最小，這樣就能以最小的代價(jià)應(yīng)對(duì)變化帶來(lái)的麻煩！所以，分層的第一要素，就是各層之間屏蔽細(xì)節(jié)，降低依賴，使 各層具體實(shí)現(xiàn)變得透明（這也是SOA的其中一個(gè)重要思想）。我們可以通過(guò)各種辦法來(lái)達(dá)到這個(gè)目的，面向接口編程，設(shè)計(jì)模式，架構(gòu)模式等等，都可以幫助我們。而我

4、在此項(xiàng)目中看到的第一個(gè)重要的問(wèn)題就是，系統(tǒng)分層不清楚。下面是分層的簡(jiǎn)圖：展現(xiàn)層公共模塊強(qiáng)類型業(yè)#對(duì)象業(yè)務(wù)邏輯層數(shù)據(jù)存取層fl數(shù)據(jù)庫(kù)由上圖可見(jiàn)，系統(tǒng)共分了三層。但有一個(gè)問(wèn)題，業(yè)務(wù)對(duì)象竟然貫穿了三層，這嚴(yán)重違反了分層的初衷。由于業(yè)務(wù)對(duì)象對(duì)數(shù)據(jù)存取層和展現(xiàn)層都可見(jiàn)，導(dǎo)致如果我們的業(yè)務(wù)對(duì)象發(fā)生了變化，就要修改從數(shù)據(jù)存取、業(yè)務(wù)邏輯到展現(xiàn)層，這三個(gè)層次的所有相關(guān)代碼。而且這個(gè)方案違反了分層的兩個(gè)設(shè)計(jì)原則：a. 下層對(duì)上層隱藏細(xì)節(jié)，只暴露接口。再此，本應(yīng)屬于業(yè)務(wù)邏輯層的業(yè)務(wù)對(duì)象被暴露到了展現(xiàn)層。b. 上層對(duì)下層不可見(jiàn)。即下層不知道上層的存在，只提供接口。這里業(yè)務(wù)邏輯層的業(yè)務(wù)對(duì)象被數(shù)據(jù)存取層操作，會(huì)導(dǎo)致兩個(gè)層

5、之間糾纏不清，以至于會(huì)出現(xiàn)改動(dòng)業(yè)務(wù)邏輯會(huì)影響數(shù)據(jù)存取方式的荒謬現(xiàn)象。另外，強(qiáng)類型 DataSet也有同樣的問(wèn)題（本應(yīng)是屬于數(shù)據(jù)存取層的，卻被傳遞到業(yè)務(wù)邏輯層，甚至是展現(xiàn)層）軟件設(shè)計(jì)中有一個(gè)很重要的原則就是：依賴倒置原則（DIP）依賴倒置的意思是：調(diào)用者依賴被調(diào)用者的接口，而不是實(shí)現(xiàn)。具體到此處就是：業(yè)務(wù)邏輯層應(yīng)該依賴數(shù)據(jù)存取層的接口，而不是具體實(shí)現(xiàn)（強(qiáng)類型DataSet）。由于被調(diào)用者編程了抽象，而調(diào)用者變成了實(shí)現(xiàn)”所以與普通的面向?qū)ο蟮挠^念來(lái)說(shuō)，依賴關(guān)系被倒置了，因此被稱作依賴倒置原則。依賴倒置在分層結(jié)構(gòu)中是很重要的原則。希望每一個(gè)設(shè)計(jì)者都時(shí)刻把它記在心間吧，呵呵。2. 面向接口編程其實(shí)這跟

6、上一個(gè)問(wèn)題有密切聯(lián)系。面向接口編程，是依賴于抽象，而不是實(shí)現(xiàn) ”的具體手段。不管是模塊內(nèi)部，還是個(gè)層次之間，面向接口是消除依賴的基礎(chǔ)。舉一個(gè)簡(jiǎn)單的例子：本系統(tǒng)中業(yè)務(wù)邏輯層會(huì)調(diào)用數(shù)據(jù)存取層的方法，得到一些數(shù)據(jù)。比如調(diào)用一個(gè)PartnerAccess類的GetPartner的方法。PartnerAccess是數(shù)據(jù)存取層的一個(gè)具體類，負(fù)責(zé)Patrner表的所有增刪改查操作。而業(yè)務(wù)邏輯層到處充斥著這樣的語(yǔ)法：PartnerAccess partnerac = new PartnerAccess ()； partnerac.getPartner ()；這就是一個(gè)典型的依賴于具體實(shí)現(xiàn)的方案。這樣的后果是，

7、業(yè)務(wù)邏輯層知道每一個(gè)數(shù)據(jù)表的數(shù)據(jù)結(jié)構(gòu)，甚至是無(wú)需知 道的細(xì)節(jié)，并且對(duì)數(shù)據(jù)層的每一個(gè)方法都了如指掌，到處都在使用。當(dāng)我們開(kāi)始修改PartnerAccess的其中一個(gè)方法的時(shí)候(比如增加一個(gè)參數(shù))都要修改業(yè)務(wù)邏輯層的相關(guān)代碼，但誰(shuí)知道那些代碼都在哪呢？只好重新編譯吧，讓編譯器告 訴我們。而面向接口編程可以使我們避免這種問(wèn)題。我們不再依賴于千千萬(wàn)萬(wàn)個(gè)PartnerAccess或者什么別的 Access類，而是依賴一個(gè)IDataAccess的接口。這樣，所有的數(shù)據(jù)存取都被標(biāo)準(zhǔn)化，我們的調(diào)用代碼便的更簡(jiǎn)單，不會(huì)依賴任何數(shù)據(jù)庫(kù)的 結(jié)構(gòu)，甚至不需要知道表的名字，有多少個(gè)字段等等。當(dāng)我們?cè)黾右粋€(gè) OrderA

8、ccess類時(shí)，只需在數(shù)據(jù)存取層增加一個(gè)文 件，一個(gè)類就好了，而不需要更改業(yè)務(wù)邏輯層的任何代碼。記住這個(gè)原則吧，它也可以說(shuō)是面向?qū)ο蟮暮诵乃枷?。?huì)讓你受益匪淺的！3. 領(lǐng)域模型不清晰從上面的圖中可以看出來(lái)，本系統(tǒng)同時(shí)使用了兩種領(lǐng)域模型，一種是業(yè)務(wù)對(duì)象(Business Object)，一種是強(qiáng)類型 DataSet(Strong Type DataSet)，并且在每個(gè)層次中都使用了。舉個(gè)簡(jiǎn)單的例子：強(qiáng)類型 DataSet被應(yīng)用到ASP.NET的控件綁定上，用來(lái)顯示數(shù)據(jù)。而業(yè)務(wù)對(duì)象被WebService暴露給客戶端。如果有人看過(guò)馬丁 福勒的那本企業(yè)架構(gòu)模式的話，應(yīng)該會(huì)記得對(duì)領(lǐng)域模型的選擇上有幾種方

9、案。其中業(yè)務(wù)對(duì)象 和強(qiáng)類型DataSet都被提到了，并且說(shuō)明了什么時(shí)候適用哪個(gè)模型。這里我不多說(shuō)，感興趣的朋友可以去看看那本書(shū)。我想說(shuō)的是，這里使用了兩個(gè)模型并存的方案。這樣就使得系統(tǒng)的領(lǐng)域模型不清晰，而且存在很多的冗余，例如出現(xiàn) 了 Partner業(yè)務(wù)對(duì)象和PartnerDS強(qiáng)類型DataSet并存的現(xiàn)象，盡管他們各有各的優(yōu)缺點(diǎn)，但這樣勢(shì)必會(huì)造成領(lǐng)域模型的 難于維護(hù)和代碼可讀性差的問(wèn)題。其實(shí)，特殊情況下，也可以兩個(gè)同時(shí)使用，但要注意，由于業(yè)務(wù)對(duì)象是屬于業(yè)務(wù)邏輯層的，而強(qiáng)類型DataSet是數(shù)據(jù)存取層的，所以他們都要在自己的范圍內(nèi)活動(dòng)，不能被其它的層次存取。到這里，有人可能會(huì)發(fā)現(xiàn)一個(gè)矛盾就是：

10、使用單一業(yè)務(wù)對(duì)象的話，則會(huì)對(duì)數(shù)據(jù)存取層帶來(lái)額外的開(kāi)銷，因?yàn)閿?shù)據(jù)存取層不能知道業(yè)務(wù)對(duì)象的存在，就需要使用抽象，會(huì)帶來(lái)一些代價(jià)。但如果使用單一的強(qiáng)類型DataSet的話，就會(huì)對(duì)業(yè)務(wù)邏輯層和展現(xiàn)層保留很多的內(nèi)部數(shù)據(jù)細(xì)節(jié)，也會(huì)對(duì)系統(tǒng)架構(gòu)造成一些影響，而且也不利于WebService的傳輸。其實(shí)，一個(gè)合格的設(shè)計(jì)師，需要對(duì)這兩種方案做各自的調(diào)整，都為自己所用，但只取他們的優(yōu)勢(shì)，而避免他們的劣勢(shì) 多帶來(lái)的麻煩。軟件設(shè)計(jì)，何嘗又不是一種取舍的藝術(shù)呢！4. 強(qiáng)類型DataSet上面講到了業(yè)務(wù)對(duì)象和強(qiáng)類型DataSet兩種領(lǐng)域模型的使用問(wèn)題。其實(shí)強(qiáng)類型DataSet是.NET中很好的一種方案，它集成了數(shù)據(jù)庫(kù)和面向

11、對(duì)象兩種優(yōu)點(diǎn)，如果使用的好的話，會(huì)事半功倍，但使用不好的話，麻煩也很大。在本系統(tǒng)中，強(qiáng)類型 DataSet被賦予很多使命：從數(shù)據(jù)庫(kù)中獲取信息（數(shù)據(jù)存取層）、業(yè)務(wù)處理（業(yè)務(wù)邏輯層）和數(shù) 據(jù)展現(xiàn)（展現(xiàn)層），貫穿了整個(gè)系統(tǒng)。這樣就使得整個(gè)系統(tǒng)對(duì)強(qiáng)類型DataSet的數(shù)據(jù)結(jié)構(gòu)非常依賴，一旦數(shù)據(jù)庫(kù)發(fā)生變化，所有的代碼（從數(shù)據(jù)存取到展現(xiàn)層）都要修改代碼來(lái)。 并且最要命的是強(qiáng)類型 DataSet可以自動(dòng)感知數(shù)據(jù)庫(kù)的變化，自動(dòng)更新同步。試想，如果你是這個(gè)系統(tǒng)的編碼人員，會(huì)不會(huì)時(shí)時(shí)都提心吊膽呢？很顯然，這是一種糟糕的設(shè)計(jì)。在分層結(jié)構(gòu)中，任何數(shù)據(jù)結(jié)構(gòu)都不能貫穿始終，特別是與數(shù)據(jù)庫(kù)結(jié)構(gòu)。這回帶來(lái)難以 置信的麻煩。分

12、層，其實(shí)就是要隔離這種變化給系統(tǒng)帶來(lái)的連鎖反應(yīng)。使底層的修改不影響到頂層，反之亦然。當(dāng)然這是不是意味著強(qiáng)類型DataSet就不能使用了呢？當(dāng)然不是的。強(qiáng)類型DataSet是非常好的連接數(shù)據(jù)存取層和業(yè)務(wù)邏輯層的紐帶，因?yàn)樗扔袛?shù)據(jù)庫(kù)結(jié)構(gòu)又有對(duì)象特性。所以，只要我們能在兩個(gè)層次中各自屏蔽細(xì)節(jié)，依賴于抽象而 不是實(shí)現(xiàn)，強(qiáng)類型 DataSet就可以在系統(tǒng)中發(fā)揮重要的作用。5. 展現(xiàn)層太臃腫本系統(tǒng)的很大一部分 UI都是B/S的，采用ASP.NET構(gòu)建。但我發(fā)現(xiàn)很多的 WebPage中包含有大量的界面邏輯和業(yè) 務(wù)邏輯，基本每個(gè) WebPage的代碼都在幾百行，有點(diǎn)甚至上千行。試想，這樣的UI維護(hù)起來(lái)對(duì)于每

13、一個(gè)開(kāi)發(fā)者來(lái)說(shuō)，大概都經(jīng)歷過(guò)這種痛苦，為了數(shù)據(jù)庫(kù)的一個(gè)字段的修改，要從底層到頂層，全部修改一便， 而且UI的修改是最麻煩的，往往是越改越煩！其實(shí)對(duì)于UI的設(shè)計(jì)模式已經(jīng)很成熟了，大家都知道MVC模式吧。就是一個(gè)很成熟，很實(shí)用的UI設(shè)計(jì)模式。另外還有MVP模式，這個(gè)是 MVC的基礎(chǔ)之上提出來(lái)的，跟 MVC思想相同，但細(xì)節(jié)上有所不同而已。MVC模式網(wǎng)上有很多的資料，也有很多有名的應(yīng)用案例。MVP則被廣泛應(yīng)用在微軟 P&P團(tuán)隊(duì)的很多項(xiàng)目中，諸如： Software Factory系列中都有應(yīng)用。下面是MVC模式和MVP模式的對(duì)比：另外，關(guān)于兩種模式的詳細(xì)對(duì)比，可以參考另一位 MVP:TreeLee的文

14、章：ASP.NET MVC Framework 與 WCSF中MVP模式之小小比較。6. 自定義事務(wù).Net framework 2.0中內(nèi)置了對(duì)事務(wù)的支持，不但可以管理進(jìn)程內(nèi)的事務(wù)（包括SQLServer事務(wù)），還可以自動(dòng)提升至MSDTC來(lái)管理分布式事務(wù)（包括 WCF事務(wù)）。所以我們無(wú)需再編寫(xiě)任何事物的管理代碼。本系統(tǒng)中使用了 Enterprise Library中的Data Access Application Block 作為數(shù)據(jù)存取方案。但卻沒(méi)有很好地利用.Netframework 2.0的事務(wù)功能，而是自己寫(xiě)了很多管理事務(wù)的代碼。例如使用一個(gè) Transactioncontext類管理事務(wù)的執(zhí)行，在很多數(shù)據(jù)存取的方法上支持傳入 TransactionCont