影像及電子檔案管理系統(tǒng)畢業(yè)論文

1、影像及電子檔案管理系統(tǒng) 引 言由于辦公自動(dòng)化的進(jìn)一步發(fā)展和深化，特別是電子計(jì)算機(jī)和通信技術(shù)相結(jié)合形成了信息技術(shù)產(chǎn)業(yè)。過去用紙墨、照像等形成的以圖書、圖紙、照片、影音、文獻(xiàn)、記錄等類型的資料信息，都可以用電子計(jì)算機(jī)進(jìn)行，由此而產(chǎn)生了電子公文、電子圖書、電子圖形圖像、電子文獻(xiàn)資料等，這些都是屬于電子文件。具有檔案保存以及利用價(jià)值的影像及電子文件，必須要?dú)w檔保護(hù)，電子文件歸檔后即形成電子檔案。為了防止大量電子檔案信息的凌亂與丟失，也為了更方便公司分類查找調(diào)用其中有用的部分信息，創(chuàng)造更多的經(jīng)濟(jì)效益，公司內(nèi)部需要一個(gè)安全且有效地系統(tǒng)來實(shí)現(xiàn)其功能。影像及電子檔案管理系統(tǒng)的開發(fā)，使公司的信息化程度提升，有助

2、于提高公司在信息時(shí)代的競(jìng)爭(zhēng)能力，適應(yīng)當(dāng)今計(jì)算機(jī)信息化高度發(fā)達(dá)的社會(huì)，這就是我所要研究的課題。本文從軟件體系結(jié)構(gòu)模式的角度入手，首先構(gòu)建了一個(gè)基于mvc模式的應(yīng)用軟件開發(fā)框架，然后在此基礎(chǔ)上設(shè)計(jì)和實(shí)現(xiàn)了影像及電子檔案管理系統(tǒng)。在介紹ssh結(jié)構(gòu)模型、ajax等理論的基礎(chǔ)上，對(duì)比已有文檔管理平臺(tái)的不足之處，著重研究如何使用這些框架和技術(shù)開發(fā)跨平臺(tái)、框架靈活、穩(wěn)定實(shí)用的影像及電子檔案管理系統(tǒng)的問題，并給出了基于struts+hibernate+spring+extjs技術(shù)的系統(tǒng)整體架構(gòu)設(shè)計(jì)和影像及電子檔案管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。論文最后討論了目前的影像及電子檔案管理系統(tǒng)有待完善和進(jìn)一步研究的問題。1.緒

3、 論1.1 項(xiàng)目背景電子檔案以其現(xiàn)代化手段,在檔案信息存儲(chǔ)、輸出、處理等方面,具有紙質(zhì)檔案無法比擬的優(yōu)越性.網(wǎng)絡(luò)化運(yùn)用引起了電子檔案的保密性、安全性、真實(shí)性、可靠性問題.因此,必須加強(qiáng)電子文件的管理。公司中存在著各種信息檔案，而如今人們已經(jīng)習(xí)慣用電腦辦公，結(jié)果自然會(huì)產(chǎn)生大量的電子文件，但我們?nèi)绻麑⒏嗟臅r(shí)間花費(fèi)在尋找這些文件上，既費(fèi)時(shí)又費(fèi)力。同時(shí)，公司文檔又關(guān)系到公司工作效率與利益問題，怎樣有效管理電子檔案成為我們必須研究與解決的問題。如今已有的電子檔案管理系統(tǒng)存在的主要問題有：?jiǎn)栴}1：原有系統(tǒng)采用單一的struts或其他的開發(fā)框架，這種方式缺少有效的模塊集成手段，基于不同平臺(tái)的模塊很難集成，

4、系統(tǒng)的可擴(kuò)展性和伸縮性比較差。一旦系統(tǒng)需求分析發(fā)生變化(此時(shí)往往已經(jīng)到了開發(fā)過程的中后期)或者系統(tǒng)需要擴(kuò)展業(yè)務(wù)，原有系統(tǒng)的框架不能很好地解決這一問題。問題2：用戶反映該系統(tǒng)的用戶界面不夠簡(jiǎn)潔，使用流程比較復(fù)雜。問題3：文檔分類方法不恰當(dāng)，危及文件信息資源的有效收集問題4：系統(tǒng)功能不完善，直接影響文件信息資源的管理水平顯然，根本的解決辦法是完善系統(tǒng)開發(fā)框架、科學(xué)的文檔分類管理與友善的用戶操作界面。待開發(fā)的系統(tǒng)借鑒了原有系統(tǒng)的功能需求，但是在使用的開發(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)用集成

5、框架的影像及電子檔案管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，在整個(gè)過程中主要完成以下工作：1影像及電子檔案管理系統(tǒng)的整體設(shè)計(jì)。在研究國內(nèi)外現(xiàn)有成果地基礎(chǔ)上完成影像及電子檔案管理系統(tǒng)的整體設(shè)計(jì)和邏輯上的模塊劃分。2研究一套靈活的系統(tǒng)整體架構(gòu)方案，以方便處理系統(tǒng)模塊間的控制和數(shù)據(jù)的集成，解決原有系統(tǒng)可維護(hù)性和擴(kuò)展性差的問題。將研究結(jié)果應(yīng)用于實(shí)際系統(tǒng)開發(fā)，為提高影像及電子檔案管理的快速開發(fā)、可維護(hù)和擴(kuò)展能力提供有效的支持。設(shè)計(jì)并實(shí)現(xiàn)影像及電子檔案管理系統(tǒng)整體后臺(tái)框架，為整個(gè)系統(tǒng)提供架構(gòu)支持。3在系統(tǒng)表現(xiàn)層方面，研究使用與后臺(tái)進(jìn)行異步交互的框架和能帶來良好用戶體驗(yàn)的技術(shù)，以提高頁面良好的展示效果。4根據(jù)需求分析，設(shè)計(jì)實(shí)

