第57章高級(jí)數(shù)據(jù)管理服務(wù)

1、第57章高級(jí)數(shù)據(jù)管理服務(wù)本章補(bǔ)充了在數(shù)據(jù)管理服務(wù)（ DMS ）的前一章節(jié)，通過(guò)懶惰關(guān)系的工作收集解決項(xiàng)目 暫停錯(cuò)誤和管理用戶指定數(shù)據(jù)的技巧。57.1 DMS的概述有很多的途徑可以應(yīng)用DMS，這些可用的途徑有時(shí)讓人暈頭轉(zhuǎn)向。從權(quán)衡懶惰關(guān)系和渴望關(guān)系優(yōu)勢(shì)的對(duì)比，到選擇大多數(shù)的可用的通訊渠道和端點(diǎn)、最合理利用客戶端和服務(wù)器端的庫(kù)。在這一過(guò)程中，有一些缺點(diǎn)是可以避免的。本章涵蓋了三個(gè)專題項(xiàng)目相關(guān)的一些DMS項(xiàng)目。這些是可能沒(méi)有被正式文件所涵蓋。簡(jiǎn)要到詳細(xì)信息的建模一一 通常情況下，在給用戶提供一個(gè)項(xiàng)目的全部信息之前都會(huì)先列出以個(gè)簡(jiǎn)要信息。通過(guò)LCDS會(huì)有很多的實(shí)現(xiàn)方法，但是結(jié)果卻有一些微妙卻重要的不同

2、?？朔tem-pending的錯(cuò)誤LCDS的空對(duì)象錯(cuò)誤要進(jìn)行對(duì) MXML透明的綁定處理，特別是 ActionScript代碼。封裝一個(gè)可以找出item-pending錯(cuò)誤的簡(jiǎn)單的函數(shù)，反復(fù)使用它直到所有項(xiàng)目的未決部分都被檢查過(guò)。管理共享和User-Specific 的數(shù)據(jù) 一一LCDS可以很容易的實(shí)現(xiàn)用戶之間的數(shù)據(jù) 同步，相反有時(shí)一個(gè)清晰的只屬于個(gè)人的數(shù)據(jù)模型是必須的。在本章的最后以官方文件為基礎(chǔ)指出了一些重要的但是沒(méi)有在此書中詳細(xì)介紹的技巧。57.2概要到詳盡的建模許多大型的互聯(lián)網(wǎng)應(yīng)用程序在允許用戶“放大”選定項(xiàng)目并查看詳細(xì)信息之前都先羅列出它的概要信息。例如，電子郵件客戶端經(jīng)常顯示摘要信

3、息，在用戶的收件箱中列出包含標(biāo)題，發(fā)件人和郵件的日期。 當(dāng)一個(gè)客戶選擇一個(gè)消息，它就會(huì)顯示出它所屬的郵件的正文或全部會(huì)話內(nèi)容。這是從性能和內(nèi)存角度選擇出的模式，因?yàn)樗恍枰A(yù)先提取簡(jiǎn)要的資料。沒(méi)有必要在用戶只想查看其中一個(gè)或兩個(gè)有關(guān)細(xì)節(jié)的時(shí)候提取所有會(huì)話的全部詳細(xì)內(nèi) 容。相反，他們可以根據(jù)他們的需要進(jìn)行提取信息。此行為可能引導(dǎo)LCDS開發(fā)利用懶惰關(guān)系的優(yōu)勢(shì)填充信件的具體內(nèi)容，使用管理對(duì)象模型類似如圖57-1EmailSummary+ id :String+ title:String+ sender:String+ sentDate:Date+ received date: Datethread

4、<lazy>EmailDetails+ EmailSummaryO+ id :String+ body:Stri ng+ attachments ：String+ EmallDetailsOFigure 57-1然而，這決定不應(yīng)掉以輕心，因?yàn)檫@可能會(huì)導(dǎo)致性能不佳，更高的內(nèi)存消耗，和不必要 的服務(wù)請(qǐng)求-也就是原意相反的！這取決于所涉及的數(shù)據(jù)，如何使用綁定，以及以何種方式 用戶可以與數(shù)據(jù)交互。想象一下，用戶界面是一分為二，就是電子郵件的摘要列表左側(cè)，而右邊，是所選信息的詳細(xì)信息。如果用戶選擇第一個(gè)信息， 然后在列表中快速向下滾動(dòng)光標(biāo)。所有信息都將被選取。如果綁定是用來(lái)呈現(xiàn)懶惰的關(guān)系，通

5、過(guò)信件的具體內(nèi)容，那么每次消息被選中，其細(xì)節(jié)將自動(dòng)從服務(wù)器提取。這將導(dǎo)致許多不必要的服務(wù)請(qǐng)求， 并在被管理對(duì)象模型規(guī)模的增加， 因?yàn)檫@些細(xì)節(jié)對(duì)象在被歸還時(shí)不會(huì)被自動(dòng)清理。通過(guò)獲取項(xiàng)目替換懶惰關(guān)系在這樣的情況下，一般最好使用getltem ()或fill ()方法而不是懶惰關(guān)系之間建立摘要和詳細(xì)信息鏈接。這使得郵件細(xì)節(jié)的實(shí)際接受和后期的清理更加容易控制。電子郵件客戶端實(shí)現(xiàn)可以選擇在內(nèi)存中只以一個(gè)郵件的形式保存電子郵件的全部會(huì)話，而不是每查看新E 廠日 W*d.：5!ring-：論 iStrirj mdr : Srir： -S?itD3t= :* EmailS umma ry()信息就越來(lái)越多的收

6、集更多的數(shù)據(jù)。圖57-2顯示了概要到詳細(xì)的 FILL方法的定義。Ernail5umrriaryKt5»mbls,EmailDetails Ass; mbter|-MfEmai Summar«i>1*summarD :String):CoNectionEmaUktails+ i 二:Stnrz+ tDdh>' :String -砒二r 小:Strirf -ErrllD-ELdllSI IFigure 57'2該 EmailSummaryAssembler 定義一個(gè) FILL 方法，getEmailSummaries ()，填充 EmailSumma

7、ry管理對(duì)象集合。EmailSummary ID屬性可以用作第二個(gè)FILL方法的參數(shù)，getConversation ()，在 EmailDetailsAssember 中的填充 EmailDetails 管理對(duì)象集合的方 法只適于單獨(dú)的會(huì)話。在一個(gè)EmailSummary從列表視圖中被選中的時(shí)候需要協(xié)調(diào)客戶端這邊使當(dāng)?shù)卣{(diào)用getCo nversatio n()來(lái)填充方法。57.3 克服 Item-Pending 錯(cuò)誤Item-Pending錯(cuò)誤對(duì)LCDS來(lái)說(shuō)相當(dāng)于空對(duì)象錯(cuò)誤對(duì)Flex。他們經(jīng)常意外的發(fā)生，通常是因?yàn)樾〉木幊体e(cuò)誤或是系統(tǒng)變更的副作用。 一個(gè)單元測(cè)試套件可以很容易地抵御空對(duì)象錯(cuò)

8、誤，但難以保護(hù) Item-Pending 錯(cuò)誤，因?yàn)樗麄兛赡艹霈F(xiàn)或消失取決于服務(wù)器的配置更改。綁定表達(dá)式是最簡(jiǎn)潔的處理 Item-Pending 錯(cuò)誤的方式，當(dāng)綁定到一個(gè)懶惰關(guān)系屬性時(shí)， Item-Pending 錯(cuò)誤的發(fā)生就會(huì)被綁定結(jié)構(gòu)吞沒(méi)。每當(dāng)屬性被接收，綁定就啟動(dòng)，直到所有的 關(guān)聯(lián)都被裝載。例如，如果個(gè)人到地址的關(guān)聯(lián)是之后的，哪么隨后的MXML 將會(huì)隱藏Item-Pending 錯(cuò)誤，然后接收地址數(shù)據(jù)提交給street。<mx:Label text= ” person.address.street ”/>但是有時(shí)會(huì)有 Item-Pending 錯(cuò)誤需要提交給內(nèi)部編程處理的 A

9、ctionScript 類。此傳統(tǒng)的 方法是附加響應(yīng)這個(gè) Item-Pending 錯(cuò)誤，所以當(dāng)一個(gè)屬性被接受時(shí)結(jié)果處理函數(shù)就被調(diào)用。 然后結(jié)果再次調(diào)用函數(shù)就需要懶惰關(guān)系。這種方法有一定局限性。 如果有問(wèn)題的屬性鏈有一個(gè)以上的惰性關(guān)聯(lián)， 那么 fetchAddressResult （ ）方法本身可 能引發(fā) Item-Pending 錯(cuò)誤 。 處理不同級(jí) 別的 個(gè) 別 Item-Pending 錯(cuò)誤是十分冗雜的，所以需要更好的解決辦法。57.3.1 Repeated AttacksRepeated attack 是一種解決在 Action Script 中這種錯(cuò)誤的簡(jiǎn)單技術(shù)。 它通過(guò)多次調(diào)用 （

10、或attacking）能引起Item-Pending錯(cuò)誤的代碼塊直到不再發(fā)生這樣的錯(cuò)誤。錯(cuò)誤處理代碼限制 于一個(gè)單獨(dú)的地方。這是通過(guò)高度遞歸響應(yīng)掛接到原來(lái)的函數(shù)，如下所示這種技術(shù)允許processPersonalDetails（）函數(shù)內(nèi)部代碼保持簡(jiǎn)單，而不去關(guān)注Item-Pending 錯(cuò)誤。該函數(shù)可以被編碼，猶如渴望關(guān)系，而不是懶惰關(guān)系，創(chuàng)建的代碼，其他開發(fā)人員更 容易閱讀和理解。注意一個(gè)被 try-catch 圍繞的函數(shù)被多次調(diào)用時(shí)這個(gè)技術(shù)是很重要的。這種技術(shù)相比效 率更在意簡(jiǎn)潔， 因?yàn)槟繕?biāo)函數(shù)雖然簡(jiǎn)單但是在邏輯上可能處理了很多次。在某些情況下， 可以更好地修改管理的數(shù)據(jù)模型，以減少懶惰關(guān)

11、系。57.4 數(shù)據(jù)管理與用戶特殊數(shù)據(jù)DMS 便于用戶之間同步數(shù)據(jù)， 但有些時(shí)候數(shù)據(jù)需要特殊保存到單個(gè)用戶， 而不是共享。 事實(shí)上，協(xié)作應(yīng)用程序的數(shù)據(jù)形式通常即需要有管理的數(shù)據(jù)模型共享的部分可以用來(lái)訪問(wèn)和 被多個(gè)用戶同時(shí)更新。 也有其它部分只屬于個(gè)人用戶。 一個(gè)像這樣的數(shù)據(jù)管理模型需要進(jìn)行 仔細(xì)設(shè)計(jì)，以確保私有的信息不被共享和錯(cuò)誤同步。5741 個(gè)簡(jiǎn)單的即使消息系統(tǒng)考慮建立一個(gè)即時(shí)消息到一個(gè)Flex應(yīng)用程序的系統(tǒng)內(nèi)案件。用戶可以將消息發(fā)送到一個(gè)或多個(gè)收件人，然后它將作為一個(gè)新的未讀郵件出現(xiàn)在收件箱中。當(dāng)收件人打開這個(gè)郵件，它將被標(biāo)記為已讀。 這個(gè)模型中，主要信息的詳細(xì)信息一一主題，信息體和發(fā)件人

12、一一都是在收件人之間共享的， 但是這封郵件的已讀與未讀的標(biāo)記是對(duì)于用戶所特有的。一個(gè)簡(jiǎn)單的即時(shí)信息系統(tǒng)的信息數(shù)據(jù)模型如下所示Figure 57-3.+ id :Strip?+ rscipent :lls«rD=t3 its0據(jù)*+ id String亠 :Sirhj+ 陶:Sbrij+ attachrn?rts:Array:DateFigu re 57-3MessageDetails類包含了一般的信件信息，而UserMessage類擁有用戶特有屬性。從UserMessage類到 MessageDetails類有多對(duì)一的關(guān)系。MessageDetails類有一對(duì)多的關(guān)系與用 戶類來(lái)為信

