1、基于面向?qū)ο笏枷肜肳eb Service開發(fā)三層體系結(jié)構(gòu)的某市規(guī)劃信息管理系統(tǒng)(畢業(yè)設(shè)計(jì)初稿)作者：周文    厚樸教育來源：本站原創(chuàng)    點(diǎn)擊數(shù)：1925    更新時(shí)間：2009-4-2摘要：介紹基于軟件工程的面向?qū)ο笏枷耄脀eb service技術(shù)，開發(fā)具有三層體系結(jié)構(gòu)的規(guī)劃信息管理系統(tǒng)的過程，突出此系統(tǒng)具有的高可維護(hù)性、高重用性、高靈活性、高擴(kuò)展性等特性，并對(duì)系統(tǒng)實(shí)現(xiàn)的關(guān)鍵技術(shù)進(jìn)行深入研究，最后總結(jié)此種軟件開發(fā)模式的利弊。關(guān)鍵字：Web Servic

2、e、面向?qū)ο?、三層架?gòu)、規(guī)劃信息管理系統(tǒng)、面向?qū)ο竽Ｐ突夹g(shù)中圖分類號(hào): TP393 文獻(xiàn)標(biāo)識(shí)碼:A 引言：隨著時(shí)代的發(fā)展，軟件開發(fā)在生產(chǎn)效率、可靠性、靈活性、可擴(kuò)展性、易維護(hù)性、易管理等方面提出了更高要求，為了迎接日趨復(fù)雜的軟件需求的挑戰(zhàn)，新的軟件工程思想和方法層出不窮，尤其是面向?qū)ο笏枷?、分層式軟件體系架構(gòu)的出現(xiàn)，極大地改變了傳統(tǒng)軟件的開發(fā)模式，大大提高了軟件的開發(fā)效率?；ヂ?lián)網(wǎng)迅猛發(fā)展，大量異構(gòu)程序和不同平臺(tái)之間的互操作性要求越來越強(qiáng)烈。Web Service應(yīng)運(yùn)而生，它使原來各孤立的站點(diǎn)之間的信息能夠更加方便的相互通信和共享。順應(yīng)時(shí)代技術(shù)潮流，集眾家之所長，作者于是基于軟件工程

3、的面向?qū)ο笏枷?，利用web service技術(shù)，開發(fā)具有三層體系結(jié)構(gòu)的某市規(guī)劃信息管理系統(tǒng)。 正文：1.  面向?qū)ο蠛喗?.1面向?qū)ο笏枷?、方法和技術(shù)面向?qū)ο笏枷氲某霭l(fā)點(diǎn)是盡可能模擬人類習(xí)慣的思維方式, 使開發(fā)軟件的方法與過程盡可能接近人類認(rèn)識(shí)世界、解決問題的方法與過程。面向?qū)ο箝_發(fā)方法主要有三個(gè)，分別是Booch方法、Cord方法和OMT方法。本系統(tǒng)采用OMT方法進(jìn)行開發(fā)。此方法將面向?qū)ο蟮母拍顟?yīng)用于軟件生存周期的各個(gè)階段，并說明了如何在軟件開發(fā)的整個(gè)生存周期中貫穿運(yùn)用面向?qū)ο蟮母拍睢⒎椒ê图夹g(shù)進(jìn)行分析、設(shè)計(jì)和實(shí)現(xiàn)。面向?qū)ο蠹夹g(shù)包括面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計(jì)及面向?qū)ο蟪绦?/p>

4、設(shè)計(jì)三部分內(nèi)容：（1）     面向?qū)ο蠓治觯褐杠浖枨蠓治龅囊环N帶有約束性的方法，用于軟件開發(fā)過程中的問題定義階段。其主要活動(dòng)是對(duì)問題進(jìn)行抽象建模（包括使用實(shí)例建模、類和對(duì)象建模、組件建模和分布建模等），產(chǎn)生一種描述系統(tǒng)功能和問題論域基本特征的綜合文檔。（2）     面向?qū)ο笤O(shè)計(jì)：將面向?qū)ο蠓治鏊鶆?chuàng)建的分析模型轉(zhuǎn)變?yōu)樽鳛檐浖?gòu)造藍(lán)圖的設(shè)計(jì)模型。面向?qū)ο笤O(shè)計(jì)的獨(dú)特性，在于其具有基于抽象、信息隱蔽、功能獨(dú)立性和模塊性建造系統(tǒng)等四個(gè)重要軟件設(shè)計(jì)概念的能力。（3）     面向?qū)?/p>

