個(gè)人總結(jié)，僅供參考，歡迎加好友一起討論

架構(gòu) - 層次式架構(gòu)設(shè)計(jì)理論與實(shí)踐

考點(diǎn)摘要

• 層次式體系結(jié)構(gòu)概述（★）

第二版架構(gòu)新教材里新增加內(nèi)容，對(duì)應(yīng)第13章，新增的內(nèi)容是有關(guān)層次架構(gòu)的總結(jié)性知識(shí)，偏理論多，案例題中有內(nèi)容涉及。

層次式體系結(jié)構(gòu)概述

層次式體系結(jié)構(gòu)設(shè)計(jì)是將系統(tǒng)組成一個(gè)層次結(jié)構(gòu)，每一層為上層服務(wù)，并作為下層客戶。 在一些層次系統(tǒng)中，除了一些精心挑選的輸出函數(shù)外，內(nèi)部的層接口只對(duì)相鄰的層可見。連接件通過決定層間如何交互的協(xié)議來定義，拓?fù)浼s束包括對(duì)相鄰層間交互的約束。由于每一層最多只影響兩層，同時(shí)只要給相鄰層提供相同的接口，允許每層用不同的方法實(shí)現(xiàn)，同樣為軟件重用提供了強(qiáng)大的支持。

分層架構(gòu)的一個(gè)特性就是關(guān)注分離（separation of concerns）。 該層中的組件只負(fù)責(zé)本層的邏輯，組件的劃分很容易明確組件的角色和職責(zé)，也比較容易開發(fā)、測(cè)試、管理和維護(hù)。

層次式體系結(jié)構(gòu)是一個(gè)可靠的通用的架構(gòu)，對(duì)很多應(yīng)用來說，如果不確定哪種架構(gòu)適合，可以用它作為一個(gè)初始架構(gòu)。但是，設(shè)計(jì)時(shí)要注意以下兩點(diǎn)：

1. 要注意的是污水池反模式。

   污水池反模式（architecture sinkhole anti-pattern），就是請(qǐng)求流簡(jiǎn)單地穿過幾個(gè)層，每層里面基本沒有做任何業(yè)務(wù)邏輯，或者做了很少的業(yè)務(wù)邏輯。比如一些JavaEE例子，業(yè)務(wù)邏輯層只是簡(jiǎn)單的調(diào)用了持久層的接口，本身沒有什么業(yè)務(wù)邏輯。

2. 需要考慮的是分層架構(gòu)可能會(huì)讓你的應(yīng)用變得龐大。

   即使你的表現(xiàn)層和中間層可以獨(dú)立發(fā)布，但它的確會(huì)帶來一些潛在的問題，比如：分布模式復(fù)雜、健壯性下降、可靠性和性能的不足，以及代碼規(guī)模的膨脹等。

表現(xiàn)層框架設(shè)計(jì)

MVC模式

MVC強(qiáng)制性地把一個(gè)應(yīng)用的輸入、處理、輸出流程按照視圖、控制、模型的方式進(jìn)行分離，形成了控制器、模型、視圖三個(gè)核心模塊。

• 控制器（Controller）：接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求。該部分是用戶界面與Model的接口。一方面它解釋來自于視圖的輸入，將其解釋成為系統(tǒng)能夠理解的對(duì)象，同時(shí)它也識(shí)別用戶動(dòng)作，并將其解釋為對(duì)模型特定方法的調(diào)用；另一方面，它處理來自于模型的事件和模型邏輯執(zhí)行的結(jié)果，調(diào)用適當(dāng)?shù)囊晥D為用戶提供反饋。
• 模型（Model）：應(yīng)用程序的主體部分。模型表示業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)邏輯。一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)。由于同一個(gè)模型可以被多個(gè)視圖重用，所以提高了應(yīng)用的可重用性。
• 視圖（View）：用戶看到并與之交互的界面。視圖向用戶顯示相關(guān)的數(shù)據(jù)，并能接收用戶輸入的數(shù)據(jù)，但是它并不進(jìn)行任何實(shí)際的業(yè)務(wù)處理。視圖可以向模型查詢業(yè)務(wù)狀態(tài)，但不能改變模型。視圖還能接受模型發(fā)出的數(shù)據(jù)更新事件，從而對(duì)用戶界面進(jìn)行同步更新。