6、現(xiàn)影像及電子檔案管理核心功能，即文檔管理功能，為其他模塊提供技術(shù)借鑒與支持。5根據(jù)需求分析實(shí)現(xiàn)影像及電子檔案管理系統(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)需求分析。簡(jiǎn)要說明了影像及電子檔案管理系統(tǒng)的需求分析和不同系統(tǒng)角色的具體功能需求。第四章：首先分析了影像及電子檔案管理系統(tǒng)架構(gòu)的總體設(shè)計(jì)。重點(diǎn)介紹了基于ssh架構(gòu)的影像及電子檔案管理系統(tǒng)總體架構(gòu)的總體設(shè)計(jì)以及數(shù)據(jù)庫設(shè)計(jì)。然后分別對(duì)系統(tǒng)持久層和

7、業(yè)務(wù)邏輯層設(shè)計(jì)做了詳細(xì)介紹。第五章：介紹了影像及電子檔案管理系統(tǒng)核心模塊非共性的具體實(shí)現(xiàn)，重點(diǎn)討論了使用了ext框架的頁面組織和實(shí)現(xiàn)過程。第六章：系統(tǒng)測(cè)試與運(yùn)行。首先介紹了系統(tǒng)軟硬件部署情況，然后以貫穿系統(tǒng)配置與部署的日志管理系統(tǒng)的運(yùn)行情況說明系統(tǒng)是可實(shí)現(xiàn)的而且部署是成功的。最后以系統(tǒng)核心功能為例，使用測(cè)試用例對(duì)其進(jìn)行了測(cè)試，分析了測(cè)試結(jié)果。最后總結(jié)了全文，指出了系統(tǒng)的需要改進(jìn)的地方和進(jìn)一步的研究方向。2.相關(guān)理論與技術(shù)2.1 相關(guān)理論簡(jiǎn)介 sshssh 在j2ee項(xiàng)目中表示了3種框架,既 spring + struts + hibernate。 struts2struts21是在webwor

8、k基礎(chǔ)上發(fā)展起來的，是建立在稱為xwork的command模式框架之上的強(qiáng)大的基于web的mvc框架（參見本章2.2節(jié)）。 hibernatehibernate2是一個(gè)開放源代碼的對(duì)象關(guān)系映射框架，對(duì)jdbc進(jìn)行了輕量級(jí)的對(duì)象封裝，使得我們可以使用對(duì)象編程思維來操縱數(shù)據(jù)庫。 hibernate可以應(yīng)用在任何使用jdbc的場(chǎng)合，最具革命意義的是，hibernate可以在應(yīng)用ejb的j2ee架構(gòu)中取代cmp，完成數(shù)據(jù)持久化的重任（參見本章2.3節(jié)）。 springspring3是一個(gè)開源框架，它是為了解決企業(yè)應(yīng)用開發(fā)的復(fù)雜性而創(chuàng)建的。spring使用基本的javabean來完成以前只可能由ejb完

9、成的事情。然而，spring的用途不僅限于服務(wù)器端的開發(fā)。從簡(jiǎn)單性、可測(cè)試性和松耦合的角度而言，任何java應(yīng)用都可以從spring中受益（參見本章2.4節(jié)）。 ajaxajax4全稱為“asynchronous javascript and xml”(異步j(luò)avascript和xml)，是指一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)。ajax并不是一種新產(chǎn)生出來的技術(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)定性、性能等各方面都有很好的保證：

10、而且吸收了struts 1和webwork兩者的優(yōu)勢(shì)。struts2是一個(gè)優(yōu)雅的，可擴(kuò)展的java ee web5框架?？蚣茉O(shè)計(jì)的目標(biāo)貫穿整個(gè)開發(fā)周期，從開發(fā)到發(fā)布，包括維護(hù)的整個(gè)過程。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年代為編程語言smalltalk-80發(fā)明的一種軟件架構(gòu)模式。它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開。使用m

11、vc應(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è)文檔信息的視圖只接受來自模型的數(shù)據(jù)并顯示給用戶，以及將用戶界面的輸入數(shù)據(jù)和請(qǐng)求傳遞給控制和模型。模型(model)表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在mvc的三個(gè)部件中，模型擁有最多的處理任務(wù)。例如它可能用如ejbs和co

12、ldfusion components這樣的構(gòu)件對(duì)象來處理數(shù)據(jù)庫。被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性?？刂?controller)可以理解為從用戶接收請(qǐng)求, 將模型與視圖匹配在一起，共同完成用戶的請(qǐng)求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個(gè)分發(fā)器，選擇什么樣的模型，選擇什么樣的視圖，可以完成什么樣的用戶請(qǐng)求?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。例如，用戶點(diǎn)擊一個(gè)連接，控制層接受請(qǐng)求后, 并不處理業(yè)務(wù)信息，它只把用戶的信息傳遞給模型，告訴模型做什么，選擇符合要求的視

