本篇主要講述ASP.NET應(yīng)用中如何進(jìn)行邏輯分層。本篇的前篇會從Smart UI 反模式和它的一些缺點(diǎn)開始講述，然后一步步的講述如何邏輯分層，而且在后篇中也會給出一個ASP.NET設(shè)計中常用的僅供參考的分層架構(gòu)的Demo。

　　一個穩(wěn)定和易維護(hù)的系統(tǒng)必須建立在一個好的基礎(chǔ)之上。計劃和設(shè)計一個好的架構(gòu)對一個項(xiàng)目的成敗起著至關(guān)重要的作用。可能在我們一般做項(xiàng)目的時候，經(jīng)驗(yàn)告訴我們：3層，N層的設(shè)計，基本就能把問題解決了，很多的情況確實(shí)是這樣的。在提出一個設(shè)計的時候，常常要考慮為什么要這樣劃分結(jié)構(gòu)，而且常常要承擔(dān)風(fēng)險和責(zé)任，特別是萬一這個項(xiàng)目因?yàn)樽畛醯脑O(shè)計而導(dǎo)致崩潰，那就郁悶了。所以設(shè)計的提出一定和考慮業(yè)務(wù)。

　　下面就先來看看Smart UI的設(shè)計方式。

　　Smart UI

　　想想我們最初是如何開發(fā)ASP.NET的應(yīng)用的:在頁面設(shè)計界面中把界面布局好，然后雙擊控件就開始編寫功能代碼。很多的時候把邏輯判斷和數(shù)據(jù)訪問都寫在頁面的.cs的文件中。后來我們學(xué)習(xí)到了分層，逐漸的明白了這種方式的缺點(diǎn)：導(dǎo)致業(yè)務(wù)邏輯代碼到處分散而且重復(fù)，不利于以后的更改和維護(hù)等。

　　盡管有上述說的一些缺點(diǎn)，Smart UI還是有它的用途的，如為項(xiàng)目快速的建立一個原型或者開發(fā)一個功能比較的小的項(xiàng)目。還有一個問題，如何最初用Smart UI的方式開發(fā)的小項(xiàng)目很成功，慢慢的變大，變復(fù)雜了，那么很多的問題就出來了。就像Flower在架構(gòu)模式一書中提到的：盡量用領(lǐng)域模型來組織一個項(xiàng)目的業(yè)務(wù)邏輯，盡管在開始的時候邏輯不復(fù)雜或者看不出這種方式的好處，一旦項(xiàng)目變化，好處就顯而易見了。在對項(xiàng)目原型開發(fā)中，盡量不用Smart UI。

　　其實(shí)Smart UI最大的問題就是：職責(zé)不清—把所有的東西全部寫在一起。為了和以后講述的內(nèi)容的比較，我還是寫一個例子出來，很多朋友都已經(jīng)對這種Smart UI的開發(fā)方式很熟悉了，可以跳過下面的例子。在例子中，我們會用電子商務(wù)中一個常見的場景：一個頁面來顯示一個產(chǎn)品的列表信息，如名字，推薦的零售價格(Recommend Retail Price)，折扣，和庫存等。（如果朋友們愿意，可以照著下面的步驟一起做）

　　1． 打開Visual Studio，并且建立一個”空白的解決方案”,命名為:ASPPatterns.Chap3.SmartUI，然后添加一個新的Web項(xiàng)目，命名為:ASPPatterns.Chap3.SmartUI.Web.

　　2． 在新建的Web項(xiàng)目中右擊：Add—New Item,添加一個Sql Server的數(shù)據(jù)文件：Shop.mdf.

NET技術(shù)：走向ASP.NET架構(gòu)設(shè)計——第三章：分層設(shè)計，初涉架構(gòu)（前篇），轉(zhuǎn)載需保留來源！

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