5、象程序設(shè)計(jì)：指使用類和對(duì)象以及面向?qū)ο筇赜械母拍钸M(jìn)行編程。概括的說，面向?qū)ο笫且环N運(yùn)用對(duì)象、類、繼承、封裝、聚合、消息傳遞、多態(tài)性等概念來構(gòu)造系統(tǒng)的軟件開發(fā)方法。它打破了傳統(tǒng)的代碼、數(shù)據(jù)分離做法, 將一種數(shù)據(jù)結(jié)構(gòu)和操作該數(shù)據(jù)結(jié)構(gòu)的方法捆綁在一起, 封裝在一個(gè)對(duì)象內(nèi), 實(shí)現(xiàn)了數(shù)據(jù)封裝和信息隱藏, 通過對(duì)象的對(duì)外接口實(shí)現(xiàn)信息傳遞, 使數(shù)據(jù)封裝、信息隱藏、抽象代碼共享等軟件工程思想得到充分體現(xiàn)。1.2面向?qū)ο蟮膬?yōu)缺點(diǎn)在計(jì)算機(jī)系統(tǒng)開發(fā)領(lǐng)域中存在各種各樣的系統(tǒng)分析和設(shè)計(jì)方法, 其中結(jié)構(gòu)化方法與面向?qū)ο蠓椒ㄊ擒浖_發(fā)程序設(shè)計(jì)中的2個(gè)主流思想。結(jié)構(gòu)化方法程序設(shè)計(jì)的基本思想是: 自頂向下, 采用模塊化技術(shù),

6、分而治之, 逐步求精地將信息系統(tǒng)按功能分解為若干模塊進(jìn)行分析與設(shè)計(jì), 應(yīng)用子程序?qū)崿F(xiàn)模塊化, 模塊內(nèi)部由順序結(jié)構(gòu)、選擇結(jié)構(gòu)、循環(huán)結(jié)構(gòu)等三大基本控制結(jié)構(gòu)組成。結(jié)構(gòu)化方法的局限:1)不能直接反映問題域: 結(jié)構(gòu)化分析方法以數(shù)據(jù)流為中心, 強(qiáng)調(diào)數(shù)據(jù)的流動(dòng)及每一個(gè)處理過程, 不是以問題域中的各事物為基礎(chǔ), 打破了各事物的界限, 分析結(jié)果不能直接反映問題域, 容易隱蔽一些對(duì)問題域的理解偏差。2)數(shù)據(jù)和代碼缺乏保護(hù)機(jī)制: 一個(gè)特定全程數(shù)據(jù)既可以被操作這些數(shù)據(jù)的過程訪問, 也可以被其他過程訪問, 這給程序設(shè)計(jì)帶來了不安定因素, 一個(gè)不正常的數(shù)據(jù)修改或者過程調(diào)用可能會(huì)破壞正常的程序執(zhí)行流程或結(jié)果。3)分析和設(shè)計(jì)

7、體系不一: 結(jié)構(gòu)化分析的結(jié)果是數(shù)據(jù)流圖, 結(jié)構(gòu)化設(shè)計(jì)的結(jié)果是模塊結(jié)構(gòu)圖。二者的表示體系不一致, 分析文檔很難與設(shè)計(jì)文檔對(duì)應(yīng), 所以從分析到設(shè)計(jì)的“轉(zhuǎn)換”過程容易因理解上的錯(cuò)誤而使得設(shè)計(jì)文檔與用戶的原本需求相差甚遠(yuǎn)。4)開發(fā)過程復(fù)雜: 由于結(jié)構(gòu)化方法將過程和數(shù)據(jù)分離為相互獨(dú)立的實(shí)體, 程序員在編程時(shí)必須時(shí)刻考慮到所要處理的數(shù)據(jù)的格式。對(duì)于不同的數(shù)據(jù)格式做相同的處理或?qū)τ谙嗤臄?shù)據(jù)格式做不同的處理都需要編寫不同的程序, 而且往往不能對(duì)數(shù)據(jù)的安全性進(jìn)行有效的控制。如果程序進(jìn)行擴(kuò)充或升級(jí), 也需要大量修改函數(shù), 因此結(jié)構(gòu)化程序的可重用性不好。面向?qū)ο蠓椒ㄅc傳統(tǒng)的結(jié)構(gòu)化方法比較，有如下獨(dú)到之處:（1）&

8、#160;    可重用性。通過類的繼承關(guān)系, 使公共的特性能夠共享, 簡化了對(duì)象、類的創(chuàng)建工作量, 增加了代碼的可重性。另外, 重用經(jīng)過測(cè)試的代碼還可以使產(chǎn)生額外錯(cuò)誤的可能性達(dá)到最小，增強(qiáng)了系統(tǒng)的可靠性。（2）     可擴(kuò)展性。類的繼承性使類能夠反映現(xiàn)實(shí)世界的層次結(jié)構(gòu), 多態(tài)性反映了現(xiàn)實(shí)世界的復(fù)雜多樣。類的繼承性和多態(tài)性使軟件編碼具有良好的可重用性和可擴(kuò)展性。無需修改源代碼就可以使軟件功能容易擴(kuò)充和修改。（3）     數(shù)據(jù)保護(hù)。將一種數(shù)據(jù)結(jié)構(gòu)和操作該數(shù)據(jù)結(jié)構(gòu)的方法捆綁在一起, 封