13、圖返回給用戶。因此，一個(gè)模型可能對(duì)應(yīng)多個(gè)視圖，一個(gè)視圖可能對(duì)應(yīng)多個(gè)模型。模型、視圖與控制器的分離，使得一個(gè)模型可以具有多個(gè)顯示視圖。如果用戶通過某個(gè)視圖的控制器改變了模型的數(shù)據(jù)，所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此，無論何時(shí)發(fā)生了何種數(shù)據(jù)變化，控制器都會(huì)將變化通知所有的視圖，導(dǎo)致顯示的更新。這實(shí)際上是一種模型的變化-傳播機(jī)制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能2.3 hibernate的核心技術(shù)hibernate是一種java語言下的對(duì)象關(guān)系映射解決方案。 它是一種自由、開源的軟件。它用來把對(duì)象模型表示的對(duì)象映射到基于sql 的關(guān)系模型結(jié)構(gòu)中去，為面向?qū)ο蟮念I(lǐng)域模

14、型到傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的映射，提供了一個(gè)使用方便的框架。 hibernate 不僅管理java類到數(shù)據(jù)庫表的映射（包括從java數(shù)據(jù)類型到sql數(shù)據(jù)類型的映射），還提供數(shù)據(jù)查詢和獲取數(shù)據(jù)的方法，可以大幅度減少開發(fā)時(shí)人工使用sql 和jdbc 處理數(shù)據(jù)的時(shí)間。hibernate對(duì)jdbc進(jìn)行了非常輕量級(jí)的對(duì)象封裝，使得java程序員可以隨心所欲的使用對(duì)象編程思維來操縱數(shù)據(jù)庫。 hibernate可以應(yīng)用在任何使用jdbc的場(chǎng)合，它既可以在java的客戶端程序使用，也可以在servlet/jsp的web應(yīng)用中使用。最具革命意義的是，hibernate可以在應(yīng)用ejb（enterprise java

15、beans是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)用開發(fā)的“一站式”選擇，并貫穿表現(xiàn)層、業(yè)務(wù)層及持久層。然而，spring并不想取代那些已有的框架，而是與它們無縫地整合。控制翻轉(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)中由程序代碼直接操控，這種將控制

16、權(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ī)制，通過配置文件管理組建的協(xié)作對(duì)象，創(chuàng)建可以構(gòu)造組件的ioc容器。這樣，不需要編寫工廠模式、單例模式或者其他構(gòu)造的方法，就可以通過容器直接獲取所需的業(yè)務(wù)組件。spring框架的結(jié)構(gòu)如圖2.2所示。圖2.2 spring框架模塊組成spring框架由七個(gè)定義明確的模塊組成，且每個(gè)模塊或組件都可以單獨(dú)存在，或者與其他一個(gè)或多個(gè)模塊聯(lián)合實(shí)現(xiàn)。spring

17、core container是一個(gè)用來管理業(yè)務(wù)組件的ioc容器，是spring應(yīng)用的核心；spring dao和spring orm不僅提供數(shù)據(jù)訪問的抽象模塊，還集成了對(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í)它也是模塊化的框架，允許開發(fā)人員自由地挑選適合自己應(yīng)用的模塊進(jìn)行開發(fā)

18、。spring框架式是一個(gè)松耦合的框架，框架的部分耦合度被設(shè)計(jì)為最小，在各個(gè)層次上具體選用哪個(gè)框架取決于開發(fā)者的需要。2.5 ajax技術(shù)ajax的核心是javascript對(duì)象xmlhttprequest。它是一種支持異步請(qǐng)求的技術(shù)。javascript可以在不刷新頁面的情況下從服務(wù)器獲取數(shù)據(jù)，或者向服務(wù)器提交數(shù)據(jù)，靈活地實(shí)現(xiàn)了數(shù)據(jù)異步交互。我們知道，傳統(tǒng)的web應(yīng)用是同步交互的方式。這種同步交互方式的處理過程如圖2.3所示。圖4.14 同步交互方式用戶向服務(wù)器提交了一個(gè)處理請(qǐng)求時(shí)，服務(wù)器端接受到該請(qǐng)求后，和數(shù)據(jù)庫服務(wù)器進(jìn)行數(shù)據(jù)信息的交換，然后對(duì)請(qǐng)求處理進(jìn)行相應(yīng)，即將結(jié)果傳送回發(fā)出請(qǐng)求的瀏覽

19、器客戶端，返回一個(gè)html頁面在瀏覽器端進(jìn)行顯示。顯然，這樣的一種處理方式會(huì)給用戶一種不連貫的體驗(yàn)，因?yàn)楫?dāng)服務(wù)器在處理請(qǐng)求的時(shí)候，用戶多數(shù)時(shí)間只能處于等待狀態(tài)，頁面中顯示的內(nèi)容也只能時(shí)一片空白。與傳統(tǒng)的web應(yīng)用不同，ajax采用的是一種異步交互的處理方式。這種異步交互的處理過程如圖2.4所示。圖2.4 使用ajax的異步交互模式ajax相當(dāng)于在瀏覽器客戶端與服務(wù)器之間架設(shè)了一個(gè)橋梁，在它的幫助下，可以消除網(wǎng)絡(luò)交互過程中的處理等待處理等待的缺陷。在處理過程中web服務(wù)器響應(yīng)是標(biāo)準(zhǔn)的且易于解析的xml格式的數(shù)據(jù)傳遞到ajax，然后再轉(zhuǎn)換成html頁面的格式，輔助css進(jìn)行顯示。ajax是傳統(tǒng)we

