修練營ASP.NET]淺談多層式架構 (Multi Tiers)
從需求談起
我們舉個小例子來理解一般的方式與多層的方式有何不同
假設：我需要顯示最近三個月內，所有營業員的銷售金額成績排名
一般的做法：
在一個畫面中，拉個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(請參考小喵這篇【確保交易的新利器(TransactionScope)初體驗-Part 1(注意Scope.Complete的位置)】)來輕鬆解決這個問題。
實體分層的交易：
小喵剛提到，實體分層可以透過【COM+】與【WCF】來實現這個架構。但是或許有些人會問：WebService不是也支援Transaction，那使用【WebService】是不是也可以呢?經過小喵測試結果(Web Service呼叫Web Service使用Transaction確保交易完整性測試報告)，WebService呼叫WebService的時候，無法將兩個WebService包成一個完整的交易(Transaction)，因此單純的使用WebService是不行的。
總結
多層系統架構，可以讓我們的系統變得更有彈性，讓介面與資料庫可以更靈活的抽換。而且開發過程中，由於切分了不同的層。也可以讓不同的人負責不同的層級，多人一起協同開發。有些然專門處理畫面設計，有些人負責寫商業邏輯，有些人負責資料存取。而商業層級，也可以由負責不同系統的人，開發他自己的部分，讓彼此專注於自己的Domain KnowHow開發商業邏輯元件，之後再結合運作。對於開發大型的系統，建議最好能夠用多層的架構來開發。
转自：http://www.dotblogs.com.tw/topcat/archive/2009/09/11/10577.aspx#65121