9、裝在一個(gè)對(duì)象內(nèi), 實(shí)現(xiàn)了數(shù)據(jù)封裝和信息隱藏, 通過對(duì)象的對(duì)外接口實(shí)現(xiàn)信息傳遞。封裝防止了程序相互依賴性而帶來的變動(dòng)影響。（4）     可管理性。面向?qū)ο蟮拈_發(fā)方法采用類作為構(gòu)建系統(tǒng)的部件, 以對(duì)象作為系統(tǒng)的基本組成單元, 使整個(gè)項(xiàng)目的組織更加合理、方便。歸納事物、劃分成類進(jìn)行管理，符合人們認(rèn)識(shí)和管理客觀世界的習(xí)慣思維方式。當(dāng)然，面向?qū)ο笠泊嬖谝恍┤秉c(diǎn)：由于面向更高的邏輯抽象層，不得不做出性能上面的犧牲，導(dǎo)致代碼執(zhí)行效率較低。因此，在對(duì)性能要求不是很高的情況下，應(yīng)用面向?qū)ο蠓椒ㄟM(jìn)行系統(tǒng)開發(fā)，是一種極好的選擇。2.  web service技術(shù)簡

10、介2.1 web service的定義 web Service 技術(shù)是一種面向服務(wù)架構(gòu)的技術(shù)，通過標(biāo)準(zhǔn)的Web協(xié)議提供服務(wù)，目的是保證運(yùn)行在不同平臺(tái)上的應(yīng)用服務(wù)可以互操作。是一個(gè)用來發(fā)布和搜索WEB服務(wù)的協(xié)議，應(yīng)用程序可通過此協(xié)議在設(shè)計(jì)或運(yùn)行時(shí)找到目標(biāo)WEB服務(wù)。SOAP (Simple Object Access Protocal，簡單對(duì)象訪問協(xié)議)是一個(gè)基于XML的可擴(kuò)展消息信封格式，需同時(shí)綁定一個(gè)傳輸用協(xié)議。這個(gè)協(xié)議通常是HTTP 或 HTTPS，但也可能是SMTP 或XMPP。WSDL是一個(gè)XML格式文檔，用以描述服務(wù)端口訪問方式和使用協(xié)議的細(xì)節(jié)，通常用來輔助生成服務(wù)器和客戶端代碼及配

11、置信息。web Service 技術(shù)是構(gòu)建松散耦合的、可復(fù)用的軟件模塊, 自包含的、自描述的、模塊化的應(yīng)用程序的利刃。開發(fā)出的應(yīng)用程序可以通過Web來發(fā)布、定位和調(diào)用。Web Service 代表新一代的軟件架構(gòu)模式, 即通過互聯(lián)網(wǎng)架構(gòu)應(yīng)用軟件, 充分體現(xiàn)服務(wù)即軟件(Software as a Service)等軟件工程思想。2.2 web service 技術(shù)的優(yōu)缺點(diǎn)Web service 技術(shù)的優(yōu)點(diǎn)： （1）     跨平臺(tái)的可互操作性。Web Service 完全基于XML、XSD（XML Schema）等獨(dú)立于平臺(tái)、獨(dú)立于軟件供應(yīng)商的標(biāo)準(zhǔn)，是創(chuàng)建

12、可互操作的、分布式應(yīng)用程序的新平臺(tái)。（2）     跨防火墻的通信。由于Web Service使用了SOAP協(xié)議，數(shù)據(jù)是以ASCII文本的方式而非二進(jìn)制傳輸，可以無障礙地通過防火墻。（3）     應(yīng)用程序集成、軟件和數(shù)據(jù)重用。通過Web Service，應(yīng)用程序可以用標(biāo)準(zhǔn)的方法把功能和數(shù)據(jù)“暴露”出來，供其它不同語言寫成的、在不同平臺(tái)上運(yùn)行的各種程序使用。（4）     實(shí)現(xiàn)難度小。Web Service技術(shù)的實(shí)現(xiàn)難度要比CORBA和DCOM小得多。Web service

13、技術(shù)的缺點(diǎn)：（1）    Web Service使用XML對(duì)數(shù)據(jù)封裝，會(huì)造成大量的數(shù)據(jù)在網(wǎng)絡(luò)中傳輸。3.  三層體系結(jié)構(gòu)的介紹3.1三層體系結(jié)構(gòu)的定義在軟件體系架構(gòu)設(shè)計(jì)中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層、表示層，如圖所示：圖一：三層的分層式結(jié)構(gòu)數(shù)據(jù)訪問層：其功能主要是負(fù)責(zé)訪問數(shù)據(jù)庫，即實(shí)現(xiàn)對(duì)數(shù)據(jù)表的Select、Insert、Update、Delete的操作。如果使用對(duì)象關(guān)系映射（Object Relational Mapping，ORM）技術(shù)，那么就會(huì)包括對(duì)象和數(shù)據(jù)表之