20、b應(yīng)用程序的一個(gè)轉(zhuǎn)變。ajax可以所為客戶端和服務(wù)器的中間層，來處理客戶端的請(qǐng)求，并根據(jù)需要向服務(wù)器端發(fā)送請(qǐng)求，用什么就取什么、用多少就取多少，就不會(huì)有數(shù)據(jù)的冗余和浪費(fèi)，減少了數(shù)據(jù)下載總量，而且更新頁面時(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ù)訪問及合法性校驗(yàn)等工作放在中間層處理?？蛻舳瞬恢苯优c數(shù)據(jù)庫交互，而是通過組件與中間層建立連接，再由中間層與數(shù)據(jù)庫交互。表

21、現(xiàn)層是傳統(tǒng)的jsp6技術(shù)，其廣泛的應(yīng)用和穩(wěn)定的表現(xiàn)，為其作為表現(xiàn)層技術(shù)打下了堅(jiān)實(shí)的基礎(chǔ)。中間層采用的是流行的spring+hibernate，為了將控制層與業(yè)務(wù)邏輯層分離，又細(xì)分為以下幾種。web層，就是mvc7模式里面的控制器，負(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ǔ)，通過對(duì)dao組件的正面模式包裝，完成系統(tǒng)所要求的業(yè)務(wù)邏輯。dao層，負(fù)責(zé)與持久化對(duì)象交互。po，持久化對(duì)象。通過實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫8的數(shù)據(jù)映射成對(duì)象，方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫，采用

22、hibernate作為orm框架。spring的作用貫穿了整個(gè)中間層，將web層、service層、dao層及po無縫整合，其數(shù)據(jù)服務(wù)層用來存放數(shù)據(jù)。3.需求分析3.1 系統(tǒng)需求分析3.1.1 系統(tǒng)角色根據(jù)影像及電子檔案管理系統(tǒng)的實(shí)際需求，系統(tǒng)整體的用戶包括普通管理員、高級(jí)管理員以及普通用戶、高級(jí)用戶。而后臺(tái)影像及電子檔案管理系統(tǒng)的用戶角色為普通管理員和高級(jí)管理員。下面是對(duì)上述不同角色的需求分析。3.1.2 需求分析圖3.1表示普通管理員系統(tǒng)功能用例圖。如圖普通管理員功能分為登陸、類別管理、文檔管理、日志管理、評(píng)論管理和用戶管理。具體功能分析如下：(1) 普通管理員需求分析。 管理員登錄：不同

23、的用戶功能和權(quán)限不同，所以不同的用戶必須先進(jìn)行登錄驗(yàn)證，只有驗(yàn)證通過才能夠進(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)

24、行管理，例如：查看用戶評(píng)論、刪除多條用戶評(píng)論和按關(guān)鍵字批量刪除評(píng)論。 日志管理（高級(jí)管理員授權(quán)情況下）：普通管理員登錄后可以對(duì)管理員操作日志進(jìn)行管理，例如：查看日志信息、備份日志與清理日志。(2) 高級(jí)管理員需求分析。圖3.3表示高級(jí)管理員系統(tǒng)功能用例圖高級(jí)管理員可以執(zhí)行系統(tǒng)所有操作，除了普通管理員的所有需求外，還包括管理員管理和權(quán)限管理，此角色的系統(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)的需求分析，按照不

25、同的角色將功能需求用用例圖的方式列出。然后為了更深入的了解系統(tǒng)需求，使用功能結(jié)構(gòu)圖對(duì)系統(tǒng)按角色進(jìn)行了功能分析。4. 系統(tǒng)總體設(shè)計(jì)4.1 系統(tǒng)架構(gòu)總體設(shè)計(jì)根據(jù)需求分析，這一節(jié)詳細(xì)討論了影像及電子檔案管理系統(tǒng)的總體架構(gòu)設(shè)計(jì)方案。4.1.1 傳統(tǒng)開發(fā)框架到ssh框架經(jīng)典的網(wǎng)站系統(tǒng)是基于struts+hibernate的框架進(jìn)行設(shè)計(jì)和開發(fā)的。這種開發(fā)框架的好處是實(shí)現(xiàn)簡(jiǎn)單，業(yè)務(wù)邏輯清晰，開發(fā)人員使用起來很容易。因此在實(shí)際開發(fā)時(shí)可以把后臺(tái)業(yè)務(wù)邏輯代碼放到設(shè)計(jì)好的javabean中，按照上述功能結(jié)構(gòu)圖的模塊劃分方式，每個(gè)模塊都是一個(gè)單獨(dú)的javabean類，控制層代碼直接使用這些類完成實(shí)際功能。雖然上述的開

