免费99精品国产自在现线观看_人妻少妇精品视频区性色_丝袜 屁股 在线 国产_无码视频在线免费观看

詳解軟件架構模式之分層架構–三層架構,值得收藏(軟件3層架構)

概述

今天的內容主要來自《軟件架構模式》第一章,覺得還不錯,所以分享給大家。


分層架構

分層架構是一種很常見的架構模式,它也叫N層架構。這種架構是大多數(shù)Jave EE應用的實際標準,因此很多的架構師,設計師,還有程序員都知道它。許多傳統(tǒng)IT公司的組織架構和分層模式十分的相似。所以它很自然的成為大多數(shù)應用的架構模式。


模式分析

分層架構模式里的組件被分成幾個平行的層次,每一層都代表了應用的一個功能(展示邏輯或者業(yè)務邏輯)。盡管分層架構沒有規(guī)定自身要分成幾層幾種,大多數(shù)的結構都分成四個層次:展示層,業(yè)務層,持久層,和數(shù)據(jù)庫層。如表1-1,有時候,業(yè)務層和持久層會合并成單獨的一個業(yè)務層,尤其是持久層的邏輯綁定在業(yè)務層的組件當中。因此,有一些小的應用可能只有3層,一些有著更復雜的業(yè)務的大應用可能有5層或者更多的分層。

分層架構中的每一層都著特定的角色和職能。舉個例子,展示層負責處理所有的界面展示以及交互邏輯,業(yè)務層負責處理請求對應的業(yè)務。架構里的層次是具體工作的高度抽象,它們都是為了實現(xiàn)某種特定的業(yè)務請求。比如說展示層并不需要關心怎樣得到用戶數(shù)據(jù),它只需在屏幕上以特定的格式展示信息。業(yè)務層并不關心要展示在屏幕上的用戶數(shù)據(jù)格式,也不關心這些用戶數(shù)據(jù)從哪里來。它只需要從持久層得到數(shù)據(jù),執(zhí)行與數(shù)據(jù)有關的相應業(yè)務邏輯,然后把這些信息傳遞給展示層。

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)

分層架構的一個突出特性是組件間關注點分離 (separation of concerns)。一個層中的組件只會處理本層的邏輯。比如說,展示層的組件只會處理展示邏輯,業(yè)務層中的組件只會去處理業(yè)務邏輯。多虧了組件分離,讓我們更容易構造有效的角色和強力的模型。這樣應用變的更好開發(fā),測試,管理和維護。


關鍵概念

注意表1-2中每一層都是封閉的。這是分層架構中非常重要的特點。這意味request必須一層一層的傳遞。舉個例子,從展示層傳遞來的請求首先會傳遞到業(yè)務層,然后傳遞到持久層,最后才傳遞到數(shù)據(jù)層。

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)

那么為什么不允許展示層直接訪問數(shù)據(jù)層呢。如果只是獲得以及讀取數(shù)據(jù),展示層直接訪問數(shù)據(jù)層,比穿過一層一層來得到數(shù)據(jù)來的快多了。這涉及到一個概念:層隔離。

層隔離就是說架構中的某一層的改變不會影響到其他層:這些變化的影響范圍限于當前層次。如果展示層能夠直接訪問持久層了,假如持久層中的SQL變化了,這對業(yè)務層和展示層都有一定的影響。這只會讓應用變得緊耦合,組件之間互相依賴。這種架構會非常的難以維護。

從另外一個方面來說,分層隔離使得層與層之間都是相互獨立的,架構中的每一層的互相了解都很少。為了說明這個概念的牛逼之處,想象一個超級重構,把展示層從JSP換成JSF。假設展示層和業(yè)務層的之間的聯(lián)系保持一致,業(yè)務層不會受到重構的影響,它和展示層所使用的界面架構完全獨立。

然而封閉的架構層次也有不便之處,有時候也應該開放某一層。如果想往包含了一些由業(yè)務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子里,新建一個服務層通常是一個好主意,因為從架構上來說,它限制了分享服務訪問業(yè)務層(也不允許訪問展示層)。如果沒有隔離層,就沒有任何架構來限制展示層訪問普通服務,難以進行權限管理。

在這個例子中,新的服務層是處于業(yè)務層之下的,展示層不能直接訪問這個服務層中的組件。但是現(xiàn)在業(yè)務層還要通過服務層才能訪問到持久層,這一點也不合理。這是分層架構中的老問題了,解決的辦法是開放某些層。如表1-3所示,服務層現(xiàn)在是開放的了。請求可以繞過這一層,直接訪問這一層下面的層。既然服務層是開放的,業(yè)務層可以繞過服務層,直接訪問數(shù)據(jù)持久層。這樣就非常合理。

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)