14、間的mapping，以及對(duì)象實(shí)體的持久化。業(yè)務(wù)邏輯層：是整個(gè)系統(tǒng)的核心，它與這個(gè)系統(tǒng)的業(yè)務(wù)（領(lǐng)域）有關(guān)。以規(guī)劃信息系統(tǒng)為例，業(yè)務(wù)邏輯層的相關(guān)設(shè)計(jì)，均和規(guī)劃信息系統(tǒng)特有的邏輯緊密相關(guān)，例如查詢規(guī)劃圖的信息，下載規(guī)劃圖，添加規(guī)劃圖等等。如果涉及到對(duì)數(shù)據(jù)庫的訪問，則調(diào)用數(shù)據(jù)訪問層。表示層：是系統(tǒng)的UI部分，負(fù)責(zé)使用者與整個(gè)系統(tǒng)的交互。在這一層中，理想的狀態(tài)是不應(yīng)包括系統(tǒng)的業(yè)務(wù)邏輯，即表示層中的邏輯代碼，僅與界面元素有關(guān)。3.2三層體系結(jié)構(gòu)的優(yōu)缺點(diǎn)分層式結(jié)構(gòu)究竟其優(yōu)勢(shì)何在？Martin Fowler在Patterns of Enterprise Application Architecture一書中給

15、出了答案：（1）    開發(fā)人員可以只關(guān)注整個(gè)結(jié)構(gòu)中的其中某一層；（2）    可以很容易的用新的實(shí)現(xiàn)來替換原有層次的實(shí)現(xiàn)；（3）    可以降低層與層之間的依賴；（4）    有利于標(biāo)準(zhǔn)化；（5）    利于各層邏輯的復(fù)用。概括來說，分層式設(shè)計(jì)可以達(dá)至如下目的：分散關(guān)注、松散耦合、邏輯復(fù)用、標(biāo)準(zhǔn)定義。此三層體系結(jié)構(gòu)，可以使開發(fā)人員的分工更加明確。一旦定義好各層次之間的接口，負(fù)責(zé)不同邏輯設(shè)計(jì)的開發(fā)人員就可以分散關(guān)注，齊頭并進(jìn)。即UI人員只需考慮用

16、戶界面的體驗(yàn)與操作，領(lǐng)域的設(shè)計(jì)人員僅關(guān)注業(yè)務(wù)邏輯的設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)人員也只需關(guān)注數(shù)據(jù)訪問層的設(shè)計(jì)。開發(fā)效率可想而知，非常之高。松散耦合的好處也是顯而易見的。如果一個(gè)系統(tǒng)沒有分層，那么各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發(fā)生改變，則牽一發(fā)而動(dòng)全身，對(duì)項(xiàng)目的影響極為嚴(yán)重。降低層與層間的依賴性，既可以保證系統(tǒng)未來良好的可擴(kuò)展，又可以保證代碼的高復(fù)用性。每個(gè)功能模塊一旦定義好統(tǒng)一的接口，就可以被各個(gè)模塊所調(diào)用，而不用為相同的功能進(jìn)行重復(fù)地開發(fā)。接口的標(biāo)準(zhǔn)化也保證了層與層之間的良好通信?！敖馃o足赤，人無完人”，分層式結(jié)構(gòu)也不可避免具有一些缺陷：1)  

17、降低了系統(tǒng)的性能。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接訪問數(shù)據(jù)庫，直接獲取相應(yīng)的數(shù)據(jù)，不必通過中間層來完成。2)   有時(shí)會(huì)導(dǎo)致級(jí)聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個(gè)功能，為保證其設(shè)計(jì)符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼。4.  規(guī)劃信息管理系統(tǒng)的功能設(shè)計(jì)及體系結(jié)構(gòu)設(shè)計(jì)4.1系統(tǒng)功能設(shè)計(jì)圖二：系統(tǒng)功能結(jié)構(gòu)圖由圖二可知，規(guī)劃信息管理系統(tǒng)由三大模塊組成，即修規(guī)圖管理模塊、地形圖管理模塊、用戶管理模塊。使用面向?qū)ο竽Ｐ突夹g(shù)(Object Modeling Technique,簡寫為OMT)對(duì)此系統(tǒng)