26、發(fā)框架可以很好的解決電子檔案管理中的應(yīng)用開發(fā)面臨的問題，但是實(shí)際應(yīng)用表明這存在著一些弱點(diǎn)。首先是復(fù)用的層次較低，開發(fā)框架主要著眼于對(duì)象類的復(fù)用，而這些復(fù)用是代碼級(jí)的復(fù)用，代碼級(jí)的復(fù)用方式帶來的壞處是涉及實(shí)現(xiàn)細(xì)節(jié)，不支持可插拔的軟件構(gòu)件思想；其次是粒度較小，開發(fā)框架中主要實(shí)現(xiàn)的是一些通用功能或者常規(guī)操作，沒有比較大粒度的構(gòu)件復(fù)用，雖然存在一定程度的獨(dú)立的業(yè)務(wù)代碼類，但是依然離不開實(shí)現(xiàn)細(xì)節(jié)；最后就是使用人員的定位問題，使用開發(fā)框架的基本上是了解熟悉此類框架的軟件開發(fā)專業(yè)技術(shù)人員，而對(duì)于不熟悉這種開發(fā)框架的業(yè)務(wù)人員而言，無法滿足他們隨著需求變更修改系統(tǒng)或者自主開發(fā)小應(yīng)用的需要。為此，本文提出了比開發(fā)

27、框架層次更高的ssh框架構(gòu)件平臺(tái)來實(shí)現(xiàn)具體的應(yīng)用。ssh框架構(gòu)件平臺(tái)主要是為了適應(yīng)復(fù)雜多變的公司文檔信息管理的業(yè)務(wù)需求而提出的業(yè)務(wù)支撐平臺(tái)，該平臺(tái)的目標(biāo)是支持開發(fā)人員通過統(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)為例，進(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ì)和開發(fā)人員在拿到業(yè)務(wù)需求后，會(huì)立即想到是不是需要使用struts的mvc結(jié)構(gòu)，是使用e

28、jb還是使用hibernate，是使用什么樣的服務(wù)器和數(shù)據(jù)庫等。然后系統(tǒng)架構(gòu)師和每個(gè)業(yè)務(wù)人員進(jìn)行溝通并且劃分每個(gè)業(yè)務(wù)模塊，業(yè)務(wù)人員再向每個(gè)模塊填寫相應(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ī)劃旨在減輕開發(fā)人員重新建立解決復(fù)雜問題方案的負(fù)擔(dān)和精力；它可以被擴(kuò)展以進(jìn)行內(nè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)系

29、，應(yīng)用框架由上向下可分為持久層、邏輯層、業(yè)務(wù)層、控制層和表現(xiàn)層。其中上層構(gòu)件為下層提供了獨(dú)立完整的功能，下層構(gòu)件無需了解上層構(gòu)件內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，只需要調(diào)用其提供的明確定義的接口和方法來實(shí)現(xiàn)自己的功能。應(yīng)用框架的分層機(jī)制負(fù)責(zé)將用戶的業(yè)務(wù)需求分為相對(duì)獨(dú)立的層次化模塊，支持開發(fā)人員方便快速地開發(fā)相對(duì)獨(dú)立的業(yè)務(wù)單元?；趍vc模式，系統(tǒng)分為表現(xiàn)層、中間層（業(yè)務(wù)邏輯層）和數(shù)據(jù)服務(wù)層。三層體系將業(yè)務(wù)規(guī)則、數(shù)據(jù)訪問及合法性校驗(yàn)等工作放在中間層處理?？蛻舳瞬恢苯优c數(shù)據(jù)庫交互，而是通過組件與中間層建立連接，再由中間層與數(shù)據(jù)庫交互。表現(xiàn)層使用基于jsp顯示，extjs組件為主體的開發(fā)模式。中間層采用的是流行的sp

30、ring+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ǔ)，通過對(duì)dao組件的正面模式包裝，完成系統(tǒng)所要求的業(yè)務(wù)邏輯。dao層，負(fù)責(zé)與持久化對(duì)象交互。該層封裝了數(shù)據(jù)的增、刪、查、改的操作，采用數(shù)據(jù)庫中間件hibernate完成對(duì)底層數(shù)據(jù)庫應(yīng)用的封裝，通過一致的規(guī)范接口，將底層數(shù)據(jù)庫與業(yè)務(wù)邏輯分離開來，為應(yīng)用系統(tǒng)的業(yè)務(wù)代碼開發(fā)

31、提供了數(shù)據(jù)層支持。po，持久化對(duì)象。通過實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)映射成對(duì)象，很方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫，該系統(tǒng)采用hibernate作為orm框架，并使用注解方式實(shí)現(xiàn)數(shù)據(jù)映射配置。spring的作用貫穿了整個(gè)中間層，將web層、service層、dao層及po無縫整合，依靠spring依賴注入特性web層中注入service、service層中注入dao、dao層中注入hibernatetemplate，其數(shù)據(jù)服務(wù)層用來存放數(shù)據(jù)。為了提高系統(tǒng)的可擴(kuò)展性與可維護(hù)性，在dao層與service層分別抽取出接口層和接口實(shí)現(xiàn)層。4.1.3 ssh架構(gòu)在系統(tǒng)中的應(yīng)用圖4.2是影像及

32、電子檔案管理系統(tǒng)的整體架構(gòu)圖。圖4.2 影像及電子檔案管理系統(tǒng)的整體架構(gòu)圖下面是對(duì)圖4.2中各層的角色及功能說明。(1)view層：影像及電子檔案管理系統(tǒng)的視圖展示，用戶頁面采用ext框架進(jìn)行組織，數(shù)據(jù)從后臺(tái)轉(zhuǎn)發(fā)過來使用jsp的方式，然后在客戶端轉(zhuǎn)換成html頁面的格式，借助javascript和css進(jìn)行顯示。(2)controller層：影像及電子檔案管理系統(tǒng)的控制層，使用struts的控制層來進(jìn)行業(yè)務(wù)流程控制。控制器是應(yīng)用系統(tǒng)處理具體流程和導(dǎo)向的核心部分。它把模型對(duì)象給出的信息轉(zhuǎn)換成視圖可以理解的形式，并且處理系統(tǒng)流程的走向。在這里使用struts.xml配置文件來定義業(yè)務(wù)流程，使用ac

