用戶界面表示層(USL)、業務邏輯層(BLL)和數據訪問層(DAL)
BLL將USL從DAL中分離出來，增加了業務規則1的各層功能:數據數據訪問層:主要是原始數據(以數據庫或文本文件等存儲數據的形式)的操作層，而不是原始數據，即它是數據的操作，而不是數據庫，具體為業務邏輯層或表示層提供數據服務。
2.業務邏輯層:主要針對具體問題的操作，也可以理解為數據層的操作和數據業務的邏輯處理。如果數據層是壹個積木，那麽邏輯層就是這些積木的構造。
3.表示層:主要表示WEB模式，也可以表示為WINFORM模式，WEB模式也可以表示為:aspx。如果邏輯層相當強大和完善，那麽無論表示層如何定義和改變，邏輯層都可以完美地提供服務。特定區分方法
1:數據訪問層:主要看妳的數據層是否包含邏輯處理。其實它的功能主要是完成對數據文件的各種操作。不考慮其他操作。
2.業務邏輯層:主要負責數據層的操作。也就是說，合並了壹些數據層的操作。
3.表示層:主要用於用戶的請求接受，以及數據的返回，為客戶端提供對應用程序的訪問。三層結構解釋
所謂的三層架構在客戶端和數據庫之間增加了壹個中間層，也稱為組件層。這裏說的三層體系，不是指物理上的三層，或者簡單的放三臺機器或者壹個三層架構，也不是只有B/S應用才是三層架構，三層指的是邏輯上的三層，即使這三層放在壹臺機器上。三層應用將業務規則、數據訪問、合法性驗證等工作放在中間層進行處理。通常情況下，客戶端不直接與數據庫交互，而是通過COM/DCOM通信與中間層建立連接，然後通過中間層與數據庫進行交換。
開發人員可以將應用程序的業務邏輯放在中間層應用服務器上，並將應用程序的業務邏輯與用戶界面分離開來。在保證客戶端功能的前提下，為用戶提供壹個簡單的界面。這意味著，如果需要修改應用程序代碼，只需要修改中間層應用服務器，而不是修改成千上萬的客戶端應用程序。使得開發人員可以集中精力分析、設計和開發應用系統的核心業務邏輯，簡化了應用系統的開發、更新和升級。那麽為什麽要應用“中間業務層”呢？舉幾個例子:
假設有壹個登錄代碼，我們可以這樣處理Web程序。外觀層負責接收前臺頁面的數據，然後傳遞給中間層，中間層對數據進行處理，比如格式化、防止SQL註入等等。這樣的數據再傳到數據訪問層，然後和數據庫進行操作，比如匹配數據庫的用戶名和密碼等等。
“中間業務層”有很多用途，比如驗證用戶輸入的數據，緩存從數據庫讀取的數據等...但“中間業務層”的實際目的是結合“數據訪問層”最基本的存儲邏輯，形成壹個業務規則。比如“某購物網站有個規定，首次在該網站購物的用戶會被系統自動註冊”。這種業務邏輯最好放在中間層:在“數據訪問層”，最好不要有任何“業務邏輯”！換句話說，我們必須保證“數據訪問層”中函數的原子性！也就是極簡主義和不可分性。“數據訪問層”只負責存儲或讀取數據。
ASP.NET的三層結構描述
壹個完善的三層結構的要求是:修改表示層不修改邏輯層，修改邏輯層不修改數據層。否則，很難說妳的應用程序是多層結構，還是層結構的劃分和組織有問題。不同的應用有不同的理解，這只是壹個概念上的問題。了解ASP中的三層結構。NET-為什麽要分三層？
我們采用三層結構主要是為了讓項目結構更清晰，分工更明確，有利於後期的維護和升級。可能不會提高性能，因為主程序模塊只能在子程序模塊不執行時處於等待狀態。由此可見，將應用程序分層會給其執行速度帶來壹些損失。但是從團隊開發效率的角度，我們可以感受到截然不同的效果。
需要註意的是，三層結構並不是的專利。NET，也不是專門用於數據庫的技術。它是壹個更通用的建築設計概念。
這種架構在數據庫設計中要註意表與表之間的關系，盡量滿足主從關系。對用戶的功能應該有壹些限制，不應該體現在刪除子表的謹慎上，以免造成主表和子表的數據出現邏輯錯誤，主表的外鍵在子表中沒有對應的值。該表的綜合查詢方法是:
首先查詢主表，調用主表對應的DL。然後根據主表的記錄查詢各個子表。將表中的查詢結果添加到主表後，就形成了壹個大型查詢集。
對於表格操作(增加、刪除和修改):
此時只操作主表，調用主表對應的DL中的操作方法。
RL層是邏輯判斷層，主要判斷頁面上傳的數據。RL層之上是UI如何構建三層架構解決方案。
創建新的空白解決方案。然後:
添加-新建項目-其他項目-企業模板項目-C #構建塊-數據訪問(數據層，以下簡稱D層)
添加-新建項目-其他項目-企業模板項目-C #構建塊-業務規則(業務層，以下簡稱C層)
添加-新建項目-其他項目-企業模板項目-C #構建塊-Web用戶界面(界面層，以下簡稱U層)。
右鍵單擊解決方案-項目依賴項，將U設置為依賴D，C和C設置為依賴D。
將引用d和c添加到u，將引用d添加到c。
到目前為止，已經搭起了壹個三層的架子。我上面說的很具體，也很“蠢”。知道的人都覺得我在胡說八道。其實我有壹種強烈的感覺，很多人其實根本不懂這個簡單的過程。雖然不反對構建兩個“空項目”和1個同樣可以作為三層框架的“Asp net Web應用項目”，但有相當壹部分人認為這些“企業級模板項目”其實是空項目，這是壹種誤解。是的，企業模板項目在解決方案資源管理器中什麽也不是，但是您可以用記事本打開項目文件。看出區別了嗎？有些事情已經過去了，但是系統已經準備好了。也就是說，如果妳在C層的壹個類中“使用系統數據sqlclinic”，或者使用SqlConnection對象，編譯時不會出錯，但是會在“任務列表”中生成壹些“策略警告”，警告妳不要把應該放在D層的東西放在C層(雖然就程序而言確實如此，但是可讀性和可維護性打折扣)，這個功能是壹個空項目無法實現的。在新的Trace Word 3中，應用了“企業模板項目”。把原來的LWordTask.cs放到單個項目中，項目名為AccessTask。在解決方案中創建了壹個名為InterService的新項目，該項目包含壹個程序文件LWordService.cs，該文件是“中間業務層”程序。為了不被重復命名，Trace Word 3的網站放在了WebUI項目中。更完整的代碼可以在代碼包/trace word 3目錄下找到——對象與現實的結合。
我們知道造橋需要磚，所以在造橋之前就要準備好磚，但是為了說明的有序性、壹致性和簡潔性。我們先建橋，磚需要在建造的過程中再生產，這樣就不會再有“橋不需要的東西”。註意，在實際操作中，首先要準備好磚塊。
u層其實是壹座橋，C層是壹塊磚，D層是壹種原材料(石頭、沙子)。這也解釋了為什麽U層要參考和依賴D層(而不是U-to-C和C-to-D層)，因為橋不僅需要磚，還需要石頭和沙子。“三層結構”的缺點有網友在看了本文的前作後向我提出了壹些問題，這讓我想起文章至今沒有提到“三層結構”的缺點。“三層結構”這個詞似乎壹直都很流行，原因可能就是這種開發模式被廣泛使用。但“三層結構”並不是百靈的靈丹妙藥，也有不足之處。先說它的缺點...“三層結構”開發模式壹個非常明顯的缺點就是執行速度不夠快。當然，這個“執行速度”是相對於非分層應用而言的。從本文給出的時序圖來看，這個缺點也暴露得很明顯。TraceLWord1和TraceLWord2不分層，直接調用ADO.NET提供的類獲取數據。但是，跟蹤字6必須被多次調用才能獲得數據。當子程序模塊程序不返回時，主程序模塊只能處於等待狀態。所以在執行速度上，留言板版本越高，排名越低。“三層結構”開發模式不適合對執行速度要求過於嚴格的系統，如網上訂票、網上股票交易等...它更適合於業務規則容易改變的系統。“三層結構”開發模式，入門難，理解學習難。這是給編程初學者的。在這種模式下開發的軟件通常會有更多的代碼。這往往讓初學者淹沒在浩如煙海的代碼中。對此感到恐懼和厭惡是可以理解的...其實無論哪種開發模式，哪種開發方法，都是有利有弊的。任何問題都不會有“放之四海而皆準”的解決方案。所以“三層結構”這個詞也不會例外！是否采用這種模式進行系統開發，要經過比較權衡之後才能做。避免濫用！