前言：
如果使用ASP來處理複雜的商業邏輯的網頁應用系統，會有以下幾個缺點：
 
ASP內容複雜：如果處理資料需要複雜的處理、那麼asp會變成複雜許多
安全性：把資料的讀取、維護寫在ASP中並不安全，因為可能為駭客透過特定的方式查知您的asp程式的內容，進而知道您的資料庫、資料表、欄位、甚至您的商業邏輯
不易處理資料庫交易(Transaction)：如果需要維護多個資料表、甚至多個資料庫，那麼要維持資料異動得完整性(全部的資料表維護成功才算、只要有其中一個環節失敗，維護的資料要還原回去)
因此，為了因應以上的幾個需求，因此有了三層式的網頁應用系統架構。
 
將網頁的應用系統，拆成三個部份
介面層(IIS)：用來負責使用者的介面與資料展示介面的產生，把原來ASP中負責畫面處理的不份保留在此層
資料層(DB)：用來負責資料的新增、修改、刪除、查詢
商業邏輯層(COM+)：至於複查的資料處理、商業邏輯、資料異動的一致性等複雜的工作，就交由中間的【商業邏輯層】來處理。
 
一般的做法：
在一個畫面中，拉個GridView，一個SqlDataSouce，把需求的語法設定好在SqlDataSouce之後，接著顯示出來就可以了。
這樣的做法，從【資料的展現】【商業邏輯的條件設定】【資料庫的存取】都在一個畫面中處理完畢。
 
這樣的做法，可以說把所有的東西通通寫在畫面的程式裡面。但是如果哪天想到，介面想改成Windows Form、WPF、SilverLight、PDA去呈現，那麼我們一切都必須重新寫過
 
分層做法：
如果我們把介面抽離出來，例如使用元件負責處理【商業邏輯條件設定】與【資料的存取】，那麼就會變成如下

此時介面的部分只是負責畫面的呈現，他的資料來源是從中間的元件而來，這樣未來如果想改介面為其他的方式(Windows Form、WPF'、SilverLight、PDA)，那麼中間的部分就可不必重寫，只需把介面重寫後再與元件結合
進一步的切分(商業邏輯層、資料存取層)
假設本來的系統，資料的架構比較小、量也不大，因此開發初期使用Access作為資料庫，而當架構變大了，資料變多了，想要用MS SQL Server來處理資料，那麼我們可以很慶幸的，介面層的部分可以不用更動。但是中間層可能有很多的語法、很多的資料存取有所不同了，因此將需要大幅的改寫中間層的程式。但是如果，我們將【商業邏輯條件】與【資料存取動作】在切分開來，那麼中間層的邏輯條件判斷將不須變更，只需將資料存取的部分做改寫。這樣的架構將變成如下。這樣的架構下，未來資料庫就可以變更而不動到商業邏輯層，只需改寫資料存取層。

因此在多層架構中，就會區分為【介面層】、【商業邏輯層】、【資料存取層】這三層，一般成之為【三層架構(3 Tier)】。那又何來的多層呢??在較為大型的系統中，可能區分為各個不同的部分(例如：製造、管理、庫存、銷售、物流、服務維修、…)等。因此中間層可能依照各個不同的屬性，各自獨立在不同的程式中，我們把每個部分設定為一個層的話，這些層式對等的，但是有些時候又需要互相協調合作，此時就可能出現多層的架構，例如：銷售時，須檢查庫存，維護庫存，接著要產生物流的送貨如下圖，因此區分出來的商業邏輯層，不只可以獨立的運作，也可以與其他的商業邏輯層協同運作，形成多層架構。
 
實踐多層架構的幾個方式
虛擬分層與實體分層
虛擬分層：
所謂的虛擬分層，是指【介面層】、【商業邏輯層】、【資料存取層】在相同的主機上運作，是邏輯上的分層。
 
由於都在相同的主機上運作，所以架構上單純許多，可以透過類別(Class)來撰寫【商業邏輯層】與【資料存取層】
 
實體分層：
而實體的分層，就可能這三層分別在不同的主機上，甚至商業邏輯層可能有多部的主機，分別處理各自的商業邏輯(例如：製造、管理、庫存、銷售、物流、服務維修、…都有各自的主機)

在如何實踐上，實體分層就複雜多了，由於主機不同，彼此又要協調合作，變成要處理【分散式交易】。可以透過【COM+】、【WCF】來實現這的架構
 
分層架構需注意【交易(Transaction)的完整性】
通常系統在未分層之時，在處理資料維護的時候，因為維護的程式與語法通通寫在一起，所以要處理交易(Transaction)，並不困難，在ADO.NET中，甚至在stored procedure處理即可。但是分層後，很容易就忽略了這個部分，造成資料維護一半發生問題後，沒有辦法全部Rollback，造成資料的異常。
虛擬分層的交易：
由於系統運作在同一主機中，沒有分散交易的問題。因此可以透過TransactionScope來輕鬆解決這個問題。
實體分層的交易：
實體分層可以透過【COM+】與【WCF】來實現這個架構。但WebService呼叫WebService的時候，無法將兩個WebService包成一個完整的交易(Transaction)，因此單純的使用WebService是不行的。
 
總結
多層系統架構，可以讓我們的系統變得更有彈性，讓介面與資料庫可以更靈活的抽換。而且開發過程中，由於切分了不同的層。也可以讓不同的人負責不同的層級，多人一起協同開發。有些然專門處理畫面設計，有些人負責寫商業邏輯，有些人負責資料存取。而商業層級，也可以由負責不同系統的人，開發他自己的部分，讓彼此專注於自己的Domain KnowHow開發商業邏輯元件，之後再結合運作。對於開發大型的系統，建議最好能夠用多層的架構來開發。