三層架構
“高內聚,低耦合”的思想
三層架構就是為了符合“高內聚,低耦合”思想,把各個功能模塊劃分為表示層(UI)、業務邏輯層(BLL)和數據訪問層(DAL)三層架構,各層之間採用介面相互訪問,並通過對象模型的實體類(Model)作為數據傳遞的載體,不同的對象模型的實體類一般對應於資料庫的不同表,實體類的屬性與資料庫表的欄位名一致。
三層架構區分層次的目的是為了 “高內聚,低耦合”。開發人員分工更明確,將精力更專註於應用系統核心業務邏輯的分析、設計和開發,加快項目的進度,提高了開發效率,有利於項目的更新和維護工作。
三層架構
數據訪問層:數據訪問層在作業過程中訪問數據系統中的文件,實現對資料庫中數據的讀取保存操作。
表示層:主要功能是顯示數據和接受傳輸用戶的數據,可以在為網站的系統運行提供互動式操作界面,表示層的應用方式比較常見,例如Windows窗體和Web頁面。
業務邏輯層:將用戶的輸入信息進行甄別處理,分別保存。建立新的數據存儲方式,在存儲過程中對數據進行讀取,將“商業邏輯”描述代碼進行包含。
三層架構軟體系統為用戶的數據傳輸、提取、儲存創造了便利條件。在應用數據時,信息劃分架構開發項目,對各層次之間的工作職責進行清晰規劃,這樣就降低了網站系統的維護風險。
三層架構主要是指將業務應用規劃中的表示層 UI、數據訪問層 DAL 以及業務邏輯層 BLL,其分層的核心任務是“高內聚低耦合”的實現。在整個軟體架構中,分層結構是常見和普通的軟體結構框架,同時也具有非常重要的地位和意義。這種三層架構可以在軟體開發的過程中,劃分技術人員和開發人員的具體開發工作,重視核心業務系統的分析、設計以及開發,提高信息系統開發質量和開發效率,進而為信息系統日後的更新與維護提供很大的方便。
怎麼樣分層符合三層架構原則呢?主要有以下三種分層方式:
1、數據層不包含任何代碼,只有資料庫,還有相關的存儲過程。這種模式下,數據層看起來就變得很簡單了。只包含所建立的資料庫和一些存儲過程(注意是存儲過程)。其實這些存儲過程的建立也是相當複雜的,因為它們可以完成除數據訪問外的其他一些很強大的功能,如分頁、實現搜索演演算法等。數據訪問的邏輯就都放在業務層,當然業務層還包含其他一些邏輯代碼。我們來看一個示例,假設資料庫里有一個表 BOOKS(書),建立一個存儲過程 GetAllBooks,用來讀取書的信息,這樣在業務層里編一個方法 GetBookS()和一個公用資料庫訪問類,GetBooks()就通過資料庫訪問類打開連接,執行在存儲過程,返回數據 (返回類型可以是 DataT - able,DataSet,DataReader 或 者 實 體 類)。業務層單獨編譯成一個或者幾個 DLL 文件。接著就是表示層了,表示層通過調用GetBookS()返回數據綁定在相關的控制項里。業務層的方法都是在表示層調用。一般來說 book.aspx 和 book.aspx.cs 都是表示層的內容,所有前台的設計、相關控制項、數據緩存都是屬於表示層。
2、數據層還包含所有公共數據訪問代碼。這種模式和前一種差別不大,主要是把數據訪問代碼留到數據層。這樣可以很方便地實現對多資料庫的支持。業務邏輯層直接調用數據層的相關訪問數據的代碼,完全不必了解底層是什麼資料庫。其他和前一種沒什麼分別。
3、所有數據讀取都放在數據層。這種模式下像前面所述的 GetBooks()方法都是放在數據層,在業務層再定義一個GetBookS()方法以供表示層調用。這種模式下業務層不但不必了解底層是什麼資料庫,而且連資料庫的結構都不必了解了,這是最標準的三層架構了,在 Microsoft 的 PetShop 4.0 里就是這種模式。
3個層次中,系統主要功能和業務邏輯都在業務邏輯層進行處理。
所謂三層體系結構,是在客戶端與資料庫之間加入了一個“中間層”,也叫組件層。這裡所說的三層體系,不是指物理上的三層,不是簡單地放置三台機器就是三層體系結構,也不僅僅有B/S應用才是三層體系結構,三層是指邏輯上的三層,即把這三個層放置到一台機器上。
三層體系的應用程序將業務規則、數據訪問、合法性校驗等工作放到了中間層進行處理。通常情況下,客戶端不直接與資料庫進行交互,而是通過COM/DCOM通訊與中間層建立連接,再經由中間層與資料庫進行交互。
三層架構中主要功能與業務邏輯一般要在業務邏輯層進行信息處理和實現,其中三層體系架構中的客戶端和資料庫要預設中間層,成為組建層。三層架構中的三層具有一定的邏輯性,即是將三層設置到同一個計算機系統中,把業務協議、合法校驗以及數據訪問等程序歸置到中間層進行信息處理,一般客戶端無法和資料庫進行數據傳輸,主要是利用COM/DCOM通訊和中間層構建銜接通道,實現中間層與資料庫的數據傳輸,進而實現客戶端與是資料庫的交互。
表示層又稱表現層UI,位於三層構架的最上層,與用戶直接接觸,主要是B/S信息系統中的Wed瀏覽頁面。作為Wed瀏覽頁面,表示層的主要功能是實現系統數據的傳入與輸出,在此過程中不需要藉助邏輯判斷操作就可以將數據傳送到BBL系統中進行數據處理,處理後會將處理結果反饋到表示層中。換句話說,表示層就是實現用戶界面功能,將用戶的需求傳達和反饋,並用BLL或者是Models進行調試,保證用戶體驗。
業務邏輯層BLL的功能是對具體問題進行邏輯判斷與執行操作,接收到表現層UI的用戶指令后,會連接數據訪問層DAL,訪問層在三層構架中位於表示層與數據層中間位置,同時也是表示層與數據層的橋樑,實現三層之間的數據連接和指令傳達,可以對接收數據進行邏輯處理,實現數據的修改、獲取、刪除等功能,並將處理結果反饋到表示層UI中,實現軟體功能。
數據訪問層DAL是資料庫的主要操控系統,實現數據的增加、刪除、修改、查詢等操作,並將操作結果反饋到業務邏輯層BBL。在實際運行的過程中,數據訪問層沒有邏輯判斷能力,為了實現代碼編寫的嚴謹性,提高代碼閱讀程度,一般軟體開發人員會在該層中編寫DataAccessCommon,保證數據訪問層DAL數據處理功能。
實體類庫是資料庫表的映射對象,在信息系統軟體實際開發的過程中,要建立對象實例,將關係資料庫表採用對象實體化的方式表現出來,輔助軟體開發中對各個系統功能的控制與操作執行,並利用 GET 與 SET 把資料庫表中的所有欄位映射為系統對象,建立實體類庫,進而實現各個結構層的參數傳輸,提高代碼的閱讀性。從本質上看,實體類庫主要服務於表示層、業務邏輯層以及數據訪問層,在三層之間進行數據參數傳輸,強化數據表示的簡約性。
三層架構的體系結構:表示層和業務邏輯層之間用對象模型的實體類對象來傳遞數據,業務邏輯層和數據訪問層之間用對象模型的實體類對象來傳遞數據,數據訪問層通過.NET 提供的 ADO.NET 組件來操作資料庫,或者利用 SQLServer 資料庫伺服器的存儲過程來完成數據操作。
1、數據訪問層:主要是對非原始數據(資料庫或者文本文件等存放數據的形式)的操作層,而不是指原始數據,也就是說,是對資料庫的操作,而不是數據,具體為業務邏輯層或表示層提供數據服務。
2、業務邏輯層:主要是針對具體的問題的操作,也可以理解成對數據層的操作,對數據業務邏輯處理,如果說數據層是積木,那邏輯層就是對這些積木的搭建。
3、界面層:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表現成:aspx,如果邏輯層相當強大和完善,無論表現層如何定義和更改,邏輯層都能完善地提供服務。
三層結構並不是普通的DAL,BLL,WebUI三個模塊,三層程序有一些需要約定遵守的規則
1、最核心的模塊規則,表現層只是外殼作用,不能包含任何BizLogic的處理過程。
2、各層次模塊設計時應該從業務邏輯層出發,而不是開始於表現層.。業務邏輯層在API上應該實現所有BizLogic,以面向對象的方式。
3、不論數據層是一個簡單的SqlHelper,還是帶有Mapping的Classes,應該保證其與抽象的系統層無關。
4、不管使用COM+(EnterpriseService),還是Remoting,還是WebService之類的遠程對象技術,不管部署是否在伺服器上,在起碼在設計時必須要考慮多台伺服器通過負載均衡作集群。
綜上,考慮一個項目是否符合應用三層或多層設計時,必須要考慮是否真正符合項目的需求。
1、開發人員可以只關注整個結構中的其中某一層;
2、可以很容易的用新的實現來替換原有層次的實現;
3、可以降低層與層之間的依賴;
4、有利於標準化;
5、利於各層邏輯的復用;
6、結構更加的明確;
7、在後期維護的時候,極大地降低了維護成本和維護時間;
8、避免了表示層直接訪問數據訪問層,表示層只和業務邏輯層有聯繫,提高了數據安全性;
9、有利於系統的分散開發,每一個層可以由不同的人員來開發,只要遵循介面標準,利用相同的對象模型實體類就可以了,這樣就可以大大提高系統的開發速度;
10、方便系統的移植,如果要把一個C/S的系統變成B/S系統,只要修改三層架構的表示層就可以了。業務邏輯層和數據訪問層幾乎不用修改就可以輕鬆的把系統移植到網路上;
11、項目結構更清楚,分工更明確,有利於後期的維護和升級。
1、降低了系統的性能。這是不言而喻的。如果不採用分層式結構,很多業務可以直接造訪資料庫,以此獲取相應的數據,如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能,為保證其設計符合分層式結構,可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼。
3、增加了開發成本。
(1)應用伺服器
伺服器一般包括有連接與無連接形式,無連接在最底層要設置UDP/IP協議實現伺服器通信功能,同時在實際使用的過程中,由於客戶機無法保證可靠的傳輸渠道,使得客戶機向伺服器提交請求時,很容易造成請求的丟失、延遲以及傳遞失序等傳輸問題,進而降低通信質量。UDP的可靠性很低,在實際運行中UDP要依託於下層IP網路進行交付分組,無法引入檢驗程序,而IP網路還要由實際硬體網路或者是相關網關決定其工作質量。因此,從這一層面上看,下層網路的好壞直接關係到UDP工作。在進行開發有連接伺服器的過程中,要利用TCP/IP通信協議,利用網際網路創建良好的通信環境,進而提高通信數據的真實性和可靠性。TCP/IP通信協議可以對數據信息進行驗證與校對,保證數據信息的完整性。同時在實際運行中,可以通過數據的序列號排序保證數據信息的有序到達,防止出現信息重複分組的情況。另外,這種通信協議可以對流量進行有效控制,確保發送信息速度在接收方的承受範圍以內,通過INTERNET,實現伺服器的面向連接。
(2)應用客戶端
在三層構架系統中,客戶端是使用者的主要功能體驗區域,相比於伺服器而言非常簡單。一方面,在三層構架運行的過程中,客戶機軟體要和各個伺服器進行相互通信,不需要過於重視併發性處理。另一方面,一般客戶機軟體可以仿照常規程序進行指令執行,不需要進行外加保護,依託於操作系統進行強迫性保護。但與此同時對界面具有極高的要求,系統分析的過程中就要進行專門的界面設計,同時要和客戶進行及時溝通,掌握客戶的實際需求,實現高效的信息反饋與交流溝通,進而保證信息系統軟體界面設計的質量和效率。
(3)數據伺服器
在進行數據伺服器選擇的過程中,要根據信息系統平台要求和用戶期望要求,同時對應各個伺服器的特點進行使用與選擇。一般情況下出於對系統性能的考慮,會選擇SQLSERVER數據伺服器,設計階段中要通過Proactive等有效措施對系統資料庫的實際使用性能進行不斷地優化與完善。同時管理人員要和程序設計人員進行有效的溝通與協作,明確信息系統軟體的性能目標,設置性能期望值,構建系統資源組合體系,滿足用戶的實際需求。
(4)資料庫和應用伺服器的連接
在基於三層構架的信息系統開發中,應用伺服器要利用SQL語言進行連接資料庫伺服器,其連接方法包括DB-Library、DAO以及OLE等方式,其中DB-Library是最為常見的連接方式,作為SQLSERVER的重要介面層,具有極強的訪問信息效率和訪問速度。這主要是源於DB-Library的語言開發能力,直接省去DAO以及OLE等連接方式中抽象層的調用,節省了信息訪問時間。同時,三層構架適用於使用諸多開發語言的信息系統開發,不是.NET的專利,也不是專門用在資料庫上的技術,而是一種更加普適的架構設計理念,除了數據、邏輯、界面等層次之外,在實際應用中還會根據需要多出傳遞數據的層、介面層等等。在結合DB-Library資料庫連接后,設置NTWDBLIB.LIB組建,構建CDBConn實體類庫體系,實現資料庫與應用伺服器的連接。因此,信息系統軟體架構可以為系統開發創造出良好的分散式計算環境,其中邏輯層可以實現多個機器的同時運行,通過計算機網路計算能力,強化系統各個功能板塊的精準性和復用性,進而有效減少了信息系統軟體開發的時間和周期,保證信息系統的安全性與拓展性,實現系統功能的最大化實現。