從行為型模式命令模式引發的對三層的思考。
記得《大話設計模式》中對命令模式的講解。燒烤攤和燒烤店之間的區別。
由於客戶和烤羊肉串老闆的「緊耦合」所以容易出錯，容易混亂，也容易挑剔。
這其實就是「行為請求者」與「行為實現者」的緊耦合。
對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，「行為請求者」與「行為實現者」的緊耦合是不太適合的。
作為客戶不用去認識烤肉者是誰，連他的面都不用見到，我們只需要給接待我們的服務員說我們要什麼就可以了。他可以記錄我們的請求，然後再由他去讓烤肉師傅做。
烤肉師傅也不用知道具體的客戶是誰，只要知道客戶詳細的要求就行了，然後根據先後順序操作，不會混亂也不會遺忘。
而燒烤師傅取材料進行加工的時候又可以用構造型模型，如：工廠模式。
三層模型提高了程式的擴充套件性，可維護性，降低了模組之間的耦合。
對於使用使用者較少的程式來說，三層並沒有什麼必要。
但是對於，使用者較多，功能複雜的程式軟體來說，進行功能劃分和提高資源使用效率和通訊效率是很重要的。三層只是從一跨到了三，其中還有可以細化的部分
之後我們還要學習七層以提高使用者使用軟體的體驗。
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個中間層，也叫元件層。
這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也不僅僅有b/s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。
❧聯想
資料庫原理中有提到在使用者（或應用程式）到資料庫之間，db的資料結構有三層模式，兩層映像。（ 外模式 / 邏輯模式 / 內模式 ）
☺外模式是用於與資料庫系統的介面，是使用者用到的那部分資料的描述。外模式由若干個外部記錄型別組成。
☺邏輯模式是資料庫中全部資料的整體邏輯結構的描述。它由若干個邏輯記錄型別或，還包含記錄間聯絡 資料的完備性安全性等要求。
☺內模式是資料庫在物理儲存方面的描述，定義所有內部記錄型別 / 索引和檔案的組織方式，以及資料控制方面的細節。
模擬可知
☞表示層（ui）：
展現給使用者的介面。
（例如： 顧客看到的選單，體現了這個餐廳可以滿足使用者哪些需求）
☞業務邏輯層（bll）:
對資料層的操作和業務的處理。接受使用者的指令或者資料輸入，提交給應用層做處理，同時負責將業務邏輯層的處理結果顯示給使用者。
（例如： 服務員接受顧客的訂單，並反饋給客戶餐廳是否能夠滿足客戶的訂單要求；將客戶的訂單下達給廚師進行按需烹飪；當菜製作完畢，由服務員將菜端給下單的客戶，並接受客戶的反饋，用餐評價和收錢。）
☞資料層（dal）:
直接操縱資料庫，主要是增刪改查的功能。儲存資料的資料庫伺服器和處理資料和快取資料的元件。元件將大量使用的資料放入系統的快取庫，以提高資料訪問和處理的效率。
（例如：廚師在廚房直接磨刀霍霍向豬羊，對各式各樣的食材進行各種精細的操作。）
優點
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的復用。
缺點：
1、降低了系統的效能。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
【三層】建立乙個簡單的c#三層結構
我眼中的三層
三層架構中的三層分別為 資料儲存層 dal 業務邏輯層 bll 表示層 ui 呼叫關係 ui呼叫 bll，然後返回給ui ui呼叫 bll，bll呼叫 dal，dal返回給 bll，bll返回給ui 具體實現方面 ui層，使用者展現層 bll層，業務邏輯層 idal 資料邏輯層介面 dalfacto...
三層結構解釋
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個中間層，也叫元件層。這裡所 說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也 不僅僅有b s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一 臺機器上。三層體系的應用程式將業務規則 資料訪問 合法性校驗等工...
三層 多層結構
三層 多層結構就像多個人，分別不同負責各自的工作。該知道自己知道的，不該知道自己不知道的。別八卦，別打聽不該自己知道的事。表示層 不應該知道的 不應該看到物理的資料儲存。不應該有connection strings,connections,commands或者類似。應該知道的 應該知道主要模組。業務...