1.1.? 該方案的優(yōu)勢(shì)

在支持互聯(lián)網(wǎng)應(yīng)用中，BS和三層CS結(jié)構(gòu)到底誰(shuí)更合適？是一直以來(lái)爭(zhēng)論不休的問(wèn)題。筆者認(rèn)為這個(gè)問(wèn)題應(yīng)該根據(jù)不用的應(yīng)用情況而定，對(duì)于E商這種連鎖行業(yè)的業(yè)務(wù)系統(tǒng)，筆者認(rèn)為三層CS結(jié)構(gòu)會(huì)更加合適。

?	BS結(jié)構(gòu)	CS結(jié)構(gòu)	三層CS結(jié)構(gòu)
跨地域、跨網(wǎng)絡(luò)	可以	不可以，只可以用于局域網(wǎng)，跨網(wǎng)絡(luò)應(yīng)用時(shí)需要額外的投入，且應(yīng)用效果不理想	可以
操作性	不好，網(wǎng)頁(yè)的操作方式對(duì)于大數(shù)量的操作效果不理想	好	好，在客戶(hù)端方面與CS結(jié)構(gòu)的客戶(hù)端操作效果完全一致
服務(wù)器的壓力	非常大，所有的計(jì)算都在服務(wù)器上，所以服務(wù)器壓力非常大	小，客戶(hù)端分擔(dān)了部分計(jì)算壓力	小，與CS結(jié)構(gòu)完全一致
網(wǎng)絡(luò)傳輸	速度慢，因?yàn)閔tml的頁(yè)面有大量的冗余信息，必然會(huì)導(dǎo)致網(wǎng)絡(luò)流量大的問(wèn)題	快，因?yàn)橹恍枰獋鬏敂?shù)據(jù)	快，因?yàn)橹恍枰獋鬏敂?shù)據(jù)

本方案另外一個(gè)顯著的特點(diǎn)是：該方案采用了三層CS結(jié)構(gòu)，且在服務(wù)器端采用了Java服務(wù)器，客戶(hù)端采用了.net的開(kāi)發(fā)技術(shù)，可以說(shuō)是各取其所長(zhǎng)。Java技術(shù)長(zhǎng)于服務(wù)器，服務(wù)器的穩(wěn)定性業(yè)界公認(rèn)，常用于大型的系統(tǒng)，但java技術(shù)在客戶(hù)端的開(kāi)發(fā)則劣勢(shì)明顯。微軟的.net開(kāi)發(fā)框架則恰恰相反，微軟的中間件服務(wù)器，也就是IIS，其穩(wěn)定性和安全性一直為業(yè)界所詬病，一般只用于中小型企業(yè)的業(yè)務(wù)系統(tǒng)，對(duì)于大型高并發(fā)的系統(tǒng)應(yīng)用，則有點(diǎn)勉為其難。

所以，本方案在服務(wù)器但仍采用java服務(wù)器，可以與現(xiàn)有DRP采用同樣的服務(wù)器平臺(tái)，服務(wù)器的統(tǒng)一可以保證數(shù)據(jù)平臺(tái)的擴(kuò)展性和數(shù)據(jù)統(tǒng)一性。對(duì)于客戶(hù)端我們采用了.net的開(kāi)發(fā)框架，保證了客戶(hù)端良好的操作性，保證了用戶(hù)的良好使用感受和高效的工作效率。對(duì)于服務(wù)器和客戶(hù)端的通信，則由我們自行開(kāi)發(fā)了通信接口，既保證了通信效率，也增強(qiáng)了報(bào)密性和安全性。

?	Java技術(shù)	.net	本方案
服務(wù)器	強(qiáng)，穩(wěn)定性和安全性都經(jīng)過(guò)了實(shí)踐的檢驗(yàn)	差，微軟的中間件服務(wù)器的穩(wěn)定性一致為業(yè)界詬病	服務(wù)器采用java技術(shù)
客戶(hù)端	差，客戶(hù)端開(kāi)發(fā)一直是java的弱項(xiàng)	強(qiáng)，微軟一直擅長(zhǎng)于用戶(hù)界面的開(kāi)發(fā)	客戶(hù)端采用微軟.net技術(shù)

