本篇主要講述ASP.NET應用中如何進行邏輯分層。本篇的前篇會從Smart UI 反模式和它的一些缺點開始講述，然后一步步的講述如何邏輯分層，而且在后篇中也會給出一個ASP.NET設計中常用的僅供參考的分層架構的Demo。

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

　　下面就先來看看Smart UI的設計方式。

　　Smart UI

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

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

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

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

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

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

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