使用MVC模式來設(shè)計(jì)表現(xiàn)層，可以有以下的優(yōu)點(diǎn)：

• 允許多種用戶界面的擴(kuò)展。在MVC模式中，視圖與模型沒有必然的聯(lián)系，都是通過控制器發(fā)生關(guān)系，這樣如果要增加新類型的用戶界面，只需要改動(dòng)相應(yīng)的視圖和控制器即可，而模型則無須發(fā)生改動(dòng)。
• 易于維護(hù)?？刂破骱鸵晥D可以隨著模型的擴(kuò)展而進(jìn)行相應(yīng)的擴(kuò)展，只要保持一種公共的接口，控制器和視圖的舊版本也可以繼續(xù)使用。
• 功能強(qiáng)大的用戶界面。用戶界面與模型方法調(diào)用組合起來，使程序的使用更清晰，可將友好的界面發(fā)布給用戶。

MVP模式

MVP（Model-View-Presenter）模式提供數(shù)據(jù)， View負(fù)責(zé)顯示， Controller/Presenter負(fù)責(zé)邏輯的處理。

MVP是從經(jīng)典的模式MVC演變而來，MVP與MVC 的區(qū)別：MVC模式中元素之間“混亂”的交互主要體現(xiàn)在允許View和Model直接進(jìn)行“交流”，這在MVP模式中是不允的。在MVP中View并不直接使用Model，它們之間的通信是通過Presenter（MVC中的Controller）來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會(huì)直接從Model中讀取數(shù)據(jù)而不是通過Controller 。

使用MVP模式來設(shè)計(jì)表現(xiàn)層，可以有以下的優(yōu)點(diǎn)：

• 模型與視圖完全分離，可以修改視圖而不影響模型。
• 可以更高效地使用模型，因?yàn)樗械慕换ザ及l(fā)生在一個(gè)地方，Presenter內(nèi)部。
• 可以將一個(gè)Presenter用于多個(gè)視圖，而不需要改變Presenter的邏輯。這個(gè)特性非常的有用，因?yàn)橐晥D的變化總是比模型的變化頻繁。
• 如果把邏輯放在Presenter中，就可以脫離用戶接口來測(cè)試這些邏輯（單元測(cè)試）。

MVVM模式

MVM模式全稱是模型 - 視圖 - 視圖模型（Model - View - ViewModel），它和MVC、MVP不同的是：View與Model的交互通過ViewModel來實(shí)現(xiàn)。ViewModel是MVVM的核心，它通過DataBinding實(shí)現(xiàn)View與Model之間的雙向綁定，其內(nèi)容包括數(shù)據(jù)狀態(tài)處理、數(shù)據(jù)綁定及數(shù)據(jù)轉(zhuǎn)換。例如，View中某處的狀態(tài)和Model中某部分?jǐn)?shù)據(jù)綁定在一起，這部分?jǐn)?shù)據(jù)一旦變更將-會(huì)反映到View層。而這個(gè)機(jī)制通過ViewModel來實(shí)現(xiàn)。

ViewModel，即視圖模型，是一個(gè)專門用于數(shù)據(jù)轉(zhuǎn)換的控制器，它可以把對(duì)象信息轉(zhuǎn)換為視圖信息，將命令從視圖攜帶到對(duì)象。

ViewModel通常要實(shí)現(xiàn)一個(gè)觀察者，當(dāng)數(shù)據(jù)發(fā)生變化，ViewModel能夠監(jiān)聽到數(shù)據(jù)的變化，然后通知對(duì)應(yīng)的視圖做自動(dòng)更新：而當(dāng)用戶操作視圖，ViewModel也能監(jiān)聽到視圖的變化，再通知數(shù)據(jù)做改動(dòng)，從而形成數(shù)據(jù)的雙向綁定。這使得MVM更適用于數(shù)據(jù)驅(qū)動(dòng)的場(chǎng)景，尤其是數(shù)據(jù)操作特別頻繁的場(chǎng)景。

