今天咱們來談下三層架構。說到三層架構，搞過點程序的可能都知道三層架構的概念。但是對三層的精髓可能不是很了解。
首先說下自己對三層的理解，就是使用三個(多個)項目結合起來開發出一個應用系統。下層項目為上層項目提供了接口（說白了就是可以從上層類訪問下層類的方法），並且將結果返回到上層。
接下來咱們來看下三層的優勢
三層架構的優勢
- 適應變化、利於維護：項目需求往往隨市場的變化而發生變化，三層架構通過將各功能模塊分離，提高了項目的可維護性和代碼的可重用性。
- 適用於協作開發。
- 主流趨勢，越來越多的企業在開發項目時采用三層架構作為項目的基礎架構。三層架構在將來會有更多的市場。
當然，這些優勢在后續的開發中我們會有更新的體會。
了解過三層的優勢后，我們來看下三層架構究竟由哪三層組成，重點到了。
三層架構包括哪三層？
數據訪問層（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． 將用戶請求的數據封裝到實體對象中
業務邏輯層中使用實體類
- 將接收到的實體對象傳遞到下一層
- 根據用戶請求對實體對象中的數據進行處理。
在數據訪問層中使用實體類
- 將數據庫中的數據封裝到實體對象中或將多個實體對象封裝成集合
- 將實體對象中的數據保存到數據庫中
最后，我們來看下三層的效率。
三層的效率
三層一般會比不分層滿，但是為了分工明確，這樣的少量的性能下降是可以的，很多時候效率不是唯一追求的因素。
下次課內容咱們一起來使用三層開發一個簡單的日記系統。