?

1.2.? 系統(tǒng)整體結(jié)構(gòu)

系統(tǒng)為基于業(yè)界主流的三層架構(gòu)技術(shù)：

l? 數(shù)據(jù)庫(kù)：支持SQL Server、Oracle等多種數(shù)據(jù)庫(kù)。

l? 應(yīng)用服務(wù)器：可采用WebLogic、Tomcat等J2EE中間件，提供業(yè)務(wù)邏輯實(shí)現(xiàn)，數(shù)據(jù)存取，以及與外系統(tǒng)交互的各種接口。

l? 客戶(hù)端：采用基于.net 2.0的winform客戶(hù)端作為業(yè)務(wù)操作終端。

?

系統(tǒng)結(jié)構(gòu)框圖：

1.3.? 系統(tǒng)中的對(duì)象

系統(tǒng)中數(shù)據(jù)存取涉及四種不同類(lèi)型的對(duì)象：

PO:?全稱(chēng)為presentation object，即表現(xiàn)層對(duì)象。通常在客戶(hù)端使用，用于界面控件的數(shù)據(jù)綁定。一個(gè)PO對(duì)象可能包含一個(gè)或多個(gè)VO對(duì)象，或者是VO對(duì)象的線性集合。PO對(duì)象出于展現(xiàn)數(shù)據(jù)的需要，往往還要添加各種冗余字段和計(jì)算字段。另外，PO對(duì)象通常使用事件與界面控件進(jìn)行交互，以通知界面控件刷新。在.net平臺(tái)上，一般使用DataSet、DataTable和DataRow對(duì)象作為PO對(duì)象（請(qǐng)參考.net framework類(lèi)庫(kù)的System.Data命名空間）。

VO:?全稱(chēng)為value?object，即值對(duì)象，是僅僅包含數(shù)據(jù)的一種對(duì)象。通常用于業(yè)務(wù)層之間的數(shù)據(jù)傳遞，從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)，以及將自身數(shù)據(jù)寫(xiě)入數(shù)據(jù)庫(kù)等。與數(shù)據(jù)庫(kù)表的設(shè)計(jì)有密切關(guān)系。VO又常常被稱(chēng)為“實(shí)體類(lèi)”或“數(shù)據(jù)實(shí)體”。

DO:?全稱(chēng)為data?access?object，即數(shù)據(jù)訪問(wèn)對(duì)象，此對(duì)象用于訪問(wèn)數(shù)據(jù)庫(kù)。通常和VO結(jié)合使用，DO中包含了各種數(shù)據(jù)庫(kù)的操作方法。通過(guò)它的方法，結(jié)合VO的數(shù)據(jù)對(duì)數(shù)據(jù)庫(kù)進(jìn)行相關(guān)的操作.。

BO：全稱(chēng)為business object，即業(yè)務(wù)邏輯處理對(duì)象。此對(duì)象用于處理具體的業(yè)務(wù)邏輯。通常，BO有一定的繼承層次，以提取一些公用的操作（如記錄日志等）。BO通常實(shí)現(xiàn)唯一接口，接收客戶(hù)端請(qǐng)求，調(diào)用DO更新數(shù)據(jù)，并以VO或VO集合的形式返回處理結(jié)果。

這三者分工不同，在簡(jiǎn)單的小系統(tǒng)里面，可能有時(shí)會(huì)重合。但在大一點(diǎn)的系統(tǒng)里面，三者分工明確系統(tǒng)可拓展性，可維護(hù)性的好處，遠(yuǎn)遠(yuǎn)超出了前期編寫(xiě)代碼時(shí)所付的代價(jià)。

?

1.4.? 數(shù)據(jù)存取技術(shù)