18、進(jìn)行開發(fā)。OMT以面向?qū)ο笏枷霝榛A(chǔ)，通過構(gòu)造一組相關(guān)模型（對(duì)象模型、動(dòng)態(tài)模型和功能模型）來獲得關(guān)于此系統(tǒng)的全面認(rèn)識(shí)。下面以規(guī)劃信息管理系統(tǒng)中的修規(guī)圖模塊的開發(fā)為例進(jìn)行說明。(為了方便闡述，已經(jīng)大大簡化了真實(shí)系統(tǒng)模型) 4.1.1對(duì)象模型對(duì)象模型描述系統(tǒng)中對(duì)象的靜態(tài)結(jié)構(gòu)、對(duì)象之間的關(guān)系、對(duì)象的屬性、對(duì)象的操作。對(duì)象模型一般包括對(duì)象模型圖和數(shù)據(jù)字典。通過對(duì)修規(guī)圖模塊的功能和業(yè)務(wù)流進(jìn)行分析，可以得到以下模型： 圖三：修規(guī)圖對(duì)象類圖如圖三所示，XiuGuiMapInfo類表示的是修規(guī)圖對(duì)象。其中屬性FID是每一張修規(guī)圖的唯一標(biāo)識(shí)符，屬性FileNO表示修規(guī)圖的圖文號(hào)，屬性RightNo表示的是修規(guī)圖

19、的許可證號(hào)，屬性Url記錄的是修規(guī)圖CAD文件在服務(wù)器上面的存放路徑。根據(jù)實(shí)體類可以獲得相應(yīng)的數(shù)據(jù)表XiuGuiMapInfor（圖四），用于存放每張修規(guī)圖的描述信息，其中FID為主鍵： 圖四：數(shù)據(jù)表XiuGuiMapInfor4.1.2動(dòng)態(tài)模型動(dòng)態(tài)模型描述與時(shí)間和操作順序有關(guān)的系統(tǒng)特征，包括激發(fā)事件、事件序列、確定事件先后關(guān)系以及事件和狀態(tài)的組織。此處知識(shí)點(diǎn)較多，有興趣的讀者可以作進(jìn)一步的研究。4.1.3功能模型功能模型描述與值的變換有關(guān)的系統(tǒng)特征，包括功能、映射、約束和函數(shù)依賴。功能模型一般用數(shù)據(jù)流圖來表示。以“添加修規(guī)圖”功能模型為例，進(jìn)行說明，如圖五所示。 圖五：“

20、添加修規(guī)圖”功能模型4.2系統(tǒng)運(yùn)行原理 圖六：規(guī)劃信息管理系統(tǒng)運(yùn)行原理系統(tǒng)運(yùn)行原理：如圖六所示，在客戶端（Client）聲明一個(gè)代理類(Proxy Class)，客戶端通過此代理類與Web Server服務(wù)器進(jìn)行Request 和Response .當(dāng)CAD文件或者是CAD文件的描述信息也或是相關(guān)操作命令，被封裝成SOAP格式的數(shù)據(jù)流發(fā)送到服務(wù)器端的時(shí)候，服務(wù)器端生成一個(gè)進(jìn)程對(duì)象，接收這個(gè)Request的SOAP包進(jìn)行解析處理，然后把解析的結(jié)果傳給web service進(jìn)行處理，web service在處理的過程中會(huì)根據(jù)需要，與Oracle/MSSQL DB、File Store D

21、irectory聯(lián)系。處理結(jié)束以后，把處理結(jié)果進(jìn)行SOAP包裝，作為一個(gè)Response發(fā)送給客戶端的代理類，然后此代理類對(duì)這個(gè)SOAP包進(jìn)行解析處理。注：修規(guī)圖和地形圖的文件格式為CAD。Oracle/MSSQL DB是存儲(chǔ)CAD文件描述信息的，F(xiàn)ile Store Directory是用來存放CAD文件的。4.3規(guī)劃信息管理系統(tǒng)體系結(jié)構(gòu)設(shè)計(jì) 圖七：規(guī)劃信息管理系統(tǒng)三層體系結(jié)構(gòu)圖如圖七所示，在數(shù)據(jù)訪問層（DAL）中，采用Interface抽象出數(shù)據(jù)訪問邏輯，并以DAL Factory作為數(shù)據(jù)訪問層的對(duì)象的工廠模式。對(duì)于Interface而言，分別有支持MSSQL的SQL Serve

22、r DAL和支持Oracle 10g的Oracle DAL具體實(shí)現(xiàn)。而對(duì)象模型(Model Object)則包含了數(shù)據(jù)實(shí)體對(duì)象（例如修規(guī)圖對(duì)象XiuGuiMapInfo）。數(shù)據(jù)訪問層的模塊結(jié)構(gòu)如圖八所示： 圖八：數(shù)據(jù)訪問層的模塊結(jié)構(gòu)圖圖八中可以看到，在數(shù)據(jù)訪問層中，完全采用了“面向接口編程”思想。抽象出來的IDAL模塊，脫離了與具體數(shù)據(jù)庫的依賴，從而使得整個(gè)數(shù)據(jù)訪問層能夠很好地支持?jǐn)?shù)據(jù)庫的遷移。DALFactory模塊專門管理DAL對(duì)象的創(chuàng)建，便于業(yè)務(wù)邏輯層訪問。SQLServerDAL和OracleDAL模塊均實(shí)現(xiàn)IDAL模塊的接口，其中包含的邏輯就是對(duì)數(shù)據(jù)庫的Select，Ins