開放和封閉層的概念確定了架構層和請求流之間的關系,并且給設計師和開發(fā)人員提供了必要的信息理解架構里各種層之間的訪問限制。如果隨意的開放或者封閉架構里的層,整個項目可能都是緊耦合,一團糟的。以后也難以測試,維護和部署。


實例

為了演示分層架構是如何工作的,想象一個場景,如表1-4,用戶發(fā)出了一個請求要獲得客戶的信息。黑色的箭頭是從數(shù)據(jù)庫中獲得用戶數(shù)據(jù)的請求流,紅色箭頭顯示用戶數(shù)據(jù)的返回流的方向。在這個例子中,用戶信息由客戶數(shù)據(jù)和訂單數(shù)組組成(客戶下的訂單)。

用戶界面只管接受請求以及顯示客戶信息。它不管怎么得到數(shù)據(jù)的,或者說得到這些數(shù)據(jù)要用到哪些數(shù)據(jù)表。如果用戶界面接到了一個查詢客戶信息的請求,它就會轉發(fā)這個請求給用戶委托(Customer Delegate)模塊。這個模塊能找到業(yè)務層里對應的模塊處理對應數(shù)據(jù)(約束關系)。業(yè)務層里的customer object聚合了業(yè)務請求需要的所有信息(在這個例子里獲取客戶信息)。這個模塊調用持久層中的 customer dao 來得到客戶信息,調用order dao來得到訂單信息。這些模塊會執(zhí)行SQL語句,然后返回相應的數(shù)據(jù)給業(yè)務層。當 customer object收到數(shù)據(jù)以后,它就會聚合這些數(shù)據(jù)然后傳遞給 customer delegate,然后傳遞這些數(shù)據(jù)到customer screen 展示在用戶面前。

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)

從技術的角度來說,有很多的方式能夠實現(xiàn)這些模塊。比如說在Java平臺中,customer screen 對應的是 (JSF) Java Server Faces ,用 bean 組件來實現(xiàn) customer delegate。用本地的Spring bean或者遠程的EJB3 bean 來實現(xiàn)業(yè)務層中的customer object。上例中的數(shù)據(jù)訪問可以用簡單的POJP’s(Plain Old Java Objects),或者可以用MyBatis,還可以用JDBC或者Hibernate 查詢。Microsoft平臺上,customer screen能用 .NET 庫的ASP模塊來訪問業(yè)務層中的C#模塊,用ADO來實現(xiàn)用戶和訂單數(shù)據(jù)的訪問模塊。


軟件架構設計之分層架構(三層架構)

在軟件體系架構設計中,分層式結構是最常見,也是最重要的一種結構。微軟推薦的分層式結構一般分為三層,從下至上分別為:數(shù)據(jù)訪問層、業(yè)務邏輯層(又或稱為領域層)、表示層。

各層的作用:

1:數(shù)據(jù)訪問層:主要是對非原始數(shù)據(jù)(數(shù)據(jù)庫或者文本文件等存放數(shù)據(jù)的形式)的操作層,而不是指原始數(shù)據(jù),也就是說,是對數(shù)據(jù)庫的操作,而不是數(shù)據(jù),具體為業(yè)務邏輯層或表示層提供數(shù)據(jù)服務.

2:業(yè)務邏輯層:主要是針對具體的問題的操作,也可以理解成對數(shù)據(jù)層的操作,對數(shù)據(jù)業(yè)務邏輯處理,如果說數(shù)據(jù)層是積木,那邏輯層就是對這些積木的搭建。

3:界面層:主要表示W(wǎng)EB方式,也可以表示成WINFORM方式,WEB方式也可以表現(xiàn)成:aspx,如果邏輯層相當強大和完善,無論表現(xiàn)層如何定義和更改,邏輯層都能完善地提供服務。

區(qū)分方法:

1:數(shù)據(jù)訪問層:主要看數(shù)據(jù)層里面有沒有包含邏輯處理,實際上它的各個函數(shù)主要完成各個對數(shù)據(jù)文件的操作。而不必管其他操作。

2:業(yè)務邏輯層:主要負責對數(shù)據(jù)層的操作。也就是說把一些數(shù)據(jù)層的操作進行組合。

3:界面層:主要對用戶的請求接受,以及數(shù)據(jù)的返回,為客戶端提供應用程序的訪問。

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)


總結

分層架構是一個很可靠的架構模式。它適合大多數(shù)的應用。如果你不確定在項目中使用什么架構,分層架構是可以先用著的。不過從架構的角度上來說,選擇這個模式還要考慮很多的東西(如污水池反模式)。后面會分享更多devops和DBA方面的內容,感興趣的朋友可以關注一下~

詳解軟件架構模式之分層架構--三層架構,值得收藏(軟件3層架構)

相關新聞

聯(lián)系我們
聯(lián)系我們
在線咨詢
分享本頁
返回頂部