33、tion類調(diào)用相應(yīng)的web service來實(shí)現(xiàn)這些具體功能。(3)model層：影像及電子文檔管理系統(tǒng)的模型層，實(shí)現(xiàn)具體的業(yè)務(wù)邏輯。模型包含應(yīng)用程序的核心功能，封裝了應(yīng)用程序的狀態(tài)，它對(duì)視圖或控制器一無所知。數(shù)據(jù)庫中間件方面，系統(tǒng)定義了dao層，使用集成封裝的hibernatetemplate實(shí)現(xiàn)數(shù)據(jù)操作。系統(tǒng)使用annotation（注解）方式配置實(shí)體類與數(shù)據(jù)庫的映射關(guān)系，包括主鍵生成策略、表與表的級(jí)聯(lián)關(guān)系配置等。4.1.4 ssh架構(gòu)的優(yōu)勢(shì)與不足傳統(tǒng)的網(wǎng)站系統(tǒng)采用單一的struts+hibernate框架進(jìn)行設(shè)計(jì)和開發(fā)，在這種方式下，客戶端代碼和業(yè)務(wù)邏輯代碼混雜在一起，而且模塊化劃分不夠

34、靈活，各個(gè)業(yè)務(wù)模塊之間的耦合度較高。傳統(tǒng)的應(yīng)用沒有完全遵循軟件可重用性的原則，可重用性僅僅體現(xiàn)在本地的代碼可重用性，而對(duì)于更廣范圍的數(shù)據(jù)和代碼的可重用性，并沒有相應(yīng)的支持。與傳統(tǒng)的網(wǎng)站系統(tǒng)應(yīng)用相比，基于ssh框架的影像及電子檔案管理系統(tǒng)架構(gòu)有如下優(yōu)點(diǎn)：開發(fā)效率高一個(gè)良好的框架可以讓開發(fā)人員減輕重新建立解決復(fù)雜問題方案的負(fù)擔(dān)和精力；它可以被擴(kuò)展以進(jìn)行內(nèi)部的定制化；并且有強(qiáng)大的用戶社區(qū)來支持它?？蚣芡ǔＤ芎芎玫慕鉀Q一個(gè)問題。后期維護(hù)效率高軟件工程不同于傳統(tǒng)的工業(yè)，例如電器、建筑及汽車等行業(yè)。這些行業(yè)的產(chǎn)品一旦開發(fā)出來，交付用戶使用后將很少需要后續(xù)的維護(hù)。軟件產(chǎn)品的后期運(yùn)行維護(hù)是個(gè)巨大的工程。傳統(tǒng)的

35、asp和 php等腳本站點(diǎn)技術(shù)，將整個(gè)站點(diǎn)的業(yè)務(wù)邏輯和表現(xiàn)邏輯都混雜在asp或php頁面里，從而導(dǎo)致頁面的可讀性相當(dāng)差，可維護(hù)性非常低。但采用嚴(yán)格分層j2ee架構(gòu)，則可完全避免這個(gè)問題。對(duì)表現(xiàn)層的修改即使發(fā)生錯(cuò)誤，也絕對(duì)不會(huì)將錯(cuò)誤擴(kuò)展到業(yè)務(wù)邏輯層，更不會(huì)影響持久層。因此，采用j2ee分層架構(gòu)，即使前期的開發(fā)效率稍微低一點(diǎn)，但也是值得的。 系統(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ò)清晰。系統(tǒng)需求擴(kuò)展性強(qiáng)幾乎所有的軟件需求都是在變化的?？蛻魧?duì)軟件需求，是隨

36、著軟件開發(fā)過程的深入，不斷明晰起來的。因此，常常遇到軟件開發(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ā)

37、生改變，將意味著放棄整個(gè)頁面，或者改寫。采用hibernate作為持久層技術(shù)的最大的好處在于：可以完全以面向?qū)ο蟮姆绞竭M(jìn)行系統(tǒng)分析、系統(tǒng)設(shè)計(jì)。系統(tǒng)技術(shù)擴(kuò)展性強(qiáng)struts、hibernate、spring都是開源框架，這同樣是優(yōu)勢(shì)之一。如struts支持多種插件，在本系統(tǒng)中使用到了jfreechart實(shí)現(xiàn)了系統(tǒng)統(tǒng)計(jì)的功能。更高的系統(tǒng)靈活性 系統(tǒng)的頁面和服務(wù)開發(fā)相互分離，這就使得在需求確定的情況下，系統(tǒng)的表現(xiàn)層和服務(wù)層的開發(fā)能夠同時(shí)進(jìn)行，大大減少了系統(tǒng)開發(fā)周期。另外，頁面和業(yè)務(wù)的分離降低了表現(xiàn)層和服務(wù)層的耦合度，一旦頁面發(fā)生改變，服務(wù)層根本不需要改變，這樣也使得系統(tǒng)具有很好的靈活性。采用上述架構(gòu)