系統(tǒng)采用成熟的大型關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)作為數(shù)據(jù)存儲(chǔ)后端，同時(shí)使用基于面向?qū)ο笏枷氲木幊碳夹g(shù)。

由于關(guān)系型模型和面向?qū)ο竽Ｐ椭g存在結(jié)構(gòu)上的錯(cuò)配，因此需要采用ORM技術(shù)對(duì)數(shù)據(jù)在數(shù)據(jù)庫(kù)和中間層之間進(jìn)行轉(zhuǎn)換。iBatis是目前業(yè)界流行的一種ORM解決方案，其簡(jiǎn)單、靈活、可靠的特點(diǎn)使得其得到了廣泛應(yīng)用。

1.4.1.? ORM

對(duì)象關(guān)系映射（Object Relational Mapping，簡(jiǎn)稱(chēng)ORM）是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫(kù)存在的互不匹配的現(xiàn)象的技術(shù)。 簡(jiǎn)單的說(shuō)，ORM是通過(guò)使用描述對(duì)象和數(shù)據(jù)庫(kù)之間映射的元數(shù)據(jù)，將java/.net程序中的對(duì)象自動(dòng)持久化到關(guān)系數(shù)據(jù)庫(kù)中。

1.4.2.? iBatis

iBATIS是一個(gè)混合式的ORM解決方案（hybrid solution），借鑒了多種操作關(guān)系數(shù)據(jù)庫(kù)的方法的理念。

iBATIS的優(yōu)點(diǎn)：

l? 簡(jiǎn)單，學(xué)習(xí)成本低，容易掌握

l? 生產(chǎn)效率高，易于自動(dòng)化

l? 性能

l? 提供對(duì)數(shù)據(jù)庫(kù)連接池、數(shù)據(jù)緩存、事務(wù)的統(tǒng)一管理

l? 分工明確，程序員和DBA可以各司其職，分工合作

l? 官方同時(shí)提供對(duì)java和.net平臺(tái)的支持

1.4.3.? 代碼生成

代碼生成的概念：

通過(guò)指定若干輸入?yún)?shù)，使用特定的軟件工具，使得計(jì)算機(jī)能自動(dòng)地、批量地生成程序源代碼的過(guò)程。常用的代碼生成工具有“MyGeneration”、“CodeSmith”等。通常代碼生成工具都是基于模板和模板引擎技術(shù)，執(zhí)行時(shí)，使用動(dòng)態(tài)腳本語(yǔ)言根據(jù)輸入?yún)?shù)的不同，自動(dòng)替換模板中的某些部分，從而生成大量邏輯相似的源代碼。使用jsp或asp.net腳本技術(shù)，也可以很方便的制作適用于特定目的的小型代碼生成器。

?

為什么要使用代碼生成技術(shù)：

l? 代碼生成非常高效。因?yàn)橐坏┲谱骱昧撕线m的模板，設(shè)定了輸入?yún)?shù)，計(jì)算機(jī)可以在數(shù)秒內(nèi)生成數(shù)萬(wàn)至數(shù)十萬(wàn)行的源代碼，效率是人工編碼的成千上萬(wàn)倍。

l? 有利于代碼的標(biāo)準(zhǔn)化。通過(guò)合理規(guī)劃和制作模板，使得生成的源代碼的邏輯非常相似，代碼的結(jié)構(gòu)、接口、處理過(guò)程容易標(biāo)準(zhǔn)化、通用化。通過(guò)修改模板，便可以批量地升級(jí)所有的生成代碼。

l? 有利于提高代碼質(zhì)量。一方面，代碼的標(biāo)準(zhǔn)化使得性能調(diào)優(yōu)變得更加容易。另一方面，減少了由于人工編寫(xiě)而帶來(lái)的各種失誤。

