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

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