23、ert，Update和Delete操作。因?yàn)閿?shù)據(jù)庫類型的不同，對(duì)數(shù)據(jù)庫的操作也有所不同，代碼也會(huì)因此有所區(qū)別。此外，抽象出來的IDAL模塊，除了解除了向下的依賴之外，對(duì)于其上的業(yè)務(wù)邏輯層，同樣僅存在弱依賴關(guān)系，如圖九所示： 圖九：業(yè)務(wù)邏輯層的模塊結(jié)構(gòu)圖圖九中，BLL是業(yè)務(wù)邏輯層的核心模塊，它包含了整個(gè)系統(tǒng)的核心業(yè)務(wù)。在業(yè)務(wù)邏輯層中，不能直接訪問數(shù)據(jù)庫，而必須通過數(shù)據(jù)訪問層。注意圖中對(duì)數(shù)據(jù)訪問業(yè)務(wù)的調(diào)用，是通過接口模塊IDAL來完成的。既然與具體的數(shù)據(jù)訪問邏輯無關(guān)，則層與層之間的關(guān)系就是松散耦合的。如果此時(shí)需要修改數(shù)據(jù)訪問層的具體實(shí)現(xiàn)，只要不涉及到IDAL的接口定義，那么業(yè)務(wù)邏輯層就不

24、會(huì)受到任何影響。 圖十：表示層的模塊結(jié)構(gòu)圖由于此系統(tǒng)業(yè)務(wù)邏輯相對(duì)簡單，所以將核心的業(yè)務(wù)邏輯都放到了一個(gè)模塊BLL中，并沒有將具體的實(shí)現(xiàn)和抽象嚴(yán)格的按照模塊分開。所以web service表示層和業(yè)務(wù)邏輯層之間的調(diào)用關(guān)系，其耦合度相對(duì)較高。5.  規(guī)劃信息管理系統(tǒng)的具體實(shí)現(xiàn)此系統(tǒng)在visual studio2005平臺(tái)上，采用C#,SQL2005/Oracle10g進(jìn)行開發(fā)。 圖十一：系統(tǒng)在visual studio2005中的解決方案從下表（表一）可以知道圖十一中規(guī)劃信息管理系統(tǒng)在開發(fā)平臺(tái)上面的所有項(xiàng)目的基本描述，即各項(xiàng)目在系統(tǒng)的三層體系結(jié)構(gòu)中扮演的角色。序號(hào)項(xiàng)目

25、名稱基本描述1WebSite表示層2Client表示層3WebService表示層4BLL業(yè)務(wù)邏輯層5IDAL數(shù)據(jù)訪問層接口定義6DALFactory數(shù)據(jù)層的抽象工廠7OracleDALOracle數(shù)據(jù)訪問層8SQLServerDALSQLServer數(shù)據(jù)訪問層9DBUtility數(shù)據(jù)訪問類組件10CheckUtility常用驗(yàn)證、加密函數(shù)基礎(chǔ)類11Model業(yè)務(wù)實(shí)體表一：開發(fā)平臺(tái)中系統(tǒng)各項(xiàng)目在系統(tǒng)的三層體系結(jié)構(gòu)中扮演的角色5.1系統(tǒng)服務(wù)器端的實(shí)現(xiàn)5.1.1涉及的項(xiàng)目名稱及描述：(實(shí)現(xiàn)步驟為：4-3-7-6-5-2-1)（1）   Web Service/ WebSite/

26、 Client表示層（2）   BLL業(yè)務(wù)邏輯層（3）   IDAL數(shù)據(jù)訪問層接口定義（4）   Model業(yè)務(wù)實(shí)體（5）   DALFactory數(shù)據(jù)層的抽象工廠(創(chuàng)建反射)（6）   SQLServerDALSQLServer數(shù)據(jù)訪問層 / OracleDALOracle數(shù)據(jù)訪問層（7）   DBUtility 數(shù)據(jù)庫訪問組件基礎(chǔ)類CheckUtility 常用驗(yàn)證、加密函數(shù)基礎(chǔ)類5.1.2項(xiàng)目引用關(guān)系（依賴關(guān)系）（1）Web Service引用 BLL。（2）BLL 引

27、用 IDAL，Model，使用DALFactory創(chuàng)建實(shí)例。（3）IDAL 引用 Model。（4）Model 無引用。（5）DALFactory 引用IDAL，通過讀取web.config里設(shè)置的程序集，加載類的實(shí)例，返回給BLL使用。（6）SQLServerDAL 引用 Model、IDAL、CheckUtility和DBUtility，被DALFactory加載的程序集，實(shí)現(xiàn)接口里的方法。 5.1.3實(shí)現(xiàn)步驟（以修規(guī)圖管理模塊開發(fā)為例）(1) 創(chuàng)建Model項(xiàng)目：實(shí)現(xiàn)業(yè)務(wù)實(shí)體。如圖三所示，類XiuGuiMapInfo表示的是修規(guī)圖對(duì)象。(2)創(chuàng)建IDAL項(xiàng)目：實(shí)現(xiàn)接口。 圖十二