l? 提高代碼適應(yīng)能力。比如數(shù)據(jù)庫(kù)字段的增減在項(xiàng)目開(kāi)發(fā)初期可能是比較頻繁的，如果由人工維護(hù)相應(yīng)的數(shù)據(jù)存取代碼，則非常容易錯(cuò)漏字段。通過(guò)使用代碼生成工具，只要輕輕點(diǎn)擊“重新生成”，便可使得代碼同步于外界環(huán)境的變化，減少了錯(cuò)誤發(fā)生的可能。

?

代碼生成的適用場(chǎng)合：

由于不存在“萬(wàn)能”的代碼模板，代碼生成一般適用于處理過(guò)程和處理邏輯比較標(biāo)準(zhǔn)的場(chǎng)合。通過(guò)使用基于iBatis的ORM框架，數(shù)據(jù)存取層的邏輯和編寫(xiě)過(guò)程變得容易標(biāo)準(zhǔn)化，從而使數(shù)據(jù)存取層的代碼生成成為可能。

本系統(tǒng)中，數(shù)據(jù)存取層的VO、DO及相關(guān)的iBatis XML映射文件將應(yīng)用代碼生成技術(shù)。

?

生成單表VO、DO：

這是最簡(jiǎn)單的情況，代碼生成器將為指定的表生成對(duì)應(yīng)的VO對(duì)象和DO對(duì)象。VO對(duì)象包含了數(shù)據(jù)庫(kù)表的所有字段，并且添加了必要的輔助字段和輔助方法。由于VO對(duì)象不包含業(yè)務(wù)邏輯處理，因此其所有數(shù)據(jù)域（Field）都是public的，目的是使代碼更精煉。DO對(duì)象提供了對(duì)關(guān)聯(lián)VO的四種基本操作：Select、Insert、Update、Delete。通過(guò)函數(shù)重載，為Select方法添加條件、分頁(yè)和排序的選項(xiàng)。

?

生成多表連接的VO、DO：

需要為此VO指定基本表。DO為基本表生成與單表VO類(lèi)似的四種基本操作。對(duì)于關(guān)聯(lián)的其他表，需要指定連接的類(lèi)型（join類(lèi)型）和外鍵，代碼生成器會(huì)生成含join關(guān)鍵字的聯(lián)合查詢(xún)SQL及對(duì)應(yīng)的SelectWith方法（With表示該查詢(xún)涉及多個(gè)表）。通過(guò)函數(shù)重載，為SelectWith添加條件、分頁(yè)和排序的選項(xiàng)。

?

條件檢索和條件刪除：

數(shù)據(jù)庫(kù)設(shè)計(jì)中，常常有物理主鍵和邏輯主鍵不完全一樣的情況。比如物理主鍵可能采用GUID，而邏輯主鍵可能是單據(jù)號(hào)，或者若干字段的組合。代碼生成器允許我們通過(guò)指定邏輯主鍵字段，生成相應(yīng)的SelectBy、DeleteBy方法族。在多表連接時(shí)，還將生成SelectWithBy方法族用于聯(lián)合檢索。

?

條件更新：

在需要進(jìn)行批量更新，或者需要使用邏輯主鍵進(jìn)行更新的場(chǎng)合，可以為代碼生成器指定條件字段（通常對(duì)應(yīng)于外鍵字段或邏輯主鍵字段），使其自動(dòng)生成UpdateBy方法族。

?

部分檢索：

通常，在制作查詢(xún)界面時(shí)，并不需要羅列所有的字段，只要顯示若干主要的字段即可。或者，一些說(shuō)明型或者二進(jìn)制型的復(fù)雜字段，不需要在查詢(xún)結(jié)果中顯示（通常是在單據(jù)界面顯示這些復(fù)雜字段）。這個(gè)時(shí)候，為了提高響應(yīng)速度和減小網(wǎng)絡(luò)流量，可以指定代碼生成器生成只檢索若干指定字段的查詢(xún)。代碼生成器將創(chuàng)建相應(yīng)的SQL語(yǔ)句，使得數(shù)據(jù)庫(kù)只返回選定的字段，從而優(yōu)化了性能。

