用戶界面表示層(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必須被多次調用才能獲得數據。當子程序模塊程序不返回時,主程序模塊只能處於等待狀態。所以在執行速度上,留言板版本越高,排名越低。“三層結構”開發模式不適合對執行速度要求過於嚴格的系統,如網上訂票、網上股票交易等...它更適合於業務規則容易改變的系統。“三層結構”開發模式,入門難,理解學習難。這是給編程初學者的。在這種模式下開發的軟件通常會有更多的代碼。這往往讓初學者淹沒在浩如煙海的代碼中。對此感到恐懼和厭惡是可以理解的...其實無論哪種開發模式,哪種開發方法,都是有利有弊的。任何問題都不會有“放之四海而皆準”的解決方案。所以“三層結構”這個詞也不會例外!是否采用這種模式進行系統開發,要經過比較權衡之後才能做。避免濫用!