28、：IDAL中IXiuGuiMap接口類圖如圖十二所示，IXiuGuiMap接口所包含的方法和方法的基本描述如下： /添加一張修規(guī)圖的信息 bool AddXiuGuiMap(XiuGuiMapInfo map); /刪除某特定修規(guī)圖的信息 bool deleteXiuGuiMap(int FID);/查詢功能 獲得符合搜索條件的所有修規(guī)圖的信息 IList<XiuGuiMapInfo>GetSearchXiuGuiMap(string SearchWord);/查詢功能 獲得數(shù)據(jù)庫中所有修規(guī)圖的信息 IList<XiuGuiMapInfo> GetAllXiuGuiMa

29、p();/查詢功能 獲得某特定修規(guī)圖的信息 XiuGuiMapInfo GetXiuGuiMap(int FID); /下載某特定修規(guī)圖的CAD文件byte GetXiuGuiMapCAD(int FID);/更新某特定修規(guī)圖的信息bool UpdateXiuGuiMap(XiuGuiMapInfo map);(3)創(chuàng)建SQLServerDAL/OracleDAL項(xiàng)目：實(shí)現(xiàn)接口里的方法（需要調(diào)用DBUtility和CheckUtility組件類），如圖十三所示。 圖十三：SQLServerDAL中的XiuGuiMap類圖(4)增加web.config里的配置信息：可設(shè)為SQLServ

30、erDAL的程序集，代碼如下：<appSettings> <addkey="WebDAL"value="SQLServerDAL"/></appSettings>(5)創(chuàng)建DALFactory項(xiàng)目：返回程序集中指定類的實(shí)例。示例中的指定類為SQLServerDAL.XiuGuiMap。示例：讀取web.config里的配置信息，創(chuàng)建DALFactory的方法CreateXiuGuiMap()，返回程序集中類SQLServerDAL.XiuGuiMap的實(shí)例。主要代碼：privatestaticreadonlystrin

31、g path = ConfigurationManager.AppSettings"WebDAL" publicstatic IDAL.IXiuGuiMap CreateXiuGuiMap() string className = path + ".XiuGuiMap"return (DAL.IXiuGuiMap)Assembly.Load(path).CreateInstance(className); (6)創(chuàng)建BLL項(xiàng)目：調(diào)用DALFactory，得到程序集指定類的實(shí)例，調(diào)用此類的數(shù)據(jù)操作方法。示例：調(diào)用DALFactory，得到程序集中類SQLS

32、erverDAL.XiuGuiMap的實(shí)例，調(diào)用此類數(shù)據(jù)操作方法GetXiuGuiMapInforByFID(int FID)。此類所含的數(shù)據(jù)操作方法如圖十四所示。主要代碼： privatestaticreadonlyIUser dal = webserviceDemo.DALFactory.DataAccess.CreateUser();publicIList<XiuGuiMapInfo> GetXiuGuiMapInforByFID(int FID) if (FID>int.MaxValue&&FID<int.MinValue)returnnewLi

33、st<XiuGuiMapInfo>();return dal.GetXiuGuiMap(FID); 圖十四：SQLServerDAL.XiuGuiMap類圖(7)創(chuàng)建Web Service項(xiàng)目：根據(jù)實(shí)際業(yè)務(wù)需要，調(diào)用BLL里的數(shù)據(jù)操作方法創(chuàng)建服務(wù)。 圖十五：web service對(duì)外發(fā)布的服務(wù)如圖十五所示，web service對(duì)外發(fā)布的服務(wù)和服務(wù)內(nèi)容的描述如下：1)   AddXiuGuiMap 添加一張修規(guī)圖的信息 2)   GetAllXiuGuiMap 獲得數(shù)據(jù)庫中所有修規(guī)圖的信息 3)   G

34、etSearchXiuGuiMap 獲得符合搜索條件的所有修規(guī)圖的信息 4)   GetXiuGuiMapCAD 下載某特定修規(guī)圖的CAD文件 5)   GetXiuGuiMapInforByFID 獲得某特定修規(guī)圖的信息 6)   Link 驗(yàn)證服務(wù)地址是否正確 <7)   Login 登錄授權(quán) 8)   UpdateXiuGuiMap 更新某特定修規(guī)圖的信息 9)   deleteXiuGuiMap 刪除某特定修規(guī)圖的信息5.2系統(tǒng)客戶端的實(shí)現(xiàn)以Windows Cl