?

部分更新：

在審核型的業(yè)務(wù)操作中，通常只對(duì)有限的幾個(gè)字段進(jìn)行更新：主鍵、狀態(tài)字段和時(shí)間戳。這時(shí)我們可以指定需要更新哪些字段，則代碼生成器將創(chuàng)建相應(yīng)的Update語(yǔ)句，使得只有指定的字段獲得更新，從而優(yōu)化了性能。

?

數(shù)據(jù)分頁(yè)：

在三層或多層架構(gòu)的軟件系統(tǒng)中，由于受客戶(hù)端到服務(wù)器的帶寬限制，數(shù)據(jù)分頁(yè)是很常見(jiàn)的一種操作，其目的是一次只返回“一頁(yè)”數(shù)據(jù)。通過(guò)在SQL語(yǔ)句中添加ROWNUM關(guān)鍵字，可以很容易地使分頁(yè)過(guò)程自動(dòng)化。

?

直接執(zhí)行動(dòng)態(tài)SQL：

在實(shí)際的業(yè)務(wù)處理中，總是存在有難以標(biāo)準(zhǔn)化處理的情況，因此在系統(tǒng)中添加了對(duì)直接執(zhí)行動(dòng)態(tài)SQL的支持。該動(dòng)態(tài)SQL可以是無(wú)返回值的（如Insert、Update或Delete操作，以及存儲(chǔ)過(guò)程調(diào)用），也可以是有返回值的（如Select操作）。返回值將以Hashtable（哈希表）結(jié)構(gòu)返回。

?

1.5.? 中間層

中間層即應(yīng)用服務(wù)層，部署于應(yīng)用服務(wù)器上。中間層的主要作用是：

l? 響應(yīng)客戶(hù)端請(qǐng)求，處理業(yè)務(wù)邏輯，返回響應(yīng)數(shù)據(jù)

l? 執(zhí)行數(shù)據(jù)庫(kù)存取操作

l? 通過(guò)部署Web Service，提供外系統(tǒng)接口

?

基于靈活性和可擴(kuò)展性考慮，中間層采用MVC和Front Controller設(shè)計(jì)模式。

1.5.1.? MVC模式:

MVC（Model-View-Controller）模式是目前大型多層應(yīng)用系統(tǒng)中主流的架構(gòu)模式。MVC模式基于用戶(hù)輸入將域的建模、顯示和操作分為三個(gè)獨(dú)立的類(lèi)：

l? 模型。模型用于管理應(yīng)用程序域的行為和數(shù)據(jù)，并響應(yīng)為獲取其狀態(tài)信息（通常來(lái)自視圖）而發(fā)出的請(qǐng)求，還會(huì)響應(yīng)更改狀態(tài)的指令（通常來(lái)自控制器）。在系統(tǒng)中，模型對(duì)應(yīng)PO和VO類(lèi)對(duì)象。模型部分需要在客戶(hù)端和中間層之間傳遞數(shù)據(jù)。

l? 視圖。視圖用于管理信息的顯示。在系統(tǒng)中，視圖部分部署在客戶(hù)端，對(duì)應(yīng)于.net WinForm 客戶(hù)端的各種窗體、控件。

l? 控制器。控制器用于解釋用戶(hù)的鼠標(biāo)和鍵盤(pán)輸入，以通知模型和/或視圖進(jìn)行相應(yīng)的更改。控制器部署在中間層，包括一個(gè)前端控制器對(duì)象和一系列處理具體業(yè)務(wù)邏輯的命令對(duì)象。

?

使用MVC模式的優(yōu)點(diǎn)：

l 同時(shí)支持多種客戶(hù)端。客戶(hù)端與中間層間使用XML進(jìn)行通訊，中間層無(wú)需關(guān)心客戶(hù)端是winform、webform還是PDA。