使用XML設(shè)計(jì)表現(xiàn)層

XML（可擴(kuò)展標(biāo)記語(yǔ)言）與HTML類似，是一種標(biāo)記語(yǔ)言。與主要用于控制數(shù)據(jù)的顯示和外觀的HTML標(biāo)記不同，XML標(biāo)記用于定義數(shù)據(jù)本身的結(jié)構(gòu)和數(shù)據(jù)類型。XML已被公認(rèn)為是優(yōu)秀的數(shù)據(jù)描述語(yǔ)言，并且成為了業(yè)內(nèi)廣泛采用的數(shù)據(jù)描述標(biāo)準(zhǔn)。

由于XML本身就是一種樹形結(jié)構(gòu)描述語(yǔ)言，所以可以很好地支持控件之間的層次結(jié)構(gòu)。GUI主要是由GUI控件組成?？丶梢钥闯墒且粋€(gè)數(shù)據(jù)對(duì)象，其包含位置信息、類型和綁定的事件等。這些信息在XML 中都可以作為數(shù)據(jù)結(jié)點(diǎn)保存下來，每一個(gè)控件都可以被描述成一個(gè) XML結(jié)點(diǎn)，而控件的那些相關(guān)屬性都可以描述成這個(gè)XML結(jié)點(diǎn)的Attribute。

表現(xiàn)層中UIP設(shè)計(jì)思想

表現(xiàn)層開發(fā)的痛點(diǎn)：

• 導(dǎo)航和工作流控制：這些將不會(huì)出現(xiàn)的Ul中，但是經(jīng)常因?yàn)橐跇I(yè)務(wù)邏輯決定哪一個(gè)視圖將被顯示。這導(dǎo)致代碼的不雅和難于管理。
• 導(dǎo)航和工作流改變：用傳統(tǒng)的UI技術(shù)改變應(yīng)用程序的界面（改變頁(yè)面的順序或者添加刪除頁(yè)面）是非常痛苦的。
• 狀態(tài)管理：不管是在windows form還是在web form中，在視圖間維護(hù)狀態(tài)都是比較困難的。
• 保存當(dāng)前交互的快照：你可能想保存一個(gè)交互的快照并且在別的地方（不同的時(shí)間，不同的地點(diǎn)）重新開始它。

UIP（UserInterface Process Application Block）是微軟社區(qū)開發(fā)的眾多Application Block中的其中之一，它是開源的。 UIP 提供了一個(gè)擴(kuò)展的框架，用于簡(jiǎn)化用戶界面與商業(yè)邏輯代碼的分離的方法，可以用它來寫復(fù)雜的用戶界面導(dǎo)航和工作流處理，并且它能夠復(fù)用在不同的場(chǎng)景、并可以隨著應(yīng)用的增加而進(jìn)行擴(kuò)展。

UIP框架的應(yīng)用程序把表現(xiàn)層分為了以下幾層：

• User Interface Components：這個(gè)組件就是原來的表現(xiàn)層，用戶看到的和進(jìn)行交互都是這個(gè)組件，它負(fù)責(zé)獲取用戶的數(shù)據(jù)并且返回結(jié)果。
• User Interface Process Components：這個(gè)組件用于協(xié)調(diào)用戶界面的各部分，使其配合后臺(tái)的活動(dòng)，例如導(dǎo)航和工作流控制，以及狀態(tài)和視圖的管理。用戶看不到這一組件，但是這些組件為User Interface Components提供了重要的支持功能。

中間層架構(gòu)設(shè)計(jì)

業(yè)務(wù)邏輯組件分為接口和實(shí)現(xiàn)類兩個(gè)部分。

