各層的作用
數據數據訪問層:主要是對原始數據（數據庫或者文本文件等存放數據的形式）的操作層 而不是指原始數據 也就是說 是對數據的操作 而不是數據庫 具體為業務邏輯層或表示層提供數據服務．
業務邏輯層:主要是針對具體的問題的操作 也可以理解成對數據層的操作 對數據業務邏輯處理 如果說數據層是積木 那邏輯層就是對這些積木的搭建
表示層:主要表示WEB方式 也可以表示成WINFORM方式 WEB方式也可以表現成:aspx 如果邏輯層相當強大和完善 無論表現層如何定義和更改 邏輯層都能完善地提供服務
具體的區分方法
數據數據訪問層:主要看妳的數據層裏面有沒有包含邏輯處理 實際上他的各個函數主要完成各個對數據文件的操作 而不必管其他操作
業務邏輯層:主要負責對數據層的操作 也就是說把壹些數據層的操作進行組合
表示層:主要對用戶的請求接受 以及數據的返回 為客戶端提供應用程序的訪問
三層結構解釋
所謂三層體系結構 是在客戶端與數據庫之間加入了壹個中間層 也叫組件層 這裏所說的三層體系 不是指物理上的三層 不是簡單地放置三臺機器就是三層體系結構 也不僅僅有B/S應用才是三層體系結構 三層是指邏輯上的三層 即使這三個層放置到壹臺機器上 三層體系的應用程序將業務規則 數據訪問 合法性校驗等工作放到了中間層進行處理 通常情況下 客戶端不直接與數據庫進行交互 而是通過/D通訊與中間層建立連接 再經由中間層與數據庫進行交換
開發人員可以將應用的商業邏輯放在中間層應用服務器上 把應用的業務邏輯與用戶界面分開 在保證客戶端功能的前提下 為用戶提供壹個簡潔的界面 這意味著如果需要修改應用程序代碼 只需要對中間層應用服務器進行修改 而不用修改成千上萬的客戶端應用程序 從而使開發人員可以專註於應用系統核心業務邏輯的分析 設計和開發 簡化了應用系統的開發 更新和升級工作
那麽為什麽要應用 中間業務層 呢？舉些例子:
我們假設有壹段登錄代碼 則可以這樣處理Web程序 外觀層負責接收前臺頁面的數據 然後傳給中間層 中間層對數據進行處理 比如格式化 防SQL註入等等壹些 這樣的數據再傳給數據訪問層然後與數據庫進行操作 比如與數據庫的用戶名和密碼匹配等等壹些代碼
中間業務層 的用途有很多 例如 驗證用戶輸入數據 緩存從數據庫中讀取的數據等等……但是 中間業務層 的實際目的是將 數據訪問層 的最基礎的存儲邏輯組合起來 形成壹種業務規則 例如 在壹個購物網站中有這樣的壹個規則 在該網站第壹次購物的用戶 系統為其自動註冊 這樣的業務邏輯放在中間層最合適
在 數據訪問層 中 最好不要出現任何 業務邏輯 ！也就是說 要保證 數據訪問層 的中的函數功能的原子性！即最小性和不可再分 數據訪問層 只管負責存儲或讀取數據就可以了
完善的三層結構的要求是:修改表現層而不用修改邏輯層 修改邏輯層而不用修改數據層 否則妳的應用是不是多層結構 或者說是層結構的劃分和組織上是不是有問題就很難說 不同的應用有不同的理解 這只是壹個概念的問題． 理解ASP NET中的三層結構——為什麽要分三層？
我們用三層結構主要是使項目結構更清楚 分工更明確 有利於後期的維護和升級 它未必會提升性能 因為當子程序模塊未執行結束時 主程序模塊只能處於等待狀態 這說明將應用程序劃分層次 會帶來其執行速度上的壹些損失 但從團隊開發效率角度上來講卻可以感受到大不相同的效果
需要說明壹下 三層結構不是 NET的專利 也不是專門用在數據庫上的技術 它是壹種更加普適的架構設計理念
個人感覺
個人感覺此種架構要在數據庫設計上註意表之間的關系 盡力滿足主與子的關系 在功能上對用戶要有壹定的限制 不要表現在對於子表的刪除操作壹定要慎重 以免造成主表與子表的數據在邏輯上出現的主表的外鍵在子表中沒有相對應的值
對於表的綜合查詢方法是
先對主表查詢 調用主表所對應的DL 再根據主表的記錄分別對每壹個子表進行查詢 將自表的查詢結果添加的主表後 形成壹個大的查詢集合
對於表的操作（增刪改）
此時只對主表進行操作 調用主表對應的DL中的操作方法 RL層是邏輯判斷層 主要是對頁面上傳入的數據進行邏輯判斷 RL層之上就是UI
如何建立壹個三層體系結構解決方案
新建壹個空白解決方案 然後
添加 － 新建項目 － 其他項目 － 企業級模版項目 － C#生成塊 － 數據訪問 （數據層 下簡稱D層） 添加 － 新建項目 － 其他項目 － 企業級模版項目 － C#生成塊 － 業務規則 （業務層 下簡稱C層） 添加 － 新建項目 － 其他項目 － 企業級模版項目 － C#生成塊 － Web用戶界面 （界面層 下簡稱U層） 右鍵點 解決方案 － 項目依賴項 設置U依賴於D C C依賴於D
對U添加引用D C 對C添加引用D
lishixinzhi/Article/program/net/201311/15434