38、的影像及電子檔案管理系統(tǒng)也存在以下不足：(1) 由于系統(tǒng)開發(fā)框架集成了許多封裝之后的組件，系統(tǒng)內(nèi)存開銷比較大。(2) 表現(xiàn)層大部分采用js技術(shù)，由于編碼與調(diào)試效率不高等因素，開發(fā)效率有一定影響。(3) 靈活的開發(fā)方式必然是以開發(fā)的復(fù)雜性為代價(jià)的，影像及電子檔案管理系統(tǒng)開發(fā)起來相對(duì)復(fù)雜。4.2 系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)系統(tǒng)核心關(guān)系表是，文檔類別表、文檔表、文件表和文檔評(píng)論表。面對(duì)對(duì)象關(guān)系模型圖中個(gè)別屬性和類之間的相互關(guān)系進(jìn)行說明： 管理員類(admin)：存放管理員信息，其中id是主鍵，privilege是權(quán)限級(jí)別，系統(tǒng)分為高級(jí)管理員和普通管理員兩個(gè)級(jí)別。 文檔類別類(category)：存放文檔類別信息

39、，id是數(shù)據(jù)庫表中的主鍵，沒有實(shí)際意義。parentid是父類別的id值，haschild是否有孩子節(jié)點(diǎn)，這兩個(gè)屬性可以實(shí)現(xiàn)類別樹形結(jié)構(gòu)的顯示。state表示類別的狀態(tài)，0表示正在審核中，1表示通過審核并使用，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、select

40、v分別表示普通管理員、普通用戶。高級(jí)用戶是否有此權(quán)限，0表示沒有，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)系。數(shù)據(jù)字典：管理員表（admin）字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int111管理員姓名varchar100密碼varchar100性別int1e-mailvarchar

41、100工作名稱varchar100權(quán)限int2用戶表（user）字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int111姓名varchar100密碼varchar100生日date0工作號(hào)int11emailvarchar100vipint11電話varchar100權(quán)限表（privilege）字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int101姓名varchar100類型int1生日int1工作號(hào)varchar1000評(píng)論表(comment)字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int111vdidint11內(nèi)容varchar1000日期datetime0聲明int11文件表(file)字段名數(shù)據(jù)類型長(zhǎng)度

42、允許為空主鍵id int111vdidint11 姓名varchar100擴(kuò)展名varchar100類型int11路徑varchar200日志表(log)字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int111.管理員姓名varchar100 內(nèi)容varchar2000日期datetime0文檔類別表（category）字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int101姓名varchar100父類idint1子類int1描述varchar1000聲明int11影像及電子檔案表(vd)字段名數(shù)據(jù)類型長(zhǎng)度允許為空主鍵id int111類別號(hào)int11姓名varchar100日期datetime0標(biāo)志int1

43、1上傳號(hào)int11級(jí)別int11主題varchar200記錄varchar10004.3 系統(tǒng)持久層總體設(shè)計(jì)4.3.1 系統(tǒng)持久層設(shè)計(jì)與實(shí)現(xiàn)圖4.5是影像及電子檔案管理系統(tǒng)的總體類圖。圖4.5影像以電子檔案管理系統(tǒng)的類圖從圖中可以看出系統(tǒng)核心的類為文檔類，與它相關(guān)的包括文檔類別類、文件類、管理員類、用戶類、評(píng)論類，而與用戶和管理員相關(guān)的有權(quán)限類，最后日志類是系統(tǒng)類是獨(dú)立的一個(gè)類。通過實(shí)體關(guān)系映射工具將關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)映射成對(duì)象，很方便地實(shí)現(xiàn)以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)庫，該系統(tǒng)采用hibernate9作為orm框架。它將數(shù)據(jù)庫中的表映射到j(luò)ava里的實(shí)體類，從而實(shí)現(xiàn)用面向?qū)ο蟮乃枷雭聿僮鲾?shù)據(jù)庫。避

44、免了在面向?qū)ο蟮恼Z言中使用面向過程的sql語句帶來的不便，降低了代碼的復(fù)雜性。hibernate從實(shí)體到表的映射是通過映射文件來完成的，映射文件將一個(gè)pojo類映射到數(shù)據(jù)庫中相應(yīng)的表，類中的每個(gè)成員變量必須有自己的getter和setter方法，完成類的持久化和表中數(shù)據(jù)的取出工作。使用注解方式配置實(shí)體類與數(shù)據(jù)庫表的映射關(guān)系，包括主鍵生成策略、表與表的級(jí)聯(lián)關(guān)系等。并且通過配置把每個(gè)實(shí)體類交給spring容器統(tǒng)一管理。關(guān)鍵配置代碼與解釋：a entity /表示此類為持久化對(duì)象類b id /定義此字段為表主鍵generatedvalue(strategy=generationtype.identi

45、ty) /定義主鍵生成策略為自增。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ù)庫操作方法。我們以文檔管理模塊的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