• 接口：用于定義業(yè)務(wù)邏輯組件，定義業(yè)務(wù)邏輯組件必須實(shí)現(xiàn)的方法是整個(gè)系統(tǒng)運(yùn)行的核心通常按模塊來設(shè)計(jì)業(yè)務(wù)邏輯組件，每個(gè)模塊設(shè)計(jì)一個(gè)業(yè)務(wù)邏輯組件，并且每個(gè)業(yè)務(wù)邏輯組件以多個(gè)DAO（Data Access Object）組件作為基礎(chǔ)，從而實(shí)現(xiàn)對(duì)外提供系統(tǒng)的業(yè)務(wù)邏輯服務(wù)。增加業(yè)務(wù)邏輯組件的接口，是為了提供更好的解耦，控制器無須與具體的業(yè)務(wù)邏輯組件耦合，而是面向接口編程。
• 實(shí)現(xiàn)類：業(yè)務(wù)邏輯組件以DAO組件為基礎(chǔ)，必須接收Spring容器注入的DAO組件，因此必須為業(yè)務(wù)邏輯組件的實(shí)現(xiàn)類提供對(duì)應(yīng)的Setter方法。業(yè)務(wù)邏輯組件的實(shí)現(xiàn)類將DAO組件接口實(shí)例作為屬性（面向接口編程），而對(duì)于復(fù)雜的業(yè)務(wù)邏輯，可能需要訪問多個(gè)對(duì)象的數(shù)據(jù)，那么只需在這個(gè)方法里調(diào)用多個(gè)DAO接口，將具體實(shí)現(xiàn)委派給DAO完成。

業(yè)務(wù)邏輯層工作流設(shè)計(jì)

工作流管理聯(lián)盟（Workflow Management Coalition）將工作流定義為：業(yè)務(wù)流程的全部或部分自動(dòng)化，在此過程中，文檔、信息或任務(wù)按照一定的過程規(guī)則流轉(zhuǎn)，實(shí)現(xiàn)組織成員間的協(xié)調(diào)工作以達(dá)到業(yè)務(wù)的整體目標(biāo)。

• 過程定義導(dǎo)入/導(dǎo)出接口。這個(gè)接口的特點(diǎn)是：轉(zhuǎn)換格式和API調(diào)用，從而支持過程定義信息間的互相轉(zhuǎn)換。這個(gè)接口也支持已完成的過程定義或過程定義的一部分之間的互相轉(zhuǎn)換。早期標(biāo)準(zhǔn)是WPDL，后來發(fā)展為XPDL。
• 客戶端應(yīng)用程序接口。通過這個(gè)接口工作流機(jī)可以與任務(wù)表處理器交互，代表用戶資源來組織任務(wù)。然后由任務(wù)表處理器負(fù)責(zé)，從任務(wù)表中選擇、推進(jìn)任務(wù)項(xiàng)。由任務(wù)表處理器或者終端用戶來控制應(yīng)用工具的活動(dòng)。
• 應(yīng)用程序調(diào)用接口。允許工作流機(jī)直接激活一個(gè)應(yīng)用工具，來執(zhí)行一個(gè)活動(dòng)。典型的是調(diào)用以后臺(tái)服務(wù)為主的應(yīng)用程序，沒有用戶接口。當(dāng)執(zhí)行活動(dòng)要用到的工具，需要與終端用戶交互，通常是使用客戶端應(yīng)用程序接口來調(diào)用那個(gè)工具，這樣可以為用戶安排任務(wù)時(shí)間表提供更多的靈活性。
• 工作流機(jī)協(xié)作接口。其目標(biāo)是定義相關(guān)標(biāo)準(zhǔn)，以使不同開發(fā)商的工作流系統(tǒng)產(chǎn)品相互間能夠進(jìn)行無縫的任務(wù)項(xiàng)傳遞。 WFMC定義了4個(gè)協(xié)同工作模型，包含多種協(xié)同工作能力級(jí)別。
• 管理和監(jiān)視接口。提供的功能包括用戶管理、角色管理、審查管理、資源控制、過程管理和過程狀態(tài)處理器等。

