《畢設(shè)-電子檔案管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn).doc》由會(huì)員分享，可在線閱讀，更多相關(guān)《畢設(shè)-電子檔案管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn).doc（60頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

______________________________________________________________________________________________________________ 學(xué)號(hào)：13061255 西安電子科技大學(xué)學(xué)士學(xué)位論文 影像及電子檔案管理系統(tǒng) 內(nèi)容管理子系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn) Design and Implementation of the Content Management Subsystem of the Video and Document Management System 學(xué)院： 軟件學(xué)院 專業(yè)： 軟件工程 班級(jí)： 130613 姓名： 崔日新 導(dǎo)師： 孫述龍 摘 要 隨著檔案資料價(jià)值的日漸提升，各行各業(yè)對(duì)檔案管理也提出了更高的要求。對(duì)檔案要“管好”，更要“用好”，但首先要管理好。本文針對(duì)企業(yè)中的信息管理需求探討了面向企業(yè)應(yīng)用的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。由于企業(yè)內(nèi)信息文檔繁多、業(yè)務(wù)需求多變，以及涉及到公司工作效率和文件價(jià)值與保密性等因素。致使文檔管理平臺(tái)建設(shè)存在許多問(wèn)題。本文從軟件體系結(jié)構(gòu)模式的角度入手，首先構(gòu)建了一個(gè)基于MVC模式的應(yīng)用軟件開(kāi)發(fā)框架，然后在此基礎(chǔ)上設(shè)計(jì)和實(shí)現(xiàn)了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)。在介紹SSH結(jié)構(gòu)模型、Ajax等理論的基礎(chǔ)上，對(duì)比已有文檔管理平臺(tái)的不足之處，著重研究如何使用這些框架和技術(shù)開(kāi)發(fā)跨平臺(tái)、框架靈活、穩(wěn)定實(shí)用的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的問(wèn)題，并給出了基于Struts+Hibernate+ Spring+ExtJ技術(shù)的系統(tǒng)整體架構(gòu)設(shè)計(jì)和內(nèi)容管理子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。論文最后討論了目前的影像及電子檔案管理內(nèi)容管理子系統(tǒng)有待完善和進(jìn)一步研究的問(wèn)題。 關(guān)鍵詞： 影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng) MVC SSH Ajax -可編輯修改- ______________________________________________________________________________________________________________ ABSTRACT With the increasing value of file data, all walks of life have a higher demand for the file management. As to the document, it is better to be used well than be managed well, while the first is to be managed well. This paper will talk about the design and implementation of the Content Management Subsystem of the Video and Document Management System which works as an enterprise application. Aware of the changing business requirements in the system, it is very difficult to build the platform. In this paper, it firstly begins with the software architecture patterns, then constructs an application software development framework which is built upon the MVC pattern, next describes the design and implementation of the Content Management Subsystem of the Video and Document Management System. On the basis of introducing SSH architecture, the paper contrasts to the disadvantages in the existing document management systems and focuses on how to use these technologies and development frameworks to build a cross-platform, flexible framework and stability practical video and document management system. It also gives the implementation of the system’s overall framework for designing and performance layer based on Struts, Hibernate, Spring and ExtJs , in the paper. Finally, the paper points to the problems when refer to making the system more perfect and further work to be done in the current Content Management Subsystem of the Video and Document Management System. Finally, the paper discusses the points to be perfected and the problems to be further studied in the current in the current Content Management Subsystem of the Video and Document Management System. Keyword: Video and Document Management System MVC SSH Ajax ______________________________________________________________________________________________________________ 目 錄 第一章 緒論 3 1.1 項(xiàng)目背景 3 1.2 項(xiàng)目研究?jī)?nèi)容 3 1.3 論文結(jié)構(gòu) 4 第二章 相關(guān)理論與技術(shù) 6 2.1 相關(guān)理論簡(jiǎn)介 6 2.2 Struts2的核心技術(shù) 6 2.3 Hibernate的核心技術(shù) 8 2.4 Spring的核心技術(shù) 9 2.5 AJAX技術(shù) 10 2.6 SSH集成框架 11 第三章 需求分析 12 3.1系統(tǒng)需求分析 12 3.1.1 系統(tǒng)角色 12 3.1.2 需求分析 12 3.2 本章小結(jié) 15 第四章 系統(tǒng)總體設(shè)計(jì) 16 4.1 系統(tǒng)架構(gòu)總體設(shè)計(jì) 16 4.1.1 傳統(tǒng)開(kāi)發(fā)框架到SSH框架 16 4.1.2 SSH框架構(gòu)建設(shè)計(jì) 17 4.1.3 SSH架構(gòu)在系統(tǒng)中的應(yīng)用 19 4.1.3 SSH架構(gòu)的優(yōu)勢(shì)與不足 20 4.2 系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì) 21 4.3 系統(tǒng)持久層總體設(shè)計(jì) 23 4.3.1 系統(tǒng)持久層設(shè)計(jì)與實(shí)現(xiàn) 23 4.3.2 DAO層設(shè)計(jì)與實(shí)現(xiàn) 24 4.4 系統(tǒng)業(yè)務(wù)邏輯層總體設(shè)計(jì) 27 4.5 系統(tǒng)表現(xiàn)層總體設(shè)計(jì) 29 4.5.1 使用Ext的頁(yè)面布局 29 4.5.2 使用Ext支持的客戶端表單驗(yàn)證 29 4.5.3 Ext封裝的Ajax技術(shù)的使用 30 4.7 本章小節(jié) 32 第五章 系統(tǒng)具體實(shí)現(xiàn) 33 5.1 類別管理模塊具體實(shí)現(xiàn) 33 5.1.1 持久層具體實(shí)現(xiàn) 33 5.1.2 表現(xiàn)層具體實(shí)現(xiàn) 33 5.2 文檔管理模塊具體實(shí)現(xiàn) 34 5.2.1 持久層和控制層具體實(shí)現(xiàn) 34 5.2.2 表現(xiàn)層具體實(shí)現(xiàn) 35 5.3 日志管理模塊具體實(shí)現(xiàn) 37 5.4 權(quán)限管理模塊具體實(shí)現(xiàn) 38 5.4.1 控制層具體實(shí)現(xiàn) 38 5.4.2 表現(xiàn)層具體實(shí)現(xiàn) 38 5.5 系統(tǒng)附加功能具體實(shí)現(xiàn) 39 5.5.1信息統(tǒng)計(jì)功能的實(shí)現(xiàn)具體實(shí)現(xiàn) 39 5.5.2 系統(tǒng)定時(shí)清理功能具體實(shí)現(xiàn) 39 5.6 本章小節(jié) 40 第六章 運(yùn)行及測(cè)試 41 6.1 系統(tǒng)部署情況 41 6.2 系統(tǒng)日志功能運(yùn)行情況 42 6.3 系統(tǒng)核心功能測(cè)試與運(yùn)行情況 42 6.3.1 管理員管理功能測(cè)試與運(yùn)行情況 42 5.3.2 文檔管理功能測(cè)試與運(yùn)行情況 44 5.3.3 權(quán)限管理功能測(cè)試與運(yùn)行情況 47 第七章 結(jié)論與展望 49 7.1 本文總結(jié) 49 7.2 影像及電子檔案管理系統(tǒng)建設(shè)的未來(lái)思考 49 7.2.1 系統(tǒng)存在的不足 49 7.2.1 系統(tǒng)的展望 50 致 謝 51 參考文獻(xiàn) 53 ______________________________________________________________________________________________________________ 第一章 緒論 1.1 項(xiàng)目背景 電子檔案以其現(xiàn)代化手段,在檔案信息存儲(chǔ)、輸出、處理等方面,具有紙質(zhì)檔案無(wú)法比擬的優(yōu)越性.網(wǎng)絡(luò)化運(yùn)用引起了電子檔案的保密性、安全性、真實(shí)性、可靠性問(wèn)題.因此,必須加強(qiáng)電子文件的管理。公司中存在著各種信息檔案，而如今人們已經(jīng)習(xí)慣用電腦辦公，結(jié)果自然會(huì)產(chǎn)生大量的電子文件，但我們?nèi)绻麑⒏嗟臅r(shí)間花費(fèi)在尋找這些文件上，既費(fèi)時(shí)又費(fèi)力。同時(shí)，公司文檔又關(guān)系到公司工作效率與利益問(wèn)題，怎樣有效管理電子檔案成為我們必須研究與解決的問(wèn)題。如今已有的電子檔案管理系統(tǒng)存在的主要問(wèn)題有： 問(wèn)題1：原有系統(tǒng)采用單一的Struts或其他的開(kāi)發(fā)框架，這種方式缺少有效的模塊集成手段，基于不同平臺(tái)的模塊很難集成，系統(tǒng)的可擴(kuò)展性和伸縮性比較差。一旦系統(tǒng)需求分析發(fā)生變化(此時(shí)往往已經(jīng)到了開(kāi)發(fā)過(guò)程的中后期)或者系統(tǒng)需要擴(kuò)展業(yè)務(wù)，原有系統(tǒng)的框架不能很好地解決這一問(wèn)題。 問(wèn)題2：用戶反映該系統(tǒng)的用戶界面不夠簡(jiǎn)潔，使用流程比較復(fù)雜。 問(wèn)題3：文檔分類方法不恰當(dāng)，危及文件信息資源的有效收集。 問(wèn)題4：系統(tǒng)功能不完善，直接影響文件信息資源的管理水。 顯然，根本的解決辦法是完善系統(tǒng)開(kāi)發(fā)框架、科學(xué)的文檔分類管理與友善的用戶操作界面。待開(kāi)發(fā)的系統(tǒng)借鑒了原有系統(tǒng)的功能需求，但是在使用的開(kāi)發(fā)框架和表現(xiàn)層方面對(duì)原有系統(tǒng)進(jìn)行改進(jìn)，使得系統(tǒng)更加完善。 1.2 項(xiàng)目研究?jī)?nèi)容 本文主要研究在影像及電子檔案管理平臺(tái)中隸屬于影像及電子檔案管理系統(tǒng)應(yīng)用集成框架的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，在整個(gè)過(guò)程中主要完成以下工作： 1．影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的整體設(shè)計(jì)。在研究國(guó)內(nèi)外現(xiàn)有成果地基礎(chǔ)上完成影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的整體設(shè)計(jì)和邏輯上的模塊劃分。 2．研究一套靈活的系統(tǒng)整體架構(gòu)方案，以方便處理系統(tǒng)模塊間的控制和數(shù)據(jù)的集成，解決原有系統(tǒng)可維護(hù)性和擴(kuò)展性差的問(wèn)題。將研究結(jié)果應(yīng)用于實(shí)際系統(tǒng)開(kāi)發(fā)，為提高影像及電子檔案管理內(nèi)容管理子系統(tǒng)的快速開(kāi)發(fā)、可維護(hù)和擴(kuò)展能力提供有效的支持。設(shè)計(jì)并實(shí)現(xiàn)影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)整體后臺(tái)框架，為整個(gè)系統(tǒng)提供架構(gòu)支持。 3．在系統(tǒng)表現(xiàn)層方面，研究使用與后臺(tái)進(jìn)行異步交互的框架和能帶來(lái)良好用戶體驗(yàn)的技術(shù)，以提高頁(yè)面良好的展示效果。 4．根據(jù)需求分析，設(shè)計(jì)實(shí)現(xiàn)影像及電子檔案管理內(nèi)容管理子系統(tǒng)核心功能，即文檔管理功能，為其他模塊提供技術(shù)借鑒與支持。 5．根據(jù)需求分析實(shí)現(xiàn)影像及電子檔案管理內(nèi)容管理子系統(tǒng)各功能。 1.3 論文結(jié)構(gòu) 論文分為六章，各章主要內(nèi)容如下： 第一章：緒論。提出項(xiàng)目的背景，以及項(xiàng)目的研究?jī)?nèi)容和組織結(jié)構(gòu)。 第二章：相關(guān)技術(shù)概述。探討了Struts、Hibernate、Spring、Ajax等相關(guān)理論。 第三章：影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)需求分析。簡(jiǎn)要說(shuō)明了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的需求分析和不同系統(tǒng)角色的具體功能需求。 第四章：首先分析了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)架構(gòu)的總體設(shè)計(jì)。重點(diǎn)介紹了基于SSH架構(gòu)的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)總體架構(gòu)的總體設(shè)計(jì)以及數(shù)據(jù)庫(kù)設(shè)計(jì)。然后分別對(duì)系統(tǒng)持久層和業(yè)務(wù)邏輯層設(shè)計(jì)做了詳細(xì)介紹。 第五章：介紹了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)核心模塊非共性的具體實(shí)現(xiàn)，重點(diǎn)討論了使用了Ext框架的頁(yè)面組織和實(shí)現(xiàn)過(guò)程。 第六章：系統(tǒng)測(cè)試與運(yùn)行。首先介紹了系統(tǒng)軟硬件部署情況，然后以貫穿系統(tǒng)配置與部署的日志管理系統(tǒng)的運(yùn)行情況說(shuō)明系統(tǒng)是可實(shí)現(xiàn)的而且部署是成功的。最后以系統(tǒng)核心功能為例，使用測(cè)試用例對(duì)其進(jìn)行了測(cè)試，分析了測(cè)試結(jié)果。 最后總結(jié)了全文，指出了系統(tǒng)的需要改進(jìn)的地方和進(jìn)一步的研究方向。 第二章 相關(guān)理論與技術(shù) 2.1 相關(guān)理論簡(jiǎn)介 ? SSH SSH 在J2EE項(xiàng)目中表示了3種框架,既 Spring + Struts + Hibernate。 ? Struts2 Struts2[1]是在WebWork基礎(chǔ)上發(fā)展起來(lái)的，是建立在稱為XWork的Command模式框架之上的強(qiáng)大的基于Web的MVC框架（參見(jiàn)本章2.2節(jié)）。 ? Hibernate Hibernate[2]是一個(gè)開(kāi)放源代碼的對(duì)象關(guān)系映射框架，對(duì)JDBC進(jìn)行了輕量級(jí)的對(duì)象封裝，使得我們可以使用對(duì)象編程思維來(lái)操縱數(shù)據(jù)庫(kù)。 Hibernate可以應(yīng)用在任何使用JDBC的場(chǎng)合，最具革命意義的是，Hibernate可以在應(yīng)用EJB的J2EE架構(gòu)中取代CMP，完成數(shù)據(jù)持久化的重任（參見(jiàn)本章2.3節(jié)）。 ? Spring Spring[3]是一個(gè)開(kāi)源框架，它是為了解決企業(yè)應(yīng)用開(kāi)發(fā)的復(fù)雜性而創(chuàng)建的。Spring使用基本的JavaBean來(lái)完成以前只可能由EJB完成的事情。然而，Spring的用途不僅限于服務(wù)器端的開(kāi)發(fā)。從簡(jiǎn)單性、可測(cè)試性和松耦合的角度而言，任何Java應(yīng)用都可以從Spring中受益（參見(jiàn)本章2.4節(jié)）。 ? Ajax Ajax[4]全稱為“Asynchronous JavaScript and XML”(異步JavaScript和XML)，是指一種創(chuàng)建交互式網(wǎng)頁(yè)應(yīng)用的網(wǎng)頁(yè)開(kāi)發(fā)技術(shù)。Ajax并不是一種新產(chǎn)生出來(lái)的技術(shù)，它實(shí)際上是由目前幾種相對(duì)成熟的技術(shù)組合而成的。標(biāo)準(zhǔn)的Ajax包含： 基于XHTML和CSS標(biāo)準(zhǔn)的表示。 2.2 Struts2的核心技術(shù) Struts2是WebWork的升級(jí)，而不是一個(gè)全新的框架，因此穩(wěn)定性、性能等各方面都有很好的保證：而且吸收了Struts 1和WebWork兩者的優(yōu)勢(shì)。Struts2是一個(gè)優(yōu)雅的，可擴(kuò)展的JAVA EE Web[5]框架?？蚣茉O(shè)計(jì)的目標(biāo)貫穿整個(gè)開(kāi)發(fā)周期，從開(kāi)發(fā)到發(fā)布，包括維護(hù)的整個(gè)過(guò)程。 Struts2框架的核心是一個(gè)靈活的控制層，它基于以下標(biāo)準(zhǔn)技術(shù)，如：Java Servlet、JavaBean資源綁定、XML和各種Jakarta Commons包。Struts鼓勵(lì)使用基于Model2方法的應(yīng)用框架，它是一種經(jīng)典的模型－試圖－控制器的MVC模型。 MVC是Xerox PARC在20世紀(jì)80年代為編程語(yǔ)言Smalltalk-80發(fā)明的一種軟件架構(gòu)模式。它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開(kāi)。使用MVC應(yīng)用程序被分成三個(gè)核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)。MVC視圖如圖： 圖2.1 MVC視圖 視圖(View)代表用戶交互界面。隨著應(yīng)用的復(fù)雜性和規(guī)模性，界面的處理也變得具有挑戰(zhàn)性。一個(gè)應(yīng)用可能有很多不同的視圖，MVC設(shè)計(jì)模式對(duì)于視圖的處理僅限于視圖上數(shù)據(jù)的采集和處理，以及用戶的請(qǐng)求，而不包括在視圖上的業(yè)務(wù)流程的處理。業(yè)務(wù)流程的處理交予模型(Model)處理。比如一個(gè)文檔信息的視圖只接受來(lái)自模型的數(shù)據(jù)并顯示給用戶，以及將用戶界面的輸入數(shù)據(jù)和請(qǐng)求傳遞給控制和模型。 模型(Model)表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個(gè)部件中，模型擁有最多的處理任務(wù)。例如它可能用如EJBs和ColdFusion Components這樣的構(gòu)件對(duì)象來(lái)處理數(shù)據(jù)庫(kù)。被模型返回的數(shù)據(jù)是中立的，就是說(shuō)模型與數(shù)據(jù)格式無(wú)關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫(xiě)一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性。 控制(Controller)可以理解為從用戶接收請(qǐng)求, 將模型與視圖匹配在一起，共同完成用戶的請(qǐng)求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個(gè)分發(fā)器，選擇什么樣的模型，選擇什么樣的視圖，可以完成什么樣的用戶請(qǐng)求?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。例如，用戶點(diǎn)擊一個(gè)連接，控制層接受請(qǐng)求后, 并不處理業(yè)務(wù)信息，它只把用戶的信息傳遞給模型，告訴模型做什么，選擇符合要求的視圖返回給用戶。因此，一個(gè)模型可能對(duì)應(yīng)多個(gè)視圖，一個(gè)視圖可能對(duì)應(yīng)多個(gè)模型。 模型、視圖與控制器的分離，使得一個(gè)模型可以具有多個(gè)顯示視圖。如果用戶通過(guò)某個(gè)視圖的控制器改變了模型的數(shù)據(jù)，所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此，無(wú)論何時(shí)發(fā)生了何種數(shù)據(jù)變化，控制器都會(huì)將變化通知所有的視圖，導(dǎo)致顯示的更新。這實(shí)際上是一種模型的變化-傳播機(jī)制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能 2.3 Hibernate的核心技術(shù) Hibernate是一種Java語(yǔ)言下的對(duì)象關(guān)系映射解決方案。 它是一種自由、開(kāi)源的軟件。它用來(lái)把對(duì)象模型表示的對(duì)象映射到基于SQL 的關(guān)系模型結(jié)構(gòu)中去，為面向?qū)ο蟮念I(lǐng)域模型到傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的映射，提供了一個(gè)使用方便的框架。 Hibernate 不僅管理Java類到數(shù)據(jù)庫(kù)表的映射（包括從Java數(shù)據(jù)類型到SQL數(shù)據(jù)類型的映射），還提供數(shù)據(jù)查詢和獲取數(shù)據(jù)的方法，可以大幅度減少開(kāi)發(fā)時(shí)人工使用SQL 和JDBC 處理數(shù)據(jù)的時(shí)間。 Hibernate對(duì)JDBC進(jìn)行了非常輕量級(jí)的對(duì)象封裝，使得Java程序員可以隨心所欲的使用對(duì)象編程思維來(lái)操縱數(shù)據(jù)庫(kù)。 Hibernate可以應(yīng)用在任何使用JDBC的場(chǎng)合，它既可以在Java的客戶端程序使用，也可以在Servlet/JSP的Web應(yīng)用中使用。最具革命意義的是，Hibernate可以在應(yīng)用EJB（Enterprise JavaBeans是Java應(yīng)用于企業(yè)計(jì)算的框架）的J2EE架構(gòu)中取代CMP，完成數(shù)據(jù)持久化的重任。 2.4 Spring的核心技術(shù) Spring是一個(gè)輕量級(jí)的控制反轉(zhuǎn)(IoC)和面向切面(AOP)的容器框架。是企業(yè)應(yīng)用開(kāi)發(fā)的“一站式”選擇，并貫穿表現(xiàn)層、業(yè)務(wù)層及持久層。然而，Spring并不想取代那些已有的框架，而是與它們無(wú)縫地整合。 控制翻轉(zhuǎn)IoC(Inversion of Control)/依賴注入DI(Dependence Injection)機(jī)制。IoC是指由容器中控制組件之間的關(guān)系（這里，容器是指為組件提供特定服務(wù)和技術(shù)支持的一個(gè)標(biāo)準(zhǔn)化的運(yùn)行時(shí)的環(huán)境）而非傳統(tǒng)實(shí)現(xiàn)中由程序代碼直接操控，這種將控制權(quán)由程序代碼到外部容器的轉(zhuǎn)移，稱為“翻轉(zhuǎn)”。DI是對(duì)IoC更形象的解釋，即由容器在運(yùn)行期間動(dòng)態(tài)地將依賴關(guān)系（如構(gòu)造參數(shù)、構(gòu)造對(duì)象或接口）注入到組件之中。Spring采用設(shè)值注入（使用Setter方法實(shí)現(xiàn)依賴）和構(gòu)造子注入（在構(gòu)造方法中實(shí)現(xiàn)依賴）的機(jī)制，通過(guò)配置文件管理組建的協(xié)作對(duì)象，創(chuàng)建可以構(gòu)造組件的IoC容器。這樣，不需要編寫(xiě)工廠模式、單例模式或者其他構(gòu)造的方法，就可以通過(guò)容器直接獲取所需的業(yè)務(wù)組件。Spring框架的結(jié)構(gòu)如圖2.2所示。 圖2.2 Spring框架模塊組成 Spring框架由七個(gè)定義明確的模塊組成，且每個(gè)模塊或組件都可以單獨(dú)存在，或者與其他一個(gè)或多個(gè)模塊聯(lián)合實(shí)現(xiàn)。Spring Core Container是一個(gè)用來(lái)管理業(yè)務(wù)組件的IoC容器，是Spring應(yīng)用的核心；Spring DAO和Spring ORM不僅提供數(shù)據(jù)訪問(wèn)的抽象模塊，還集成了對(duì)Hibernate、JDO和iBatis等流行的對(duì)象關(guān)系映射框架的支持模塊，并且提供了緩沖連接池、事務(wù)處理等重要的服務(wù)功能，保證了系統(tǒng)的性能和數(shù)據(jù)的完整性；Spring Web模塊提供了Web應(yīng)用的一些抽象封裝，可以將Struts、Webwork等Web框架與Spring整合成為適用于自己的解決方案。 Spring框架可以成為企業(yè)級(jí)應(yīng)用程序一站式的解決方案，同時(shí)它也是模塊化的框架，允許開(kāi)發(fā)人員自由地挑選適合自己應(yīng)用的模塊進(jìn)行開(kāi)發(fā)。Spring框架式是一個(gè)松耦合的框架，框架的部分耦合度被設(shè)計(jì)為最小，在各個(gè)層次上具體選用哪個(gè)框架取決于開(kāi)發(fā)者的需要。 2.5 AJAX技術(shù) Ajax的核心是JavaScript對(duì)象XmlHttpRequest。它是一種支持異步請(qǐng)求的技術(shù)。JavaScript可以在不刷新頁(yè)面的情況下從服務(wù)器獲取數(shù)據(jù)，或者向服務(wù)器提交數(shù)據(jù)，靈活地實(shí)現(xiàn)了數(shù)據(jù)異步交互。 我們知道，傳統(tǒng)的Web應(yīng)用是同步交互的方式。這種同步交互方式的處理過(guò)程如圖2.3所示。 圖4.14 同步交互方式 用戶向服務(wù)器提交了一個(gè)處理請(qǐng)求時(shí)，服務(wù)器端接受到該請(qǐng)求后，和數(shù)據(jù)庫(kù)服務(wù)器進(jìn)行數(shù)據(jù)信息的交換，然后對(duì)請(qǐng)求處理進(jìn)行相應(yīng)，即將結(jié)果傳送回發(fā)出請(qǐng)求的瀏覽器客戶端，返回一個(gè)HTML頁(yè)面在瀏覽器端進(jìn)行顯示。 顯然，這樣的一種處理方式會(huì)給用戶一種不連貫的體驗(yàn)，因?yàn)楫?dāng)服務(wù)器在處理請(qǐng)求的時(shí)候，用戶多數(shù)時(shí)間只能處于等待狀態(tài)，頁(yè)面中顯示的內(nèi)容也只能時(shí)一片空白。 與傳統(tǒng)的Web應(yīng)用不同，Ajax采用的是一種異步交互的處理方式。這種異步交互的處理過(guò)程如圖2.4所示。 圖2.4 使用Ajax的異步交互模式 Ajax相當(dāng)于在瀏覽器客戶端與服務(wù)器之間架設(shè)了一個(gè)橋梁，在它的幫助下，可以消除網(wǎng)絡(luò)交互過(guò)程中的處理－等待－處理－等待的缺陷。在處理過(guò)程中Web服務(wù)器響應(yīng)是標(biāo)準(zhǔn)的且易于解析的XML格式的數(shù)據(jù)傳遞到Ajax，然后再轉(zhuǎn)換成HTML頁(yè)面的格式，輔助CSS進(jìn)行顯示。 Ajax是傳統(tǒng)Web應(yīng)用程序的一個(gè)轉(zhuǎn)變。Ajax可以所為客戶端和服務(wù)器的中間層，來(lái)處理客戶端的請(qǐng)求，并根據(jù)需要向服務(wù)器端發(fā)送請(qǐng)求，用什么就取什么、用多少就取多少，就不會(huì)有數(shù)據(jù)的冗余和浪費(fèi)，減少了數(shù)據(jù)下載總量，而且更新頁(yè)面時(shí)不用重載全部?jī)?nèi)容，只更新需要更新的那部分即可，相對(duì)于純后臺(tái)處理并重載的方式縮短了用戶等待時(shí)間。 2.6 SSH集成框架 SSH（Spring + Struts + Hibernate）是典型的J2EE三層結(jié)構(gòu)，分為表現(xiàn)層、中間層（業(yè)務(wù)邏輯層）和數(shù)據(jù)服務(wù)層。三層體系將業(yè)務(wù)規(guī)則、數(shù)據(jù)訪問(wèn)及合法性校驗(yàn)等工作放在中間層處理?？蛻舳瞬恢苯优c數(shù)據(jù)庫(kù)交互，而是通過(guò)組件與中間層建立連接，再由中間層與數(shù)據(jù)庫(kù)交互。 表現(xiàn)層是傳統(tǒng)的JSP[6]技術(shù)，其廣泛的應(yīng)用和穩(wěn)定的表現(xiàn)，為其作為表現(xiàn)層技術(shù)打下了堅(jiān)實(shí)的基礎(chǔ)。 中間層采用的是流行的Spring+Hibernate，為了將控制層與業(yè)務(wù)邏輯層分離，又細(xì)分為以下幾種。 Web層，就是MVC[7]模式里面的控制器，負(fù)責(zé)控制業(yè)務(wù)邏輯層與表現(xiàn)層的交互，調(diào)用業(yè)務(wù)邏輯層，并將業(yè)務(wù)數(shù)據(jù)返回給表現(xiàn)層作組織表現(xiàn)。Service層（就是業(yè)務(wù)邏輯層），負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯層以DAO層為基礎(chǔ)，通過(guò)對(duì)DAO組件的正面模式包裝，完成系統(tǒng)所要求的業(yè)務(wù)邏輯。DAO層，負(fù)責(zé)與持久化對(duì)象交互。PO，持久化對(duì)象。通過(guò)實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫(kù)[8]的數(shù)據(jù)映射成對(duì)象，方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫(kù)，采用Hibernate作為ORM框架。 Spring的作用貫穿了整個(gè)中間層，將Web層、Service層、DAO層及PO無(wú)縫整合，其數(shù)據(jù)服務(wù)層用來(lái)存放數(shù)據(jù)。 第三章 需求分析 3.1系統(tǒng)需求分析 3.1.1 系統(tǒng)角色 根據(jù)影像及電子檔案管理內(nèi)容管理子系統(tǒng)的實(shí)際需求，系統(tǒng)整體的用戶包括普通管理員、高級(jí)管理員以及普通用戶、高級(jí)用戶。而后臺(tái)影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的用戶角色為普通管理員和高級(jí)管理員。下面是對(duì)上述不同角色的需求分析。 3.1.2 需求分析 本小節(jié)分別說(shuō)明普通管理員和高級(jí)管理員的需求分析。 圖3.1表示普通管理員系統(tǒng)功能用例圖。 圖3.1 普通管理員系統(tǒng)功能用例圖 如圖普通管理員功能分為登陸、類別管理、文檔管理、日志管理、評(píng)論管理和用戶管理。此角色的系統(tǒng)功能結(jié)構(gòu)圖為： 普通管理員管理 類別管理 文檔管理 日志管理 用戶管理 評(píng)論管理 添加子類別 更新類別信息 刪除類別 添加文檔 更新文檔信息 刪除文檔 備份日志 清理日志 修改類型 修改狀態(tài) 查看評(píng)論 驗(yàn)證評(píng)論 登陸 圖3.2 普通管理員角色系統(tǒng)功能結(jié)構(gòu)圖 具體功能分析如下： (1) 普通管理員需求分析。 ? 管理員登錄：不同的用戶功能和權(quán)限不同，所以不同的用戶必須先進(jìn)行登錄驗(yàn)證，只有驗(yàn)證通過(guò)才能夠進(jìn)行相關(guān)的操作。 ? 文檔類別管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)文檔類別進(jìn)行操作，例如：刪除類別、在某一當(dāng)前類別下添加子類別與修改類別信息。 ? 文檔管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)文檔進(jìn)行操作，例如：錄入文檔、修改文檔基本信息、驗(yàn)證文檔、修改刪除與添加文件到某一當(dāng)前文檔、刪除文檔、高級(jí)選擇查看文檔等。 ? 用戶管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)用戶進(jìn)行管理，例如：查看用戶、刪除用戶、查看用戶上傳文檔等。 ? 用戶評(píng)論管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)用戶的評(píng)論進(jìn)行管理，例如：查看用戶評(píng)論、刪除多條用戶評(píng)論和按關(guān)鍵字批量刪除評(píng)論。 ? 日志管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)管理員操作日志進(jìn)行管理，例如：查看日志信息、備份日志與清理日志。 (2) 高級(jí)管理員需求分析。 圖3.3表示高級(jí)管理員系統(tǒng)功能用例圖 圖3.3 高級(jí)管理員系統(tǒng)功能用例圖（省略了普通管理員的功能） 高級(jí)管理員可以執(zhí)行系統(tǒng)所有操作，除了普通管理員的所有需求外，還包括管理員管理和權(quán)限管理，此角色的系統(tǒng)功能結(jié)構(gòu)圖為： 高級(jí)管理員管理 管理員管理 權(quán)限管理 添加管理員 修改管理員 刪除管理員 修改權(quán)限 圖3.4 高級(jí)管理員系統(tǒng)功能結(jié)構(gòu)圖 ? 管理員管理：高級(jí)管理員登陸后可以對(duì)系統(tǒng)管理員信息進(jìn)行管理，例如：添加管理員、刪除管理員和修改管理員信息。 ? 權(quán)限管理：高級(jí)管理員登陸后可以對(duì)系統(tǒng)角色權(quán)限進(jìn)行管理。 3.2 本章小結(jié) 本章主要介紹了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的需求分析，按照不同的角色將功能需求用用例圖的方式列出。然后為了更深入的了解系統(tǒng)需求，使用功能結(jié)構(gòu)圖對(duì)系統(tǒng)按角色進(jìn)行了功能分析。 第四章 系統(tǒng)總體設(shè)計(jì) 4.1 系統(tǒng)架構(gòu)總體設(shè)計(jì) 根據(jù)需求分析，這一節(jié)詳細(xì)討論了影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)的總體架構(gòu)設(shè)計(jì)方案。 4.1.1 傳統(tǒng)開(kāi)發(fā)框架到SSH框架 經(jīng)典的網(wǎng)站系統(tǒng)是基于Struts+Hibernate的框架進(jìn)行設(shè)計(jì)和開(kāi)發(fā)的。這種開(kāi)發(fā)框架的好處是實(shí)現(xiàn)簡(jiǎn)單，業(yè)務(wù)邏輯清晰，開(kāi)發(fā)人員使用起來(lái)很容易。因此在實(shí)際開(kāi)發(fā)時(shí)可以把后臺(tái)業(yè)務(wù)邏輯代碼放到設(shè)計(jì)好的JavaBean中，按照上述功能結(jié)構(gòu)圖的模塊劃分方式，每個(gè)模塊都是一個(gè)單獨(dú)的JavaBean類，控制層代碼直接使用這些類完成實(shí)際功能。 雖然上述的開(kāi)發(fā)框架可以很好的解決電子檔案管理中的應(yīng)用開(kāi)發(fā)面臨的問(wèn)題，但是實(shí)際應(yīng)用表明這存在著一些弱點(diǎn)。首先是復(fù)用的層次較低，開(kāi)發(fā)框架主要著眼于對(duì)象類的復(fù)用，而這些復(fù)用是代碼級(jí)的復(fù)用，代碼級(jí)的復(fù)用方式帶來(lái)的壞處是涉及實(shí)現(xiàn)細(xì)節(jié)，不支持可插拔的軟件構(gòu)件思想；其次是粒度較小，開(kāi)發(fā)框架中主要實(shí)現(xiàn)的是一些通用功能或者常規(guī)操作，沒(méi)有比較大粒度的構(gòu)件復(fù)用，雖然存在一定程度的獨(dú)立的業(yè)務(wù)代碼類，但是依然離不開(kāi)實(shí)現(xiàn)細(xì)節(jié)；最后就是使用人員的定位問(wèn)題，使用開(kāi)發(fā)框架的基本上是了解熟悉此類框架的軟件開(kāi)發(fā)專業(yè)技術(shù)人員，而對(duì)于不熟悉這種開(kāi)發(fā)框架的業(yè)務(wù)人員而言，無(wú)法滿足他們隨著需求變更修改系統(tǒng)或者自主開(kāi)發(fā)小應(yīng)用的需要。 為此，本文提出了比開(kāi)發(fā)框架層次更高的SSH框架構(gòu)件平臺(tái)來(lái)實(shí)現(xiàn)具體的應(yīng)用。SSH框架構(gòu)件平臺(tái)主要是為了適應(yīng)復(fù)雜多變的公司文檔信息管理的業(yè)務(wù)需求而提出的業(yè)務(wù)支撐平臺(tái)，該平臺(tái)的目標(biāo)是支持開(kāi)發(fā)人員通過(guò)統(tǒng)一的業(yè)務(wù)平臺(tái)快速構(gòu)建影像及電子檔案管理系統(tǒng)的業(yè)務(wù)流程，實(shí)現(xiàn)公司內(nèi)部影像及電子檔案管理的業(yè)務(wù)整合和數(shù)據(jù)整合，最終形成一個(gè)統(tǒng)一的立體式的影像及電子檔案管理系統(tǒng)。 4.1.2 SSH框架構(gòu)建設(shè)計(jì) 這一節(jié)以影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)為例，進(jìn)行SSH框架應(yīng)用的研究。 SSH框架規(guī)劃的出發(fā)點(diǎn)完全不同于現(xiàn)有的建模和組件的方案設(shè)計(jì)。傳統(tǒng)的網(wǎng)站系統(tǒng)設(shè)計(jì)是：當(dāng)軟件的設(shè)計(jì)和開(kāi)發(fā)人員在拿到業(yè)務(wù)需求后，會(huì)立即想到是不是需要使用Struts的MVC結(jié)構(gòu)，是使用EJB還是使用Hibernate，是使用什么樣的服務(wù)器和數(shù)據(jù)庫(kù)等。然后系統(tǒng)架構(gòu)師和每個(gè)業(yè)務(wù)人員進(jìn)行溝通并且劃分每個(gè)業(yè)務(wù)模塊，業(yè)務(wù)人員再向每個(gè)模塊填寫(xiě)相應(yīng)的代碼。這樣，使得業(yè)務(wù)從屬于技術(shù)，業(yè)務(wù)功能受到具體技術(shù)的限制，業(yè)務(wù)和技術(shù)是緊耦合的。 這樣的設(shè)計(jì)使得很多網(wǎng)站系統(tǒng)受到技術(shù)的限制，一旦系統(tǒng)需要改進(jìn)技術(shù)或者技術(shù)被淘汰，他們的業(yè)務(wù)也會(huì)跟著發(fā)生變化或者淘汰。 SSH框架規(guī)劃旨在減輕開(kāi)發(fā)人員重新建立解決復(fù)雜問(wèn)題方案的負(fù)擔(dān)和精力；它可以被擴(kuò)展以進(jìn)行內(nèi)部的定制化，提高開(kāi)發(fā)效率并容易實(shí)現(xiàn)系統(tǒng)的可擴(kuò)展性與可維護(hù)性。下圖為系統(tǒng)基于SSH框架的層次關(guān)系圖： 圖4.1 應(yīng)用框架的層次關(guān)系圖 層次結(jié)構(gòu)圖給出了應(yīng)用框架的層次關(guān)系，應(yīng)用框架由上向下可分為持久層、邏輯層、業(yè)務(wù)層、控制層和表現(xiàn)層。其中上層構(gòu)件為下層提供了獨(dú)立完整的功能，下層構(gòu)件無(wú)需了解上層構(gòu)件內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，只需要調(diào)用其提供的明確定義的接口和方法來(lái)實(shí)現(xiàn)自己的功能。應(yīng)用框架的分層機(jī)制負(fù)責(zé)將用戶的業(yè)務(wù)需求分為相對(duì)獨(dú)立的層次化模塊，支持開(kāi)發(fā)人員方便快速地開(kāi)發(fā)相對(duì)獨(dú)立的業(yè)務(wù)單元。 基于MVC模式，系統(tǒng)分為表現(xiàn)層、中間層（業(yè)務(wù)邏輯層）和數(shù)據(jù)服務(wù)層。三層體系將業(yè)務(wù)規(guī)則、數(shù)據(jù)訪問(wèn)及合法性校驗(yàn)等工作放在中間層處理?？蛻舳瞬恢苯优c數(shù)據(jù)庫(kù)交互，而是通過(guò)組件與中間層建立連接，再由中間層與數(shù)據(jù)庫(kù)交互。 表現(xiàn)層使用基于JSP顯示，ExtJs組件為主體的開(kāi)發(fā)模式。 中間層采用的是流行的Spring+Hibernate，為了將控制層與業(yè)務(wù)邏輯層分離，又細(xì)分為以下幾種。 Web層，就是MVC模式里面的“C”（controller），系統(tǒng)中對(duì)應(yīng)Action層。負(fù)責(zé)控制業(yè)務(wù)邏輯層與表現(xiàn)層的交互，調(diào)用業(yè)務(wù)邏輯層，并將業(yè)務(wù)數(shù)據(jù)返回給表現(xiàn)層作組織表現(xiàn)。 Service層（就是業(yè)務(wù)邏輯層），負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯層以DAO層為基礎(chǔ)，通過(guò)對(duì)DAO組件的正面模式包裝，完成系統(tǒng)所要求的業(yè)務(wù)邏輯。 DAO層，負(fù)責(zé)與持久化對(duì)象交互。該層封裝了數(shù)據(jù)的增、刪、查、改的操作，采用數(shù)據(jù)庫(kù)中間件Hibernate完成對(duì)底層數(shù)據(jù)庫(kù)應(yīng)用的封裝，通過(guò)一致的規(guī)范接口，將底層數(shù)據(jù)庫(kù)與業(yè)務(wù)邏輯分離開(kāi)來(lái)，為應(yīng)用系統(tǒng)的業(yè)務(wù)代碼開(kāi)發(fā)提供了數(shù)據(jù)層支持。 PO，持久化對(duì)象。通過(guò)實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)映射成對(duì)象，很方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫(kù)，該系統(tǒng)采用Hibernate作為ORM框架，并使用注解方式實(shí)現(xiàn)數(shù)據(jù)映射配置。 Spring的作用貫穿了整個(gè)中間層，將Web層、Service層、DAO層及PO無(wú)縫整合，依靠Spring依賴注入特性Web層中注入Service、Service層中注入DAO、DAO層中注入HibernateTemplate，其數(shù)據(jù)服務(wù)層用來(lái)存放數(shù)據(jù)。 為了提高系統(tǒng)的可擴(kuò)展性與可維護(hù)性，在DAO層與Service層分別抽取出接口層和接口實(shí)現(xiàn)層。 4.1.3 SSH架構(gòu)在系統(tǒng)中的應(yīng)用 圖4.2是影像及電子文檔管理系統(tǒng)的整體架構(gòu)圖。 圖4.2 影像及電子文檔管理內(nèi)容管理子系統(tǒng)的整體架構(gòu)圖 下面是對(duì)圖4.2中各層的角色及功能說(shuō)明。 (1)View層：影像及電子文檔管理內(nèi)容管理子系統(tǒng)的視圖展示，用戶頁(yè)面采用Ext框架進(jìn)行組織，數(shù)據(jù)從后臺(tái)轉(zhuǎn)發(fā)過(guò)來(lái)使用JSP的方式，然后在客戶端轉(zhuǎn)換成HTML頁(yè)面的格式，借助JavaScript和CSS進(jìn)行顯示。 (2)Controller層：影像及電子文檔管理內(nèi)容管理子系統(tǒng)的控制層，使用Struts的控制層來(lái)進(jìn)行業(yè)務(wù)流程控制?？刂破魇菓?yīng)用系統(tǒng)處理具體流程和導(dǎo)向的核心部分。它把模型對(duì)象給出的信息轉(zhuǎn)換成視圖可以理解的形式，并且處理系統(tǒng)流程的走向。在這里使用struts.xml配置文件來(lái)定義業(yè)務(wù)流程，使用Action類調(diào)用相應(yīng)的Web Service來(lái)實(shí)現(xiàn)這些具體功能。 (3)Model層：影像及電子文檔管理內(nèi)容管理子系統(tǒng)的模型層，實(shí)現(xiàn)具體的業(yè)務(wù)邏輯。模型包含應(yīng)用程序的核心功能，封裝了應(yīng)用程序的狀態(tài)，它對(duì)視圖或控制器一無(wú)所知。 數(shù)據(jù)庫(kù)中間件方面，系統(tǒng)定義了Dao層，使用集成封裝的HibernateTemplate實(shí)現(xiàn)數(shù)據(jù)操作。系統(tǒng)使用Annotation（注解）方式配置實(shí)體類與數(shù)據(jù)庫(kù)的映射關(guān)系，包括主鍵生成策略、表與表的級(jí)聯(lián)關(guān)系配置等。 4.1.3 SSH架構(gòu)的優(yōu)勢(shì)與不足 傳統(tǒng)的網(wǎng)站系統(tǒng)采用單一的Struts+Hibernate框架進(jìn)行設(shè)計(jì)和開(kāi)發(fā)，在這種方式下，客戶端代碼和業(yè)務(wù)邏輯代碼混雜在一起，而且模塊化劃分不夠靈活，各個(gè)業(yè)務(wù)模塊之間的耦合度較高。傳統(tǒng)的應(yīng)用沒(méi)有完全遵循軟件可重用性的原則，可重用性僅僅體現(xiàn)在本地的代碼可重用性，而對(duì)于更廣范圍的數(shù)據(jù)和代碼的可重用性，并沒(méi)有相應(yīng)的支持。 與傳統(tǒng)的網(wǎng)站系統(tǒng)應(yīng)用相比，基于SSH框架的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)架構(gòu)有如下優(yōu)點(diǎn)： 1． 發(fā)效率高 一個(gè)良好的框架可以讓開(kāi)發(fā)人員減輕重新建立解決復(fù)雜問(wèn)題方案的負(fù)擔(dān)和精力；它可以被擴(kuò)展以進(jìn)行內(nèi)部的定制化；并且有強(qiáng)大的用戶社區(qū)來(lái)支持它?？蚣芡ǔＤ芎芎玫慕鉀Q一個(gè)問(wèn)題。 2． 后期維護(hù)效率高 軟件工程不同于傳統(tǒng)的工業(yè)，例如電器、建筑及汽車等行業(yè)。這些行業(yè)的產(chǎn)品一旦開(kāi)發(fā)出來(lái)，交付用戶使用后將很少需要后續(xù)的維護(hù)。軟件產(chǎn)品的后期運(yùn)行維護(hù)是個(gè)巨大的工程。傳統(tǒng)的ASP和 PHP等腳本站點(diǎn)技術(shù)，將整個(gè)站點(diǎn)的業(yè)務(wù)邏輯和表現(xiàn)邏輯都混雜在ASP或PHP頁(yè)面里，從而導(dǎo)致頁(yè)面的可讀性相當(dāng)差，可維護(hù)性非常低。但采用嚴(yán)格分層J2EE架構(gòu)，則可完全避免這個(gè)問(wèn)題。對(duì)表現(xiàn)層的修改即使發(fā)生錯(cuò)誤，也絕對(duì)不會(huì)將錯(cuò)誤擴(kuò)展到業(yè)務(wù)邏輯層，更不會(huì)影響持久層。因此，采用J2EE分層架構(gòu)，即使前期的開(kāi)發(fā)效率稍微低一點(diǎn)，但也是值得的。 3． 系統(tǒng)結(jié)構(gòu)性強(qiáng) Struts提供標(biāo)準(zhǔn)的MVC架構(gòu)模式，Hibernate實(shí)現(xiàn)底層數(shù)據(jù)映射與數(shù)據(jù)業(yè)務(wù)操作，而Spring則貫穿于整個(gè)項(xiàng)目各個(gè)層次中，作為一個(gè)輕量級(jí)容器管理各個(gè)層次。系統(tǒng)結(jié)構(gòu)脈絡(luò)清晰。 4． 系統(tǒng)需求擴(kuò)展性強(qiáng) 幾乎所有的軟件需求都是在變化的。客戶對(duì)軟件需求，是隨著軟件開(kāi)發(fā)過(guò)程的深入，不斷明晰起來(lái)的。因此，常常遇到軟件開(kāi)發(fā)到一定程度時(shí)，由于客戶對(duì)軟件需求發(fā)生了變化，使得軟件的實(shí)現(xiàn)不得不隨之改變。當(dāng)軟件實(shí)現(xiàn)需要改變時(shí)，是否可以盡可能多地保留軟件的部分，盡可能少地改變軟件的實(shí)現(xiàn)，從而滿足客戶需求的變更？答案是——采用優(yōu)秀的解耦架構(gòu)。這種架構(gòu)就是J2EE的分層架構(gòu)，在優(yōu)秀的分層架構(gòu)里，控制層依賴于業(yè)務(wù)邏輯層，但絕不與任何具體的業(yè)務(wù)邏輯組件耦合，只與接口耦合；同樣，業(yè)務(wù)邏輯層依賴于DAO層，也不會(huì)與任何具體的DAO組件耦合，而是面向接口編程。采用這種方式的軟件實(shí)現(xiàn)，即使軟件的部分發(fā)生改變，其他部分也盡可能不要改變。 另一方面，在傳統(tǒng)的程序結(jié)構(gòu)中，只要有一點(diǎn)小的需求發(fā)生改變，將意味著放棄整個(gè)頁(yè)面，或者改寫(xiě)。采用Hibernate作為持久層技術(shù)的最大的好處在于：可以完全以面向?qū)ο蟮姆绞竭M(jìn)行系統(tǒng)分析、系統(tǒng)設(shè)計(jì)。 5． 系統(tǒng)技術(shù)擴(kuò)展性強(qiáng) Struts、Hibernate、Spring都是開(kāi)源框架，這同樣是優(yōu)勢(shì)之一。如Struts支持多種插件，在本系統(tǒng)中使用到了JfreeChart實(shí)現(xiàn)了系統(tǒng)統(tǒng)計(jì)的功能。 更高的系統(tǒng)靈活性 系統(tǒng)的頁(yè)面和服務(wù)開(kāi)發(fā)相互分離，這就使得在需求確定的情況下，系統(tǒng)的表現(xiàn)層和服務(wù)層的開(kāi)發(fā)能夠同時(shí)進(jìn)行，大大減少了系統(tǒng)開(kāi)發(fā)周期。另外，頁(yè)面和業(yè)務(wù)的分離降低了表現(xiàn)層和服務(wù)層的耦合度，一旦頁(yè)面發(fā)生改變，服務(wù)層根本不需要改變，這樣也使得系統(tǒng)具有很好的靈活性。 采用上述架構(gòu)的影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)也存在以下不足： (1) 由于系統(tǒng)開(kāi)發(fā)框架集成了許多封裝之后的組件，系統(tǒng)內(nèi)存開(kāi)銷比較大。 (2) 表現(xiàn)層大部分采用JS技術(shù)，由于編碼與調(diào)試效率不高等因素，開(kāi)發(fā)效率有一定影響。 (3) 靈活的開(kāi)發(fā)方式必然是以開(kāi)發(fā)的復(fù)雜性為代價(jià)的，影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)開(kāi)發(fā)起來(lái)相對(duì)復(fù)雜。 4.2 系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì) 系統(tǒng)ER圖如下圖： 圖4.3系統(tǒng)ER圖 由上圖可知，系統(tǒng)核心關(guān)系表是，文檔類別表、文檔表、文件表和文檔評(píng)論表。面對(duì)對(duì)象關(guān)系模型圖中個(gè)別屬性和類之間的相互關(guān)系進(jìn)行說(shuō)明： ? 管理員類(Admin)：存放管理員信息，其中id是主鍵，privilege是權(quán)限級(jí)別，系統(tǒng)分為高級(jí)管理員和普通管理員兩個(gè)級(jí)別。 ? 文檔類別類(Category)：存放文檔類別信息，id是數(shù)據(jù)庫(kù)表中的主鍵，沒(méi)有實(shí)際意義。parentId是父類別的id值，hasChild是否有孩子節(jié)點(diǎn)，這兩個(gè)屬性可以實(shí)現(xiàn)類別樹(shù)形結(jié)構(gòu)的顯示。state表示類別的狀態(tài)，0表示正在審核中，1表示通過(guò)審核并使用，2表示禁用。 ? 文檔類(Vd)：系統(tǒng)核心表，存放文檔信息，flag標(biāo)識(shí)上傳者是用戶還是管理員，uploaderId記錄上傳者id，level標(biāo)識(shí)文檔的保密級(jí)別。 ? 文件類(File)：記錄文件信息，vd_id標(biāo)識(shí)所屬文檔。 ? 權(quán)限類(Privilege)：存放系統(tǒng)角色權(quán)限信息。marker記錄權(quán)限標(biāo)識(shí)字符，用于和系統(tǒng)角色權(quán)限匹配從而判斷是否有其權(quán)限。selectM、selectU、selectV分別表示普通管理員、普通用戶。高級(jí)用戶是否有此權(quán)限，0表示沒(méi)有，1表示有。 ? 日志類(Log)：記錄日志信息。adminName記錄操作人員的姓名，content記錄操作明細(xì)。 ? 用戶類(User)記錄用戶信息。vip表示是否是vip，1表示是，0表示不是。 ? 評(píng)論類(Comment)：記錄文檔的評(píng)論信息。 ? 表間關(guān)系：文檔表與文件時(shí)一對(duì)多關(guān)系，與文檔類別是多對(duì)一關(guān)系，與評(píng)論是一對(duì)多關(guān)系，與用戶是多對(duì)一關(guān)系，與管理員時(shí)多對(duì)一關(guān)系。 4.3 系統(tǒng)持久層總體設(shè)計(jì) 4.3.1 系統(tǒng)持久層設(shè)計(jì)與實(shí)現(xiàn) 圖4.5是影像文檔管理內(nèi)容管理子系統(tǒng)的總體類圖。 圖4.5影像文檔管理內(nèi)容管理子系統(tǒng)的類圖 從圖中可以看出系統(tǒng)核心的類為文檔類，與它相關(guān)的包括文檔類別類、文件類、管理員類、用戶類、評(píng)論類，而與用戶和管理員相關(guān)的有權(quán)限類，最后日志類是系統(tǒng)類是獨(dú)立的一個(gè)類。 通過(guò)實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)映射成對(duì)象，很方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫(kù)，該系統(tǒng)采用Hibernate[9]作為ORM框架。它將數(shù)據(jù)庫(kù)中的表映射到j(luò)ava里的實(shí)體類，從而實(shí)現(xiàn)用面向?qū)ο蟮乃枷雭?lái)操作數(shù)據(jù)庫(kù)。避免了在面向?qū)ο蟮恼Z(yǔ)言中使用面向過(guò)程的SQL語(yǔ)句帶來(lái)的不便，降低了代碼的復(fù)雜性。Hibernate從實(shí)體到表的映射是通過(guò)映射文件來(lái)完成的，映射文件將一個(gè)POJO類映射到數(shù)據(jù)庫(kù)中相應(yīng)的表，類中的每個(gè)成員變量必須有自己的getter和setter方法，完成類的持久化和表中數(shù)據(jù)的取出工作。使用注解方式配置實(shí)體類與數(shù)據(jù)庫(kù)表的映射關(guān)系，包括主鍵生成策略、表與表的級(jí)聯(lián)關(guān)系等。并且通過(guò)配置把每個(gè)實(shí)體類交給Spring容器統(tǒng)一管理。 關(guān)鍵配置代碼與解釋： A． @Entity //表示此類為持久化對(duì)象類 B． @Id //定義此字段為表主鍵 @GeneratedValue(strategy=GenerationType.IDENTITY) //定義主鍵生成策略為自增。 C． @OneToMany //定義表的級(jí)聯(lián)關(guān)系為一對(duì)多 4.3.2 DAO層設(shè)計(jì)與實(shí)現(xiàn) DAO層基于Hibernate中間件HibernateTemplate實(shí)現(xiàn)了持久化類基本的CRUD操作。為業(yè)務(wù)邏輯層提供方便通用的接口。為了后期擴(kuò)展的靈活性，我們把DAO層分為DAO接口層和DAO實(shí)現(xiàn)層，分別定義和實(shí)現(xiàn)了數(shù)據(jù)庫(kù)操作方法。 我們以文檔管理模塊的DAO層接口設(shè)計(jì)與實(shí)現(xiàn)為例介紹一下整個(gè)系統(tǒng)的各功能模塊DAO層接口的設(shè)計(jì)與實(shí)現(xiàn)。文檔管理模塊DAO層接口包括：實(shí)現(xiàn)添加文檔、刪除文檔、更新文檔信息、查看文檔、搜索文檔等功能；具體接口的函數(shù)定義如表4.1到表4.9。 表4.1是add函數(shù)。 表4.1 add函數(shù) 函數(shù)名稱 Add 功能 添加新文檔 參數(shù) vd：文檔類型 返回值 Void 表4.2是delete函數(shù)。 表4.2 delete函數(shù) 函數(shù)名稱 Delete 功能 刪除文檔 參數(shù) vd：文檔類型 返回值 void 表4.3是deleteById函數(shù)。 表4.3 deleteById函數(shù) 函數(shù)名稱 deleteById 功能 通過(guò)文檔Id刪除文檔 參數(shù) int：文檔Id 返回值 void 表4.4是update函數(shù)。 表4.4 update函數(shù) 函數(shù)名稱 Update 功能 更新文檔 參數(shù) vd：文檔對(duì)象 返回值 void 表4.5是loadById函數(shù)。 表4.5 loadById函數(shù) 函數(shù)名稱 loadById 功能 通過(guò)文檔Id返回一個(gè)文檔記錄 參數(shù) id：文檔Id 返回值 vd：文檔對(duì)象 備注 如果查找成功返回一個(gè)文檔對(duì)象，否則返回null 表4.6是loadPageAll函數(shù)。 表4.6 loadById函數(shù) 函數(shù)名稱 loadPageAll 功能 返回文檔列表的某一頁(yè)數(shù)據(jù)集 參數(shù) start：數(shù)據(jù)起始索引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目 返回值 PagerModel：自定義對(duì)象，保存分頁(yè)顯示時(shí)當(dāng)前頁(yè)面的數(shù)據(jù)集 備注 如果查找成功返回一個(gè)PagerModel，否則返回null 表4.7是loadPageByUser函數(shù)。 表4.7 loadPageByUser函數(shù) 函數(shù)名稱 loadPageByUser 功能 返回某一用戶所有上傳文檔列表的某一頁(yè)數(shù)據(jù)集 參數(shù) start：數(shù)據(jù)起始索引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目；userId:用戶Id 返回值 PagerModel：自定義對(duì)象，保存分頁(yè)顯示時(shí)當(dāng)前頁(yè)面的數(shù)據(jù)集 備注 如果查找成功返回一個(gè)PagerModel，否則返回null 表4.8是loadPageCategory函數(shù)。 表4.8 loadPageCategory函數(shù) 函數(shù)名稱 loadPageCategory 功能 返回某一類別下文檔列表的某一頁(yè)數(shù)據(jù)集 參數(shù) start：數(shù)據(jù)起始索引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目；categoryId：類別Id 返回值 PagerModel：自定義對(duì)象，保存分頁(yè)顯示時(shí)當(dāng)前頁(yè)面的數(shù)據(jù)集 備注 如果查找成功返回一個(gè)PagerModel，否則返回null 表4.9是loadPageHighSearch函數(shù)。 表4.9 loadPageHighSearch函數(shù) 函數(shù)名稱 loadPageHighSearch 功能 返回某一類別下文檔列表的某一頁(yè)數(shù)據(jù)集 參數(shù) start：數(shù)據(jù)起始索引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目；categoryId：類別Id；key:查詢關(guān)鍵字；startD：開(kāi)始時(shí)間;endD:終止時(shí)間；type：查詢方式 返回值 PagerModel：自定義對(duì)象，保存分頁(yè)顯示時(shí)當(dāng)前頁(yè)面的數(shù)據(jù)集 備注 如果查找成功返回一個(gè)PagerModel，否則返回null 4.4 系統(tǒng)業(yè)務(wù)邏輯層總體設(shè)計(jì) Service層（就是業(yè)務(wù)邏輯層）是系統(tǒng)業(yè)務(wù)邏輯的核心，在DAO層的基礎(chǔ)上進(jìn)行業(yè)務(wù)邏輯處理。下面詳細(xì)講解Service層的設(shè)計(jì)與實(shí)現(xiàn)。 我們把系統(tǒng)業(yè)務(wù)邏輯功能模塊看作為獨(dú)立的服務(wù)模塊，將系統(tǒng)的業(yè)務(wù)且封裝為8個(gè)松散耦合的服務(wù)，每個(gè)子服務(wù)可以是相關(guān)，但是每個(gè)服務(wù)之間基本上是獨(dú)立的。這8個(gè)服務(wù)子服務(wù)接口分別是：管理員管理服務(wù)接口、文檔類別管理服務(wù)接口、文檔管理服務(wù)接口、文件管理服務(wù)接口、用戶管理服務(wù)接口、評(píng)論管理服務(wù)接口、日志管理服務(wù)接口、權(quán)限管理服務(wù)接口。圖4.5－4.12是粗粒度的服務(wù)接口方法劃分。 圖4.5是管理員管理服務(wù)接口方法劃分。該接口包括登陸驗(yàn)證、獲得管理員對(duì)象、添加管理員對(duì)象、更新管理員對(duì)象、查看管理員列表和刪除管理員對(duì)象這些方法。 圖4.5 管理員管理服務(wù)接口 圖4.6是文檔類別管理服務(wù)接口方法劃分。該接口包括添加子類別、刪除類別、查看類別信息和修改類別信息的方法。 圖4.6 課程管理服務(wù)接口 圖4.7是文檔管理服務(wù)接口方法劃分。該接口包括添加文檔、刪除文檔、查看文檔和修改文檔的方法。 圖4.7文檔管理服務(wù)接口 圖4.8是文件管理服務(wù)接口方法劃分。該接口包括添加文件、刪除文件、查看文件和更新文件的方法。 圖4.8文件管理服務(wù)接口 圖4.9是用戶管理服務(wù)接口方法劃分。該接口包括查看用戶、查看所有用戶、刪除用戶、修改用戶類型的方法。 圖4.9用戶管理服務(wù)接口 圖4.10是評(píng)論管理服務(wù)接口方法劃分。該接口包括查看用戶評(píng)論、查看文檔評(píng)論、刪除評(píng)論、批量模糊刪除評(píng)論的方法。 圖4.10 評(píng)論管理服務(wù)接口 圖4.11是日志管理服務(wù)接口方法劃分。該接口包括添加日志、查看日志、備份日志和清理日志的方法。 圖4.11 日志管理服務(wù)接口 圖4.12是權(quán)限管理服務(wù)接口方法劃分。該接口包括查看系統(tǒng)角色權(quán)限、修改角色權(quán)限的方法。 圖4.12權(quán)限管理服務(wù)接口 4.5 系統(tǒng)表現(xiàn)層總體設(shè)計(jì) 4.5.1 使用Ext的頁(yè)面布局 （參見(jiàn)第二章2.5.4節(jié)）。 在影像及電子檔案管理系統(tǒng)內(nèi)容管理子系統(tǒng)中使用Jsp與Ext結(jié)合使用，例：頁(yè)面文件：/admin/Admin_manage.jsp；Ext文件：/admin/js/admin_manage.js； Ext應(yīng)用在本系統(tǒng)中使用的原因及其優(yōu)點(diǎn)和缺點(diǎn)：基于傳統(tǒng)Jsp，要想開(kāi)發(fā)出美觀、用戶體驗(yàn)較好的頁(yè)面比較難而且開(kāi)發(fā)時(shí)間比較長(zhǎng)。Ext是基于Web的富客戶端框架，其完全是基于標(biāo)準(zhǔn)W3C技術(shù)構(gòu)建設(shè)的，使用到的都是HTML、CSS、DIV等相關(guān)技術(shù)。Ext最杰出之處，是開(kāi)發(fā)了一系列非常簡(jiǎn)單易用的控件及組件，我們只需要使用這些組件就能實(shí)現(xiàn)各種豐富多彩的UI的開(kāi)發(fā)。由于Ext屬于Javascript技術(shù)，自然帶來(lái)了長(zhǎng)久以來(lái)公認(rèn)的編碼效率慢、代碼調(diào)試與維護(hù)比較困難的缺點(diǎn)。 4.5.2 使用Ext支持的客戶端表單驗(yàn)證 Ext自我封裝了部分表單驗(yàn)證。Ext.form.TextField組件定義“allowBlank”屬性表示用戶輸入能否為空，定義“blankText”屬性顯示當(dāng)不允許為空而輸入為空的信息，定義“minLength”屬性表示最少允許輸入的字符數(shù)，定義“maxLength”屬性表示最多允許輸入的字符數(shù)。關(guān)鍵示例代碼為： allowBlank: