而面向接口編程可以使我們避免這種問(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è)OrderAccess類時(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)域模型的選擇上有幾種方案。其中業(yè)務(wù)對(duì)象和強(qiáng)類型DataSet都被提到了，并且說(shuō)明了什么時(shí)候適用哪個(gè)模型。這里我不多說(shuō)，感興趣的朋友可以去看看那本書。

我想說(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è)矛盾是：使用單一業(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ù)和面向?qū)ο髢煞N優(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)難以置信的麻煩。分層，其實(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ì)于每一個(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的文章：ASP.NET MVC Framework與WCSF中MVP模式之小小比較。