用工作流的思想組織業(yè)務(wù)邏輯，優(yōu)點(diǎn)是：將應(yīng)用邏輯與過程邏輯分離，在不修改具體功能的情況下，通過修改過程模型改變系統(tǒng)功能，完成對(duì)生產(chǎn)經(jīng)營(yíng)部分過程或全過程的集成管理，可有效地把人、信息和應(yīng)用工具合理地組織在一起，發(fā)揮系統(tǒng)的最大效能。

業(yè)務(wù)邏輯層設(shè)計(jì)

業(yè)務(wù)框架位于系統(tǒng)架構(gòu)的中間層，是實(shí)現(xiàn)系統(tǒng)功能的核心組件。采用容器的形式，便于系統(tǒng)功能的開發(fā)、代碼重用和管理。大大降低業(yè)務(wù)層和相鄰各層的耦合。表示層代碼只需要將業(yè)務(wù)參數(shù)傳遞給業(yè)務(wù)容器，而不需要業(yè)務(wù)層多余的干預(yù)。有效地防止業(yè)務(wù)層代碼滲透到表示層。

• Domain Model是領(lǐng)域?qū)訕I(yè)務(wù)對(duì)象，它僅僅包含業(yè)務(wù)相關(guān)的屬性。
• Service是業(yè)務(wù)過程實(shí)現(xiàn)的組成部分，是應(yīng)用程序的不同功能單元，通過在這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。這種具有中立的接口定義（沒有強(qiáng)制綁定到特定的實(shí)現(xiàn)上）的特征稱為服務(wù)之間的松耦合。松耦合系統(tǒng)的好處有兩點(diǎn)，一是它的靈活性，二是當(dāng)組成整個(gè)應(yīng)用程序的每個(gè)服務(wù)的內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)逐漸地發(fā)生改變時(shí)，它能夠繼續(xù)存在。
• Control服務(wù)控制器，是服務(wù)之間的紐帶，不同服務(wù)之間的切換就是通過它來實(shí)現(xiàn)的。通過服務(wù)控制器控制服務(wù)切換可以將服務(wù)的實(shí)現(xiàn)和服務(wù)的轉(zhuǎn)向控制分離，提高了服務(wù)實(shí)現(xiàn)的靈活性和重用性。

數(shù)據(jù)訪問層設(shè)計(jì)

5種數(shù)據(jù)訪問模式

在線訪問

在線訪問是最基本的數(shù)據(jù)訪問模式，在實(shí)際開發(fā)過程中最常采用的。

這種數(shù)據(jù)訪問模式會(huì)占用一個(gè)數(shù)據(jù)庫(kù)連接，讀取數(shù)據(jù)，每個(gè)數(shù)據(jù)庫(kù)操作都會(huì)通過這個(gè)連接不斷地與后臺(tái)的數(shù)據(jù)源進(jìn)行交互。

Data Access Object

DAO模式是標(biāo)準(zhǔn)J2EE設(shè)計(jì)模式之一，開發(fā)人員常常用這種模式將底層數(shù)據(jù)訪問操作與高層業(yè)務(wù)邏輯分離開。

一個(gè)典型的DAO實(shí)現(xiàn)通常有以下組件：

• 一個(gè)DAO 工廠類
• 一個(gè)DAO接口
• 一個(gè)實(shí)現(xiàn)了DAO接口的具體類
• 數(shù)據(jù)傳輸對(duì)象，這當(dāng)中具體的DAO類包含訪問特定數(shù)據(jù)源的數(shù)據(jù)的邏輯。

Data Transfer Object

Data Transfer Object是經(jīng)典EJB設(shè)計(jì)模式之一。 DTO本身是這樣一組對(duì)象或是數(shù)據(jù)的容器，它需要跨不同的進(jìn)程或是網(wǎng)絡(luò)的邊界來傳輸數(shù)據(jù)。這類對(duì)象本身應(yīng)該不包含具體的業(yè)務(wù)邏輯，并且通常這些對(duì)象內(nèi)部只能進(jìn)行一些諸如內(nèi)部一致性檢查和基本驗(yàn)證之類的方法，而且這些方法最好不要再調(diào)用其他的對(duì)象行為。