46、函數(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：文檔對(duì)象返回值void表4.5是loadbyid函數(shù)。表4.5 loadbyid函數(shù)函數(shù)名稱loadbyid功能通過文檔id返回一個(gè)文檔記錄參

47、數(shù)id：文檔id返回值vd：文檔對(duì)象備注如果查找成功返回一個(gè)文檔對(duì)象，否則返回null表4.6是loadpageall函數(shù)。表4.6 loadbyid函數(shù)函數(shù)名稱loadpageall功能返回文檔列表的某一頁數(shù)據(jù)集參數(shù)start：數(shù)據(jù)起始索引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目返回值pagermodel：自定義對(duì)象，保存分頁顯示時(shí)當(dāng)前頁面的數(shù)據(jù)集備注如果查找成功返回一個(gè)pagermodel，否則返回null表4.7是loadpagebyuser函數(shù)。表4.7 loadpagebyuser函數(shù)函數(shù)名稱loadpagebyuser功能返回某一用戶所有上傳文檔列表的某一頁數(shù)據(jù)集參數(shù)start：數(shù)據(jù)起始索

48、引；limit：數(shù)據(jù)集中數(shù)據(jù)的數(shù)目；userid:用戶id返回值pagermodel：自定義對(duì)象，保存分頁顯示時(shí)當(dāng)前頁面的數(shù)據(jù)集備注如果查找成功返回一個(gè)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：自定義對(duì)象，保存分頁顯示時(shí)當(dāng)前頁面的數(shù)據(jù)集備注如果查找成功返回一個(gè)pagermodel，否則返回null表4.9是l

49、oadpagehighsearch函數(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：開始時(shí)間;endd:終止時(shí)間；type：查詢方式返回值pagermodel：自定義對(duì)象，保存分頁顯示時(shí)當(dāng)前頁面的數(shù)據(jù)集備注如果查找成功返回一個(gè)pagermodel，否則返回null4.4 系統(tǒng)業(yè)務(wù)邏輯層總體設(shè)計(jì)service層（就是業(yè)務(wù)邏輯層）是系統(tǒng)業(yè)務(wù)邏輯的核心，在dao層的基礎(chǔ)上進(jìn)行業(yè)務(wù)邏輯處

50、理。下面詳細(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.54.12是粗粒度的服務(wù)接口方法劃分。圖4.5是管理員管理服務(wù)接口方法劃分。該接口包括登陸驗(yàn)證、獲得管理員對(duì)象、添加管理員對(duì)象、更新管理員對(duì)象、查看管理員列表和刪除管理員對(duì)象這些方法。圖4.5 管理員管理服務(wù)接口圖4.6是文檔類

51、別管理服務(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)論

52、管理服務(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的頁面布局（參見第二章2.5.4節(jié)）。在影像及電子檔案管理系統(tǒng)中使用jsp與ext結(jié)合使用，例：頁面文件：/admin/admin_manage.jsp；ext文件：/admin/js/admin_manage.js；ext應(yīng)用在本系統(tǒng)中使用的原因及其優(yōu)點(diǎn)和缺點(diǎn)：基于傳統(tǒng)jsp，要想開發(fā)出美觀、用戶體驗(yàn)較

53、好的頁面比較難而且開發(fā)時(shí)間比較長(zhǎng)。ext是基于web的富客戶端框架，其完全是基于標(biāo)準(zhǔn)w3c技術(shù)構(gòu)建設(shè)的，使用到的都是html、css、div等相關(guān)技術(shù)。ext最杰出之處，是開發(fā)了一系列非常簡(jiǎn)單易用的控件及組件，我們只需要使用這些組件就能實(shí)現(xiàn)各種豐富多彩的ui的開發(fā)。由于ext屬于javascript技術(shù)，自然帶來了長(zhǎng)久以來公認(rèn)的編碼效率慢、代碼調(diào)試與維護(hù)比較困難的缺點(diǎn)。4.5.2 使用ext支持的客戶端表單驗(yàn)證ext自我封裝了部分表單驗(yàn)證。ext.form.textfield組件定義“allowblank”屬性表示用戶輸入能否為空，定義“blanktext”屬性顯示當(dāng)不允許為空而輸入為空的信息

54、，定義“minlength”屬性表示最少允許輸入的字符數(shù)，定義“maxlength”屬性表示最多允許輸入的字符數(shù)。關(guān)鍵示例代碼為：allowblank:false,blanktext:此處不允許為空,minlength: 6,maxlength:20ext封裝的ext.form.vtypes類可以對(duì)客戶端輸入信息進(jìn)行驗(yàn)證，其原理是使用正則表達(dá)式的判斷方式。舉例說明，如：ext.form.textfield組件屬性“vtype”可以指定輸入信息的格式如：“email”表示郵件格式等。ext還支持自定義ext客戶端表單驗(yàn)證。使用apply來附加驗(yàn)證類型到ext.form.vtypes類里面，fun

55、ction(val,field)中的參數(shù)是規(guī)定好的，val是value，是應(yīng)用驗(yàn)證的控件獲得的值，field是對(duì)象，是當(dāng)前應(yīng)用的對(duì)象，field.confirmto是綁定的對(duì)象。4.5.3 ext封裝的ajax技術(shù)的使用ext很好的封裝了自己的ajax請(qǐng)求方法，使用起來十分方便。由于系統(tǒng)頁面使用ext框架的布局管理，就需要和struts能夠很好的進(jìn)行交互。ext屬于avascript擴(kuò)展框架，我們選用json數(shù)據(jù)格式傳遞數(shù)據(jù)。json(javascript object notation) 是一種輕量級(jí)的數(shù)據(jù)交換格式。易于人閱讀和編寫，同時(shí)也易于機(jī)器解析和生成。它基于javascript（standard ecma-262 3rd edition - december 1999）的一個(gè)子集。 json