.NET應用三層架構分析

    近來在作一個.NET的項目，使用C#進行開發。項目採用經常使用的三層架構，稍微調查了一下，發現所接觸到的.NET的項目基本都是採用這種架構，因而也來分析一下這種常見的三層架構的含義、特色以及優缺點。
    .NET中的三層架構，一般是指表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL），
偶爾也會加上實體類庫（Model）。
    表現層（UI）有時也會成爲視圖（VIEW），主要包括數據的呈現、UI的控制等，不涉及具體的業務邏輯，僅負責單純的表示。業務邏輯層（BLL）主要負責業務邏輯和數據的編輯處理，複雜的業務處理主要放在這一層。數據訪問層（DAL）則是負責對數據源進行訪問和修改等處理，並將取得的數據返回到業務邏輯層（BLL）。
    三層架構的推出，有如下的目標。
    1、修改維護的簡便性。
        一些修改或者變動，能夠集中在其中一層進行，進行局部而不是全局的修改，能夠儘可能將影響範圍縮小。
    2、處理的分佈式處理。
        處理分紅三層了，結構也就能夠分散了，能夠在一臺機器上運行，也能夠分佈在多臺機器上運行，
有利於靈活部署系統。
    正是三層架構的這種針對性的目標，也便有了隨之而來的優缺點。
優勢
一、便於做業分割，開發人員能夠只關注整個結構中的其中某一層；
二、便於處理的替換，能夠很容易的用新的實現來替換原有層次的實現；
三、便於邏輯的解耦，能夠下降層與層之間的依賴；
四、便於各層邏輯的複用；
五、便於修改維護，下降了維護成本和維護時間。
缺點
一、下降了系統的性能。原本能夠直接訪問數據的處理，如今須要經過中間層進行。
二、有時會致使級聯的修改。在表現層須要增長一個功能，可能也要增長邏輯層和數據訪問層的代碼。
三、一般會有不少重複性的代碼。

    若是系統比較簡單，三層能夠放在同一臺機器上；若是稍微複雜一些的，能夠將表現層（UI）放在客戶端，業務邏輯層（BLL）和數據訪問層（DAL）放在服務器端，採用C/S或者B/S的方式部署；更復雜一些的，也能夠將數據庫再單獨放在專用的服務器上，在服務器端增長緩存和負載平衡等部件。