在具體設(shè)計(jì)這類對(duì)象（DTO）時(shí)，通?？梢杂腥缦聝煞N選擇：

• 使用編程語(yǔ)言內(nèi)置的集合對(duì)象。
• 通過創(chuàng)建自定義類來實(shí)現(xiàn)DTO對(duì)象。

離線數(shù)據(jù)模式

離線數(shù)據(jù)模式是以數(shù)據(jù)為中心，數(shù)據(jù)從數(shù)據(jù)源獲取之后，將按照某種預(yù)定義的結(jié)構(gòu)（這種結(jié)構(gòu)可以是SDO中的Data圖表結(jié)構(gòu)，也同樣可以是 ADO.NET 中的關(guān)系結(jié)構(gòu)）存放在系統(tǒng)中，成為應(yīng)用的中心。離線，對(duì)數(shù)據(jù)的各種操作獨(dú)立于各種與后臺(tái)數(shù)據(jù)源之間的連接或是事務(wù)；與XML集成，數(shù)據(jù)可以方便地與XML格式的文檔之間互相轉(zhuǎn)換；獨(dú)立于數(shù)據(jù)源，離線數(shù)據(jù)模式的不同實(shí)現(xiàn)定義了數(shù)據(jù)的各異的存放結(jié)構(gòu)和規(guī)則，這些都是獨(dú)立于具體的某種數(shù)據(jù)源的。

對(duì)象/關(guān)系映射（Object/Relation Mapping，O/R Mapping）

大多數(shù)應(yīng)用中的數(shù)據(jù)都是依據(jù)關(guān)系模型存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)中，而很多應(yīng)用程序中的數(shù)據(jù)在開發(fā)或是運(yùn)行時(shí)則是以對(duì)象的形式組織起來的。

工廠模式在數(shù)據(jù)訪問層應(yīng)用

在編寫應(yīng)用系統(tǒng)的時(shí)候，盡量做到數(shù)據(jù)庫(kù)無關(guān)。這就需要在實(shí)際開發(fā)過程中將數(shù)據(jù)庫(kù)訪問類作一次封裝。經(jīng)過這樣的封裝，不僅可以達(dá)到良好的封裝性和可維護(hù)性，還可以減少操作數(shù)據(jù)庫(kù)的步驟，減少代碼編寫量。工廠設(shè)計(jì)模式是使用的主要方法。

工廠模式定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化哪一個(gè)類。工廠方法使一個(gè)類的實(shí)例化延遲到其子類。這里可能會(huì)處理對(duì)多種數(shù)據(jù)庫(kù)的操作，因此，需要首先定義一個(gè)操縱數(shù)據(jù)庫(kù)的接口，然后根據(jù)數(shù)據(jù)庫(kù)的不同，由類工廠決定實(shí)例化哪個(gè)類。

ORM、Hibernate與CMP2.0設(shè)計(jì)思想

ORM（Object-Relation Mapping）在關(guān)系型數(shù)據(jù)庫(kù)和對(duì)象之間作一個(gè)映射，這樣，在具體操縱數(shù)據(jù)庫(kù)時(shí)，就不需要再去和復(fù)雜的SQL語(yǔ)句打交道，只要像平時(shí)操作對(duì)象一樣操作即可。

提到Hibernate必須要說到Mybatis，相關(guān)內(nèi)容自行搜索，開發(fā)人員必備。

靈活運(yùn)用XML Schema

