深入淺出三層架構三層架構概念：代碼剖析：總結：

<a></a>

<b>閱讀目錄</b>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label0">三層架構概念：</a>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label1">代碼剖析：</a>

<a href="http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html#_label2">總結：</a>

這幾天看了不少三層架構的資料，整理整理

——故寫篇博文談談自己的看法。

三層架構(3-tier application) 通常意義上的三層架構就是将整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、資料通路層（DAL）。區分層次的目的即為了“高内聚，低耦合”的思想，複雜項目不能把SQL語句直接寫到程式裡，不子產品話，難以維護。應該采取三層架構。

1、表現層（UI）：通俗講就是展現給使用者的界面，即使用者在使用一個系統的時候他的所見所得。

2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。

3、資料通路層（DAL）：該層所做事務直接操作資料庫，針對資料的增添、删除、修改、查找等。

簡單的說，UI層調用BLL，BLL調用DAL，資料用Model進行傳遞，Model為各層之間架起了資料傳輸的橋梁。

參考模型：UI&lt;--&gt;Model&lt;--&gt;BLL&lt;--&gt;Model&lt;--&gt;DAL

下面我以一個簡單的例子來細數三層架構：

建立一個項目（Windows 窗體應用程式），再在根目錄下建立3個檔案夾，分别是Model,DAL,BLL。

在Model下添加一個Person類

在DAL下添加一個SQLHelper類和一個PersonDAL類。

在BLL下添加PersonBLL類

SQLHelper類，封裝了資料庫操作的方法：

進行邏輯判斷的BLL層代碼看似是這樣的：

PersonBLL.cs代碼如下：

UI層進行測試：

　　1、開發人員可以隻關注整個結構中的其中某一層；

　　2、可以很容易的用新的實作來替換原有層次的實作；

　　3、可以降低層與層之間的依賴；

　　4、有利于标準化；

　　5、利于各層邏輯的複用。

　　1、降低了系統的性能。這是不言而喻的。如果不采用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中間層來完成。

　　2、有時會導緻級聯的修改。這種修改尤其展現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料通路層中都增加相應的代碼。

　　3、增加了開發成本。

本文轉自木宛城主部落格園部落格，原文連結：http://www.cnblogs.com/OceanEyes/archive/2012/02/10/SANCENG.html，如需轉載請自行聯系原作者