l 適應(yīng)更改。用戶(hù)界面要求的更改往往比業(yè)務(wù)規(guī)則快。將客戶(hù)端的邏輯與中間層相分離，使得界面更改不會(huì)影響到中間層和數(shù)據(jù)庫(kù)。

?

詳細(xì)技術(shù)資料，請(qǐng)參考“附件3：MVC模式”

1.5.2.? Front Controller（前端控制器）模式：

系統(tǒng)選擇Front Controller模式作為系統(tǒng)MVC架構(gòu)下的控制器結(jié)構(gòu)。

Front Controller 模式具有下列優(yōu)點(diǎn)：

l? 集中化控制。Front Controller 用于協(xié)調(diào)向 Web 應(yīng)用程序發(fā)出的所有請(qǐng)求，易于實(shí)施全應(yīng)用程序范圍的策略，如安全性和使用情況跟蹤。

l? 線程安全。控制器為每個(gè)請(qǐng)求創(chuàng)建新的命令對(duì)象（業(yè)務(wù)邏輯處理對(duì)象），從而避免了線程安全問(wèn)題。

l? 簡(jiǎn)化配置。只需要在 Web 服務(wù)器中配置一個(gè)前端控制器便可執(zhí)行各種調(diào)度。

?

詳細(xì)技術(shù)資料，請(qǐng)參考“附件4：Front Controller模式”

1.6.? 通訊技術(shù)

1.6.1.? 系統(tǒng)中各個(gè)模塊的通訊架構(gòu)：

?

1.6.2.? Web Service：

Web Service是基于HTTP通訊協(xié)議和XML技術(shù)的一套分布式應(yīng)用程序通訊框架。Web Service包含的主要技術(shù)有：

l? ?XML和XSD： 可擴(kuò)展的標(biāo)記語(yǔ)言XML 是Web Service平臺(tái)中表示數(shù)據(jù)的基本格式。除了易于建立和易于分析外，XML主要的優(yōu)點(diǎn)在于它既與平臺(tái)無(wú)關(guān)，又與廠商無(wú)關(guān)。XML是由萬(wàn)維網(wǎng)協(xié)會(huì) (W3C)創(chuàng)建，W3C制定的XML SchemaXSD 定義了一套標(biāo)準(zhǔn)的數(shù)據(jù)類(lèi)型，并給出了一種語(yǔ)言來(lái)擴(kuò)展這套數(shù)據(jù)類(lèi)型。Web Service平臺(tái)是用XSD來(lái)作為數(shù)據(jù)類(lèi)型系統(tǒng)的。當(dāng)你用某種語(yǔ)言如VB.NET或C# 來(lái)構(gòu)造一個(gè)Web Service時(shí)，為了符合Web Service標(biāo)準(zhǔn)，所有你使用的數(shù)據(jù)類(lèi)型都必須被轉(zhuǎn)換為XSD類(lèi)型。如想讓它使用在不同平臺(tái)和不同軟件的不同組織間傳遞，還需要用某種東西將它包裝起 來(lái)。這種東西就是一種協(xié)議，如 SOAP。

l? SOAP：SOAP即簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(Simple Object Access Protocol)，它是用于交換XML編碼信息的輕量級(jí)協(xié)議。它有三個(gè)主要方面：XML-envelope為描述信息內(nèi)容和如何處理內(nèi)容定義了框架，將 程序?qū)ο缶幋a成為XML對(duì)象的規(guī)則，執(zhí)行遠(yuǎn)程過(guò)程調(diào)用(RPC)的約定。

l? Web Service描述語(yǔ)言-WSDL。WSDL 就是用機(jī)器能閱讀的方式提供的一個(gè)正式描述文檔而基于XML的語(yǔ)言，用于描述Web Service及其函數(shù)、參數(shù)和返回值。因?yàn)槭腔赬ML的，所以WSDL既是機(jī)器可閱讀的，又是人可閱讀的。