XML Schema用來描述XML文檔合法結(jié)構(gòu)、內(nèi)容和限制。XML Schema由XML1.0自描述，并且使用了命名空間，有豐富的內(nèi)嵌數(shù)據(jù)類型及其強(qiáng)大的數(shù)據(jù)結(jié)構(gòu)定義功能，充分地改造了并且極大地?cái)U(kuò)展了DTDs（傳統(tǒng)描述XML文檔結(jié)構(gòu)和內(nèi)容限制的機(jī)制）的能力，將逐步替代DTDs，成為XML體系中正式的類型語(yǔ)言，同XML規(guī)范、Namespace規(guī)范一起成為XML體系的堅(jiān)實(shí)基礎(chǔ)。

事務(wù)處理設(shè)計(jì)

事務(wù)必須服從ISO/IEC所制定的ACID原則。 ACID是原子性（Atomicity）、 一致性（Consistency）、 隔離性（Isolation）和持久性（Durability）的縮寫。

• 原子性：表示事務(wù)執(zhí)行過程中的任何失敗都將導(dǎo)致事務(wù)所做的任何修改失效。
• 一致性：表示當(dāng)事務(wù)執(zhí)行失敗時(shí)，所有被該事務(wù)影響的數(shù)據(jù)都應(yīng)該恢復(fù)到事務(wù)執(zhí)行前的狀態(tài)。
• 隔離性：表示在事務(wù)執(zhí)行過程中對(duì)數(shù)據(jù)的修改，在事務(wù)提交之前對(duì)其他事務(wù)不可見。
• 持久性：表示已提交的數(shù)據(jù)在事務(wù)執(zhí)行失敗時(shí)，數(shù)據(jù)的狀態(tài)都應(yīng)該正確。

數(shù)據(jù)架構(gòu)規(guī)劃與設(shè)計(jì)

Web上存有大量的XML文檔，并需要持久保存，這一需求引發(fā)了人們對(duì)XML文檔的存儲(chǔ)技術(shù)研究。已經(jīng)提
出的XML文檔的存儲(chǔ)方式有兩種：基于文件的存儲(chǔ)方式和數(shù)據(jù)庫(kù)存儲(chǔ)方式。

• 基于文件的存儲(chǔ)方式?；谖募拇鎯?chǔ)方式是指將XML文檔按其原始文本形式存儲(chǔ)，主要存儲(chǔ)技術(shù)包括操作系統(tǒng)文件庫(kù)、通用文檔管理系統(tǒng)和傳統(tǒng)數(shù)據(jù)庫(kù)的列（作為二進(jìn)制大對(duì)象BLOB或字符大對(duì)象CLOB）。這種存儲(chǔ)方式需維護(hù)某種類型的附加索引，以建立文件之間的層次結(jié)構(gòu)?；谖募拇鎯?chǔ)方式的特點(diǎn)：無法獲取XML文檔中的結(jié)構(gòu)化數(shù)據(jù)；通過附加索引可以定位具有某些關(guān)鍵字的 XML 文檔，一旦關(guān)鍵字不確定，將很難定位；查詢時(shí)，只能以原始文檔的形式返回，即不能獲取文檔內(nèi)部信息；文件管理存在容量大、管理難的缺點(diǎn)。
• 數(shù)據(jù)庫(kù)存儲(chǔ)方式。數(shù)據(jù)庫(kù)在數(shù)據(jù)管理方面具有管理方便、存儲(chǔ)占用空間小、檢索速度快、修改效率高和安全性好等優(yōu)點(diǎn)。一種比較自然的想法是采用數(shù)據(jù)庫(kù)對(duì)XML文檔進(jìn)行存取和操作，這樣可以利用相對(duì)成熟的數(shù)據(jù)庫(kù)技術(shù)處理XML文檔內(nèi)部的數(shù)據(jù)。數(shù)據(jù)庫(kù)存儲(chǔ)方式的特點(diǎn)：能夠管理結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)；具有管理和控制整個(gè)文檔集合本身的能力；可以對(duì)文檔內(nèi)部的數(shù)據(jù)進(jìn)行操作；具有數(shù)據(jù)庫(kù)技術(shù)的特性，如多用戶、并發(fā)控制和致性約束等；管理方便，易于操作。