今天咱們來談下三層架構。說到三層架構，搞過點程序的可能都知道三層架構的概念。但是對三層的精髓可能不是很了解。

首先說下自己對三層的理解，就是使用三個(多個)項目結合起來開發出一個應用系統。下層項目為上層項目提供了接口（說白了就是可以從上層類訪問下層類的方法），并且將結果返回到上層。

接下來咱們來看下三層的優勢

三層架構的優勢

1. 適應變化、利于維護：項目需求往往隨市場的變化而發生變化，三層架構通過將各功能模塊分離，提高了項目的可維護性和代碼的可重用性。
2. 適用于協作開發。
3. 主流趨勢，越來越多的企業在開發項目時采用三層架構作為項目的基礎架構。三層架構在將來會有更多的市場。

當然，這些優勢在后續的開發中我們會有更新的體會。

了解過三層的優勢后，我們來看下三層架構究竟由哪三層組成，重點到了。

三層架構包括哪三層？

數據訪問層（DAL）、業務邏輯層（BLL）和UI（表示）層

數據訪問層：封裝了所有與數據庫的交互操作。數據交互無非就是增、刪、改、查(C:Create，

D:Delete  U:Update   R:Retrieve),數據訪問層就針對每個數據表提供增、刪、改、查操作，不做業務邏輯的判斷。

過去使用ADO.NET連接數據庫需要編寫固定格式的代碼，比如打開數據庫連接，關閉數據庫連接等。在面向對象的課程中，我們在每一個數據訪問層的方法中編寫重復的ADO.NET代碼。那么大家有沒有想過重用這些代碼呢？這里我們使用了一個封裝了ADO.NET方法的類----SqlHelper 類，用來提高數據訪問代碼的可重用性。

針對模型層中的每一個類，數據訪問層都有一個對應的數據訪問類。比如針對User實體類，有一個對應UserService類，專門處理有關Users表的數據處理。

接下來，咱們來對三層的理解更進一步。

三層深入理解

1.復雜項目不能把SQL語句直接寫到界面里，不模塊化、難以維護，應該采用三層架構。先慢慢吸收，然后再理解。Web開發中的三層機構也是同樣的結構。還有更復雜的三層架構和多層架構(petshop)每個人寫法都不一樣，理解精髓即可。

   這里需要說明：三層只是一個比較好的軟件架構，不是非使用三層不可。

 2.三層的組成

   01.界面層UI(User Intgerface);

02.數據訪問層DAL(Data Access Layer);

03.業務邏輯層BLL(business  logic  layer)

  對數據進行操作的代碼寫在DAL中，一般就是SQL語句，DAL只有對數據的操作，不能有邏輯判斷。

三層架構圖

三層實戰

咱們一起來創建一個三層項目

1.命名規則：DAL層，一般使用表名+Service，例如：Emp表在DAL層命名為EmpService。

BLL層，一般表名+BLL，例如：Emp表在BLL層命名為EmpBLL

但是這里注意一點：BLL不是簡單對DAL層的一個轉發，還包括業務邏輯。例如：“未經審核的數據不允許刪除”這樣的邏輯應該寫到BLL中。

2.三層的優點

UI層和BLL打交道，不用處理SQL語句；開發更方便，更不容易出錯。一般，UI層中沒有復雜的代碼，解耦合，容易改變UI層技術。如果由 Winform改成asp.net只要修改UI即可。如果由Sql Server改成Oracle，只需修改DAL即可。

這里還要提醒大家一點：Model是在三層之間傳遞數據的。而且Model不屬于三層中任意一層。

那么各層之間使用Model（實體類的作用是什么呢？？）

表示層中使用實體類：

1．  將解析實體對象中封裝的數據展示給用戶

2．  將用戶請求的數據封裝到實體對象中

業務邏輯層中使用實體類

1. 將接收到的實體對象傳遞到下一層
2. 根據用戶請求對實體對象中的數據進行處理。

在數據訪問層中使用實體類

1. 將數據庫中的數據封裝到實體對象中或將多個實體對象封裝成集合
2. 將實體對象中的數據保存到數據庫中

***，我們來看下三層的效率。

三層的效率

三層一般會比不分層滿，但是為了分工明確，這樣的少量的性能下降是可以的，很多時候效率不是唯一追求的因素。

下次課內容咱們一起來使用三層開發一個簡單的日記系統。