l? UDDI：UDDI 的目的是為電子商務(wù)建立標(biāo)準(zhǔn)；UDDI是一套基于Web的、分布式的、為Web Service提供的、信息注冊(cè)中心的實(shí)現(xiàn)標(biāo)準(zhǔn)規(guī)范，同時(shí)也包含一組使企業(yè)能將自身提供的Web Service注冊(cè)，以使別的企業(yè)能夠發(fā)現(xiàn)的訪問(wèn)協(xié)議的實(shí)現(xiàn)標(biāo)準(zhǔn)。

l? 遠(yuǎn)程過(guò)程調(diào)用RPC與消息傳遞

?

1.6.3.? 對(duì)象序列化技術(shù)：

在面向?qū)ο笙到y(tǒng)中，數(shù)據(jù)的操作都是通過(guò)對(duì)象完成的。在分布式應(yīng)用中，需要通過(guò)對(duì)象序列化技術(shù)，將對(duì)象轉(zhuǎn)換為可以通過(guò)網(wǎng)絡(luò)傳遞的字節(jié)流，傳送到遠(yuǎn)端。遠(yuǎn)端使用反序列化技術(shù)，將網(wǎng)絡(luò)字節(jié)流還原為對(duì)象，完成數(shù)據(jù)傳遞。

通常的對(duì)象序列化技術(shù)有兩種：

1.??????? 二進(jìn)制序列化：以二進(jìn)制格式記錄對(duì)象的所有數(shù)據(jù)域的值。序列化的結(jié)果為字節(jié)數(shù)組。

2.??????? XML序列化：以XML文本的形式記錄對(duì)象的所有數(shù)據(jù)域的文本值。非字符串類(lèi)型的數(shù)據(jù)域?qū)⑿枰D(zhuǎn)換為對(duì)應(yīng)的文本。序列化的結(jié)果為字符串，在網(wǎng)絡(luò)上傳送的實(shí)際是該字符串對(duì)應(yīng)某個(gè)特定字符集（如GB2312）的字節(jié)流。

性能上二進(jìn)制序列化要高一些，但是受特定技術(shù)平臺(tái)的限制。XML序列化由于存在XML和文本解析的過(guò)程，性能要低一些，但是可以跨技術(shù)平臺(tái)使用，而且可讀性較好。

考慮到本系統(tǒng)需要跨越j(luò)ava和.net平臺(tái)，以及將來(lái)可能需要部署各種對(duì)外接口，基于標(biāo)準(zhǔn)化和統(tǒng)一化考慮，本系統(tǒng)決定采用XML序列化技術(shù)。

?

1.1. 附：ORM技術(shù)

對(duì)象關(guān)系映射（Object Relational Mapping，簡(jiǎn)稱(chēng)ORM）是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫(kù)存在的互不匹配的現(xiàn)象的技術(shù)。 簡(jiǎn)單的說(shuō)，ORM是通過(guò)使用描述對(duì)象和數(shù)據(jù)庫(kù)之間映射的元數(shù)據(jù)，將java程序中的對(duì)象自動(dòng)持久化到關(guān)系數(shù)據(jù)庫(kù)中。本質(zhì)上就是將數(shù)據(jù)從一種形式轉(zhuǎn)換到另外一種形式。 這也同時(shí)暗示著額外的執(zhí)行開(kāi)銷(xiāo)；然而，如果ORM作為一種中間件實(shí)現(xiàn)，則會(huì)有很多機(jī)會(huì)做優(yōu)化，而這些在手寫(xiě)的持久層并不存在。 更重要的是用于控制轉(zhuǎn)換的元數(shù)據(jù)需要提供和管理；但是同樣，這些花費(fèi)要比維護(hù)手寫(xiě)的方案要少；而且就算是遵守ODMG規(guī)范的對(duì)象數(shù)據(jù)庫(kù)依然需要類(lèi)級(jí)別的元數(shù)據(jù)。