13、息創(chuàng)建收件人模型。每個(gè)UserMessage類通過(guò)一個(gè)一對(duì)一的關(guān)系從屬于單獨(dú)的一 個(gè)用戶模型。可以通過(guò)這本書的InstantMessaging項(xiàng)目找到這個(gè)簡(jiǎn)單的即時(shí)消息系統(tǒng)的源代碼。它提供了一個(gè)部分共享，部分用戶獨(dú)有的數(shù)據(jù)管理模型的例子。另外，它演示了一個(gè)AMF流連接到高性能的 NIO-server和addltemToFill ()以Java LCDS庫(kù)推動(dòng)用戶特有服務(wù)的有效改 變的特征。建立一個(gè)新的信息詳細(xì)項(xiàng)目通過(guò)LCDS，有各種方式創(chuàng)造新的管理的數(shù)據(jù)項(xiàng)。他們可以創(chuàng)建使用的CreateItem ()方法的客戶端，或增加到了一個(gè)已經(jīng)管理的集合，或者他們可以直接在服務(wù)器上拖拽出客戶端。在即時(shí)通訊

14、系統(tǒng)的情況下，客戶首先創(chuàng)建一個(gè)MessageDetails類的新實(shí)例時(shí)，點(diǎn)擊發(fā)送按鈕，如下所示消息對(duì)象被構(gòu)造，那么它的屬性設(shè)置為各種輸入控件的值。收件人的屬性被設(shè)置成一個(gè)發(fā)件地址指向的被管理用戶對(duì)象的鏈性集合。新信息在提交給服務(wù)器確認(rèn)之前就被傳遞到數(shù)據(jù)服務(wù)的createltem()方法中，因?yàn)樽詣?dòng)提交功能被禁用了。這個(gè)導(dǎo)致了新對(duì)象被傳遞給相 應(yīng)服務(wù)器的createItem()方法。5743創(chuàng)建和提交用戶郵件在服務(wù)器端，MessageDetailsService目標(biāo)使用 Java對(duì)象適配器和一個(gè)自定義匯編, MessageDetailsAssembler 。 createItem() 方 法 的

15、執(zhí)行 既支 持新的 MessageDetail 對(duì) 象使 用InstantMessageData 類，同時(shí)也支持對(duì)每個(gè)信件接收方創(chuàng)建和維持新的 UserMessage 對(duì)象。 這些對(duì)象到時(shí)會(huì)通過(guò) DataServiceTransaction 類的 addItemToFill() 方法發(fā)送到正確的用戶那 去。如下：數(shù)據(jù)的創(chuàng)建與維持通過(guò)數(shù)據(jù)的成員變量被 InstantMessageData 方法所處理。在示例項(xiàng)目 中，類實(shí)際上并不存在的數(shù)據(jù)到后臺(tái)的數(shù)據(jù)存儲(chǔ)， 而只是幾個(gè)簡(jiǎn)單的維持在內(nèi)存中的數(shù)據(jù)結(jié) 構(gòu)。方法的重要部分是 DataServiceTransaction 類的使用。當(dāng)前事務(wù)是首先抓住靜態(tài)的

16、 getCurrentDataServiceTransaction() 方法。在每個(gè)循環(huán)之后，都為下一個(gè)郵件收件人創(chuàng)建一個(gè) 新的用戶對(duì)象，然后通過(guò) addItemToFill() 方法處理交給用戶。這種簡(jiǎn)單的處理工作，因?yàn)?UserMessageService 填寫方法是通過(guò)用戶的 ID 參數(shù)，所以每個(gè)用戶都有自己的填寫方法?；氐娇蛻舳?，新UserMessage將由一個(gè)UserMessageService目標(biāo)數(shù)據(jù)服務(wù)接收并添加到 信息管理集合。由于 UserMessageService 服務(wù)與 MessageDetails 有渴望關(guān)系，相應(yīng)的 MessageDetails對(duì)象將與UserMes

17、sage一起被發(fā)送到客戶端。這個(gè)郵件就會(huì)出現(xiàn)在控制列表， 當(dāng)一個(gè)用戶點(diǎn)擊這個(gè)郵件，它的已讀標(biāo)記設(shè)置為true。由于這個(gè)UserMessage屬于用戶特有, 這個(gè)更改不與其他用戶同步，這個(gè)情況是正確的。5745 AMF至U NIO終點(diǎn)的流即時(shí)信息的實(shí)例也演示了一個(gè) AMF 流連接到通過(guò) LCDS2.6 提供的高效 NIO 服務(wù)。這 種結(jié)合為用戶提供了豐富的經(jīng)驗(yàn)，因?yàn)橐粋€(gè)永久的流連接是從每個(gè)客戶端服務(wù)器進(jìn)行維護(hù)， 使 LCDS 可以立即將新的消息發(fā)出去。 NIO-server 的使用意味著多個(gè)用戶可以由同一 JAVA 線程進(jìn)行服務(wù)，這樣可擴(kuò)展性就比被線程阻塞規(guī)則限制下的servler-based