35、ient為例,我們需先給客戶端工程添加Web引用.添加后，客戶端會(huì)生成一系列的文件，如圖十六所示。 圖十六：Web Service在客戶端生成的文件完成添加后,即可通過實(shí)例化代理類來調(diào)用Web Services。示例：實(shí)例化圖十六中的WebService_XiuGuiMap.Service代理類,調(diào)用服務(wù)器端的服務(wù)內(nèi)容主要代碼：Client.WebService_XiuGuiMap.Service ws = new Client.WebService_XiuGuiMap.Service();Object obj=ws.GetXiuGuiMapInforByFID(1);/調(diào)用服務(wù)內(nèi)容

36、，返回了一個(gè)object對(duì)象。6.  關(guān)鍵技術(shù)的研究6.1.    自定義類的設(shè)計(jì)和實(shí)例化ASP.NET WebService 支持絕大多數(shù)的基元類型及其數(shù)組，另外還支持自定義的結(jié)構(gòu)(Struct)、類型(Class)、枚舉(Enum)、DataSet、XmlElement、XmlNode、集合(IEnumerable/ICollection)等。ASP.NET WebService 使用 XmlSerializer 進(jìn)行序列化操作，對(duì)于自定義類型要注意以下幾點(diǎn)：（1）    只能序列化可讀寫公共屬性和字段。只讀屬性(get

37、;)、只讀字段(readonly)、常量(const)以及所有的非 public 數(shù)據(jù)成員都不會(huì)被序列化。（2）    自定義類型必須具有不接受任何參數(shù)的默認(rèn)構(gòu)造函數(shù)。（3）    不能序列化方法?？蛻舳松傻拇韺?duì)象不包含任何自定義類型的方法(不是WebMethod)。基于以上幾點(diǎn)，因此我們最好只定義純粹用來傳輸復(fù)合數(shù)據(jù)的數(shù)據(jù)類型(Data Object)。在表現(xiàn)層中，除了web service外，都只能使用默認(rèn)構(gòu)造函數(shù)實(shí)例化自定義類。通過對(duì)象的屬性為對(duì)象賦值。6.2.    三層體系結(jié)構(gòu)設(shè)計(jì)中各層設(shè)計(jì)

38、以及工廠模式的使用三層體系結(jié)構(gòu)設(shè)計(jì)中各層設(shè)計(jì)的精妙之處在上文已經(jīng)講述清楚。在軟件系統(tǒng)中，經(jīng)常面臨著“一系列相互依賴的對(duì)象”的創(chuàng)建工作；同時(shí)由于需求的變化，往往存在著更多系列對(duì)象的創(chuàng)建工作。為了應(yīng)對(duì)這種變化，我們繞過常規(guī)的對(duì)象的創(chuàng)建方法（new），使用了一種“封裝機(jī)制”來避免客戶程序和這種“多系列具體對(duì)象創(chuàng)建工作”的緊耦合，即抽象工廠模式，就是提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無需指定它們具體的類。概括來說，兩者的目的都是為了分散關(guān)注、松散耦合、邏輯復(fù)用、標(biāo)準(zhǔn)定義，給系統(tǒng)帶來更大的可擴(kuò)展性和盡量少的代碼修改量。6.3.    數(shù)據(jù)傳輸?shù)膬?yōu)化SOAP是基于

39、XML編碼的，系統(tǒng)使用 XMLSerializer 類對(duì)SOAP進(jìn)行了序列化處理，壓縮率高達(dá)80，提高了網(wǎng)絡(luò)傳輸?shù)男? 優(yōu)化了 WEBSERVICE性能。而客戶端只需將接收到的數(shù)據(jù)流進(jìn)行反序列化，就可以得到源數(shù)據(jù)。6.4.    狀態(tài)保持NET WebService 是建立在 ASP.NET 基礎(chǔ)上，在 WebService 中我們同樣可以訪問 Session、User、Application 等上下文對(duì)象，不過在某些使用細(xì)節(jié)上可能有所不同。由于 WebService 客戶端代理對(duì)象可能應(yīng)用于 ConsoleApplication、WinForm 或 WebFo

40、rm 等環(huán)境，而 Session 又必須通過 Cookie 來保存唯一的 SessionID，因此我們必須使用 CookieContainer 創(chuàng)建 Cookie 容器來保存 WebService 返回的 Session 信息。創(chuàng)建容器對(duì)象后，必須將其引用賦值給代理對(duì)象的 CookieContainer 屬性。在第一次調(diào)用 SessionEnabled WebMethod 后，該容器將持有 Session Cookie 信息。如果需要在多個(gè)代理對(duì)象中調(diào)用 SessionEnabled WebMethod，那么它們必須持有同一個(gè) Cookie 容器對(duì)象。簡言之，服務(wù)器端用session進(jìn)行狀態(tài)保持，客戶端需要cookie的支持。狀態(tài)保持，可以用于實(shí)現(xiàn)一次身份認(rèn)證授權(quán)，多次調(diào)用服務(wù)的功能，而不用每次調(diào)用服務(wù)時(shí)都要從客戶端傳遞身份信息到服務(wù)器端進(jìn)行認(rèn)證。6.5.