?對(duì)象-關(guān)系映射，是隨著面向?qū)ο蟮能浖_(kāi)發(fā)方法發(fā)展而產(chǎn)生的。面向?qū)ο蟮拈_(kāi)發(fā)方法是當(dāng)今企業(yè)級(jí)應(yīng)用開(kāi)發(fā)環(huán)境中的主流開(kāi)發(fā)方法，關(guān)系數(shù)據(jù)庫(kù)是企業(yè)級(jí)應(yīng)用環(huán)境中永久存放數(shù)據(jù)的主流數(shù)據(jù)存儲(chǔ)系統(tǒng)。對(duì)象和關(guān)系數(shù)據(jù)是業(yè)務(wù)實(shí)體的兩種表現(xiàn)形式，業(yè)務(wù)實(shí)體在內(nèi)存中表現(xiàn)為對(duì)象，在數(shù)據(jù)庫(kù)中表現(xiàn)為關(guān)系數(shù)據(jù)。內(nèi)存中的對(duì)象之間存在關(guān)聯(lián)和繼承關(guān)系，而在數(shù)據(jù)庫(kù)中，關(guān)系數(shù)據(jù)無(wú)法直接表達(dá)多對(duì)多關(guān)聯(lián)和繼承關(guān)系。因此，對(duì)象-關(guān)系映射(ORM)系統(tǒng)一般以中間件的形式存在，主要實(shí)現(xiàn)程序?qū)ο蟮疥P(guān)系數(shù)據(jù)庫(kù)數(shù)據(jù)的映射。

面向?qū)ο笫菑能浖こ袒驹瓌t(如耦合、聚合、封裝)的基礎(chǔ)上發(fā)展起來(lái)的，而關(guān)系數(shù)據(jù)庫(kù)則是從數(shù)學(xué)理論發(fā)展而來(lái)的，兩套理論存在顯著的區(qū)別。為了解決這個(gè)不匹配的現(xiàn)象,對(duì)象關(guān)系映射技術(shù)應(yīng)運(yùn)而生。

讓我們從O/R開(kāi)始。字母O起源于"對(duì)象"(Object),而R則來(lái)自于"關(guān)系"(Relational)。幾乎所有的程序里面，都存在對(duì)象和關(guān)系數(shù)據(jù)庫(kù)。在業(yè)務(wù)邏輯層和用戶(hù)界面層中，我們是面向?qū)ο蟮摹．?dāng)對(duì)象信息發(fā)生變化的時(shí)候，我們需要把對(duì)象的信息保存在關(guān)系數(shù)據(jù)庫(kù)中。

當(dāng)你開(kāi)發(fā)一個(gè)應(yīng)用程序的時(shí)候(不使用O/R Mapping),你可能會(huì)寫(xiě)不少數(shù)據(jù)訪問(wèn)層的代碼，用來(lái)從數(shù)據(jù)庫(kù)保存，刪除，讀取對(duì)象信息，等等。你在DAL中寫(xiě)了很多的方法來(lái)讀取對(duì)象數(shù)據(jù)，改變狀態(tài)對(duì)象等等任務(wù)。而這些代碼寫(xiě)起來(lái)總是重復(fù)的。

對(duì)象關(guān)系映射成功運(yùn)用在不同的面向?qū)ο蟪志脤赢a(chǎn)品中，如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。

一般的ORM包括以下四部分：

一個(gè)對(duì)持久類(lèi)對(duì)象進(jìn)行CRUD操作的API；

一個(gè)語(yǔ)言或API用來(lái)規(guī)定與類(lèi)和類(lèi)屬性相關(guān)的查詢(xún)；

一個(gè)規(guī)定mapping metadata的工具；

一種技術(shù)可以讓ORM的實(shí)現(xiàn)同事務(wù)對(duì)象一起進(jìn)行dirty checking, lazy association fetching以及其他的優(yōu)化操作。

總結(jié)

以上是生活随笔為你收集整理的三层CS技术方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。