18、終點(diǎn)方式大很多倍。channel 和 end point services-config.xml file 中的配置此頻道中的定義， StreamingAMFChannel 是搭配 StreamingNIOAMFEndpoint 。配置屬性 指定服務(wù)器將發(fā)送心跳消息，每個(gè)連接的客戶端每 10 秒保持流連接。用戶代理元素用于配 置特定于瀏覽器設(shè)置，確保流連接可適當(dāng)確定，并限制每節(jié)并發(fā)連接數(shù)。 有關(guān)配置流渠道更全面的詳細(xì)規(guī)定是在“流 AMF 和 HTTP 通道”的 LCDS 開發(fā)指南一節(jié)。57.5 深入學(xué)習(xí)有很多重要的論題雖然沒(méi)在此書中提及但是確在官方的LCDS 開發(fā)指南中有詳細(xì)的介紹。在著手一個(gè)

19、重要的 LCDS 項(xiàng)目之前，應(yīng)鼓勵(lì)開發(fā)者詳細(xì)閱讀開發(fā)指南，因?yàn)樗婕傲?數(shù)百頁(yè)的細(xì)節(jié)功能介紹。我們要特別注意數(shù)據(jù)管理服務(wù)的以下三種特征， 因?yàn)槲覀儾皇窃?jīng)忽略過(guò)就是僅在書中 稍微提到過(guò)。等級(jí)數(shù)據(jù) 這本書中所列舉的各個(gè)樣例應(yīng)用都采用了一個(gè)獨(dú)立的DMS 終點(diǎn)(數(shù)據(jù)管理服務(wù))來(lái)管理一個(gè)單獨(dú)的類。事實(shí)上，一個(gè) DMS 終點(diǎn)可以被用來(lái)管理一個(gè)類型層次，盡 管會(huì)有所限制。這些類型層次中的各個(gè)類必須共享同一個(gè)身份和聯(lián)系的性質(zhì)。數(shù)據(jù)分頁(yè) 盡管樣例應(yīng)用里解釋并使用了客戶對(duì)用戶之間的分頁(yè)， DMS 也支持后臺(tái) 數(shù)據(jù)庫(kù)（或其他系統(tǒng)）和服務(wù)器上的裝配器層之間的分頁(yè)。這對(duì)于把 DMS 應(yīng)用改變到非常 大的數(shù)據(jù)設(shè)置。而且

20、，有了 LCDS2.6 之后，與 DMS 終端之間的關(guān)聯(lián)也支持分頁(yè)。沖突解決 通常當(dāng)用 DMS 建立一個(gè)合作應(yīng)用時(shí)，解決數(shù)據(jù)沖突時(shí)很必要的。通常是 在多個(gè)用戶同時(shí)改變同一個(gè)已經(jīng)被管理好的數(shù)據(jù)屬性的時(shí)候需要解決沖突。 LCDS 圖書館具 有偵查與解決這種沖突的特征。下面一個(gè)話題不是針對(duì) DMS ，而是整體應(yīng)用 LCDD 的。它們對(duì)開發(fā)與調(diào)度企業(yè) LCDS 應(yīng)用很重要。適應(yīng)性調(diào)查 這是一個(gè)高級(jí)的服務(wù)器端可伸展性的一點(diǎn)， 它允許開發(fā)人員修改 LCDS 服務(wù)器的信息排隊(duì)等待和發(fā)送的行為。 可以用來(lái)提高服務(wù)質(zhì)量和效率， 截流投送率。 將多個(gè) 信息混合為一個(gè)，或是丟掉稍微老舊的信息，用更新的來(lái)取代。安全性 LCDS 可以與 J2EE 的應(yīng)用服務(wù)器的安全框架合為一個(gè)，從而被調(diào)用，但它 也可以支持自定義身份驗(yàn)證和授權(quán)的處理過(guò)程。 對(duì)每一個(gè)安全的溝通渠道的變化， 并有憑據(jù) 可以通過(guò)代理服務(wù)從客戶端遠(yuǎn)程 HTTP 的 SOAP Web 服務(wù)的服務(wù)。用白名單和黑名單可以 保護(hù) NIO