舉例了解：
最近在學習三層架構，先舉個生活中常見的例子描述一下什麼叫三層？為什麼使用三層？
服務員隻管接待客人；廚師隻管烹炒客人要的美食；采購員隻管看客人需求采購食品；分工為客人全放全面的服務。
這樣即使某個服務員請假，那麼隻需要讓其他的服務員來代替就可，而不可能說讓廚師來代替吧！生活中如此，大家各自執行各自的職責，同步到軟體系統中來：
這就是所謂的三層架構，分層說明白點其實就是還是實作“高内聚，低耦合”的思想。
具體分析：
1）介紹：
UI:主要是對使用者的請求接受（假如顧客甲想要魚香肉絲，顧客乙想來個紅燒排骨……），以及資料的傳回，為用戶端提供應用程式的通路
BLL:針對具體問題的操作（針對顧客甲和乙的要求而進行操作），也可以說是對資料層的操作，對資料業務邏輯處理
DAL:該層所做事務直接操作資料庫，針對資料的增添，删除，修改，查找進行操作（有無胡蘿蔔，排骨等等這些都需要添加，或者某些菜不新鮮了，也要去除才可）等
2）需要遵循的規則：
- 最關鍵的，UI層隻能作為一個外殼，不能包含任何業務邏輯的處理過程，就如你是服務員的角色，服務好顧客就好，其他的和自己根本就無任何關系。
- 設計時應從BLL出發，而不是從UI出發，BLL層在API上，應該以面向對象的形式實作所有的業務邏輯；就如顧客去哪個飯店吃飯，雖然服務員的服務态度是必要的，但是最主要的還是看這個飯店的餓菜做的好不好吃，也就是說廚師的技術如何了，是以飯店在招聘的時候，還是以招聘高技術的廚師為主要。
- 不管資料層是一個簡單的COM+,還是Remoting，還是WebService子類的遠端對象技術，不管部署的時候是否真的部署到不同的伺服器上，最起碼在設計的時候要有這樣的考慮.
3)從OOP思想考慮：
- 它是完全受控制的對象；
- 它具有面向對象的基本特征；
- 它可以自定義行為；
- 它消除了關系資料和對象之間的差異；
它為我們在關系資料庫和對象之間架起一座橋梁。
對于三層，自己個人的了解則是不管職責簡不簡單，既然分工了，那就各自把各自的任務完成就好。不是因為某個層特别簡單，就認為他不重要。隻要分了層，每一層都要有明确的目的和功能實作，對于三層的了解，待下一篇部落格繼續學習。