三層結構的認識

三層結構的認識

這幾天我在看三層的有關資料，對其有了一點的初步認識，現在對這一點點的認識做一下總結。

一、三層的劃分方式：物理上和邏輯上

所謂的兩層或是三層結構，它又分為物理上的劃分和邏輯上的劃分。

物理上的劃分，可以理解為硬體上的劃分，因為我們設計的程式架構都是跑在計算機上的，無論是跑在客戶機上、伺服器上或者是終端機上的，終究它是跑在硬體上的。

在三層之前就有兩層結構或者是單層結構。

1）下面的圖1 是一張典型的cs「客戶機」端和「伺服器」端的兩層物理結構圖。

「客戶機」端有使用者介面和應用邏輯，「伺服器」端就是資料庫伺服器。

客戶機是pc機或是智慧型機，

2）下面我們再看一下三層的物理結構圖

物理上的三層：顯示層/業務層/資料層

顯示層，是pc機

業務層，是應用伺服器。

資料層，資料庫伺服器。

◆ 

邏輯上的三層：ui/bll+dal/db

在這裡我們主要討論的三層是指邏輯的三層，是在資料庫之上討論的三層：ui、bll、dal。

二、三層的應用場景

我們為什麼要使用三層架構？

什麼情況下不使用三層架構？

首先要清楚一點，並不是所有的系統都需要使用三層架構的。

第一，業務邏輯簡單；第二，沒有真正的資料儲存層，所以也就不需要資料訪問層，這是就不需要使用三層架構。

只有業務邏輯複雜，既有資料訪問層，又有業務邏輯層（bll層），才需要使用三層架構的。

三、三層的結構

（1）資料訪問層（dal）

◆  dal的作用

從資料來源載入資料（select）

向資料來源寫入資料（insert/update）

從資料來源刪除資料（delete）

◆ dal中常用的技術

ado.net+sql語句

訪問sql sever資料庫時linq to sql（它是單錶對映）

所以說，dal的職責：是與資料來源打交道，讀資料、寫資料、刪資料.

（2）顯示層（ui層）◆ ui的作用

向使用者展現特定業務資料

採集使用者的輸入資訊和操作

◆ ui設計的原則

使用者至上，兼顧簡潔

◆中的常用技術

windowsform：form 、control

asp.net：aspx 、ascx 、master 、html

（3）業務邏輯層（bll）

◆ bll的作用

從dal中獲取資料，以供ui層顯示用

從ui中獲取使用者指令和資料，執行業務邏輯

從ui中獲取使用者指令和資料，通過dal寫入資料來源。

◆ bll的職責機制

ui→bll→ui

ui→bll→dal→bll→ui

總結:三層的關係

dal只提供基本的資料訪問，不包含任何業務相關的邏輯處理。

ui只負責顯示和採集使用者操作，不包含任何的業務相關的邏輯處理。

dal/bll/ui分別在不同的程式集中

各個層之間的引用關係

ui→bll→dal

dal所在程式集不引用bll和ui

bll需要引用dal

ui直接引用bll，可能會間接引用dal。

三層 我眼中的三層結構

從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...

三層結構解釋

所謂三層體系結構，是在客戶端與資料庫之間加入了乙個中間層，也叫元件層。這裡所 說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也 不僅僅有b s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一 臺機器上。三層體系的應用程式將業務規則 資料訪問 合法性校驗等工...

三層 多層結構

三層 多層結構就像多個人，分別不同負責各自的工作。該知道自己知道的，不該知道自己不知道的。別八卦，別打聽不該自己知道的事。表示層 不應該知道的 不應該看到物理的資料儲存。不應該有connection strings,connections,commands或者類似。應該知道的 應該知道主要模組。業務...