ASP.NET三層結(jié)構(gòu)的說明及三層架構(gòu)的缺點(diǎn)
ASP.NET三層結(jié)構(gòu)說明
完善的三層結(jié)構(gòu)的要求是:修改表現(xiàn)層而不用修改邏輯層,修改邏輯層而不用修改數(shù)據(jù)層。否則你的應(yīng)用是不是多層結(jié)構(gòu),或者說是層結(jié)構(gòu)的劃分和組織上是不是有問題就很難說.不同的應(yīng)用有不同的理解，這只是一個概念的問題．
理解ASP.NET三層結(jié)構(gòu)——為什么要分三層？
我們用三層結(jié)構(gòu)主要是使項(xiàng)目結(jié)構(gòu)更清楚，分工更明確，有利于后期的維護(hù)和升級。它未必會提升性能，因?yàn)楫?dāng)子程序模塊未執(zhí)行結(jié)束時，主程序模塊只能處于等待狀態(tài)。這說明將應(yīng)用程序劃分層次，會帶來其執(zhí)行速度上的一些損失。但從團(tuán)隊(duì)開發(fā)效率角度上來講卻可以感受到大不相同的效果。
需要說明一下，三層結(jié)構(gòu)不是.NET的專利，也不是專門用在數(shù)據(jù)庫上的技術(shù)。它是一種更加普適的架構(gòu)設(shè)計理念。
此種架構(gòu)要在數(shù)據(jù)庫設(shè)計上注意表之間的關(guān)系，盡力滿足主與子的關(guān)系。在功能上對用戶要有一定的限制，不要表現(xiàn)在對于子表的刪除操作一定要慎重，以免造成主表與子表的數(shù)據(jù)在邏輯上出現(xiàn)的主表的外鍵在子表中沒有相對應(yīng)的值。
對于表的綜合查詢方法是：
先對主表查詢，調(diào)用主表所對應(yīng)的DL。再根據(jù)主表的記錄分別對每一個子表進(jìn)行查詢。將自表的查詢結(jié)果添加的主表后，形成一個大的查詢集合。
對于表的操作（增刪改）：
此時只對主表進(jìn)行操作，調(diào)用主表對應(yīng)的DL中的操作方法。
RL層是邏輯判斷層，主要是對頁面上傳入的數(shù)據(jù)進(jìn)行邏輯判斷。RL層之上就是UI
如何建立一個三層體系結(jié)構(gòu)解決方案
新建一個空白解決方案。然后：
“添加”－“新建項(xiàng)目”－“其他項(xiàng)目”－“企業(yè)級模版項(xiàng)目”－“C#生成塊”－“數(shù)據(jù)訪問”（數(shù)據(jù)層，下簡稱D層）
“添加”－“新建項(xiàng)目”－“其他項(xiàng)目”－“企業(yè)級模版項(xiàng)目”－“C#生成塊”－“業(yè)務(wù)規(guī)則”（業(yè)務(wù)層，下簡稱C層）
“添加”－“新建項(xiàng)目”－“其他項(xiàng)目”－“企業(yè)級模版項(xiàng)目”－“C#生成塊”－“Web用戶界面”（界面層，下簡稱U層）
右鍵點(diǎn)“解決方案”－“項(xiàng)目依賴項(xiàng)”，設(shè)置U依賴于D、C，C依賴于D。
對U添加引用D、C，對C添加引用D。
到此為止，一個三層的架子建立起來了。我上面說的很具體很“傻瓜”，知道的人覺得我廢話，其實(shí)我這段時間很強(qiáng)烈的感覺到非常多的人其實(shí)對這個簡單的過程完全不了解。雖然不反對建2個“空項(xiàng)目”和1個“Asp net Web應(yīng)用程序項(xiàng)目”也可以作為3層的框架，而且相當(dāng)多的人認(rèn)為其實(shí)這些“企業(yè)級模板項(xiàng)目”其實(shí)就是個空項(xiàng)目，這是一個誤區(qū)。沒錯，企業(yè)級模板項(xiàng)目你從解決方案資源管理器里看它是個什么也沒有的，但是你可以用記事本打開項(xiàng)目文件，看見不同了吧？？有些東西在背后，你是看不見的，不過系統(tǒng)已經(jīng)做好了。也就是說，如果你在C層里的某個類里“using System Data SqlClineit”，或者使用一個SqlConnection對象，編譯時候不會出錯，但是會在“任務(wù)列表”里生成一些“策略警告”，警告你在C層里不要放應(yīng)該放在D層的東西（雖然就程序來說沒錯，但是可讀性可維護(hù)性就打了折扣）而這種功能，空項(xiàng)目是無法給你的。
在新TraceLWord3中，應(yīng)用了“企業(yè)級模板項(xiàng)目”。把原來的LWordTask.cs，并放置到一個單一的項(xiàng)目里，項(xiàng)目名稱為：AccessTask。解決方案中又新建了一個名稱為：InterService的項(xiàng)目，該項(xiàng)目中包含一個LWordService.cs程序文件，它便是“中間業(yè)務(wù)層”程序。為了不重復(fù)命名，TraceLWord3的網(wǎng)站被放置到了WebUI項(xiàng)目中。更完整的代碼，可以在CodePackage/TraceLWord3目錄中找到——
ASP.NET三層結(jié)構(gòu)：面象對象與實(shí)際的結(jié)合
我們知道建橋需要磚塊，應(yīng)該是先準(zhǔn)備好磚再來建橋，不過為了講解上的順序性和連貫性，簡單性。我們先建橋，建的過程中需要磚塊再現(xiàn)做，這樣就不會多出來“橋不需要的東西”。注意在實(shí)際中，還是應(yīng)該先準(zhǔn)備磚塊。
U層其實(shí)就是橋，C層是磚塊，D層是原料（石頭、沙子）。這也解釋前面為什么U層要引用、依賴D層（而不是U對C，C對D的層次），因?yàn)闃虺诵枰u頭，其實(shí)也需要石頭沙子。
“三層結(jié)構(gòu)”的缺點(diǎn)
有些網(wǎng)友在讀完這篇文章前作之后，對我提出了一些質(zhì)疑，這提醒我文章至此還沒有提及“三層結(jié)構(gòu)”的缺點(diǎn)?！叭龑咏Y(jié)構(gòu)”這個詞眼似乎一直都很熱門，究其原因，或許是這種開發(fā)模式應(yīng)用的比較普遍。但是“三層結(jié)構(gòu)”卻并不是百試百靈的“萬靈藥”，它也存在著缺點(diǎn)。下面就來說說它的缺點(diǎn)……
“三層結(jié)構(gòu)”開發(fā)模式的一個非常明顯的缺點(diǎn)就是其執(zhí)行速度不夠快。當(dāng)然這個“執(zhí)行速度”是相對于非分層的應(yīng)用程序來說的。從文中所給出的時序圖來看，也明顯的暴露了這一缺點(diǎn)。TraceLWord1和TraceLWord2沒有分層，直接調(diào)用的ADO.NET所提供的類來獲取數(shù)據(jù)。但是，TraceLWord6確要經(jīng)過多次調(diào)用才能獲取到數(shù)據(jù)。在子程序模塊程序沒有返回時，主程序模塊只能處于等待狀態(tài)。所以在執(zhí)行速度上，留言板的版本越高，排名卻越靠后。“三層結(jié)構(gòu)”開發(fā)模式，不適用于對執(zhí)行速度要求過于苛刻的系統(tǒng)，例如：在線訂票，在線炒股等等……它比較擅長于商業(yè)規(guī)則容易變化的系統(tǒng)。
“三層結(jié)構(gòu)”開發(fā)模式，入門難度夠高，難于理解和學(xué)習(xí)。這是對于初學(xué)程序設(shè)計的人來說的。以這種模式開發(fā)出來的軟件，代碼量通常要稍稍多一些。這往往會令初學(xué)者淹沒在茫茫的代碼之中。望之生畏，對其產(chǎn)生反感，也是可以理解的……
其實(shí)，無論哪一種開發(fā)模式或方法，都是有利有弊的。不會存在一種“萬用法”可以解決任何問題。所以“三層結(jié)構(gòu)”這個詞眼也不會是個例外！是否采用這個模式進(jìn)行系統(tǒng)開發(fā)，要作出比較、權(quán)衡之后才可以。切忌濫用!
【編輯推薦】
