【文章內(nèi)容簡介】 查找錯誤的，因為試卷過多，從新將試卷分類、統(tǒng)計是不可行的，而在數(shù)據(jù)庫中，后臺管理人員只需要對數(shù)據(jù)庫操作就可以找到任意一位學(xué)生的試卷或?qū)W生信息。 在硬件方面，開發(fā)本程序?qū)τ布幸欢ㄒ?，由于涉及到服?wù)器與數(shù)據(jù)庫的應(yīng)用，因此對電腦的內(nèi)存、 cpu 等有一定要求，不過目前市場上的電腦一般都能滿足條件。 操作可行性 Java 語言在用戶體驗度上的良好性能和安全的架構(gòu)，能夠讓考生很輕易的掌握對該系統(tǒng)的操作。 開發(fā)環(huán)境配置 Windows 系統(tǒng)在市場上的占有率毋庸置疑， windows 的良好性能讓越來越多的企業(yè)選擇作為 PC 平臺，從程序開發(fā)的角度來看，在 windows 系統(tǒng)上對程序的開發(fā)和部署都 9 十分高效；在應(yīng)用階段時則不考慮應(yīng)用環(huán)境的配置，因為 java 語言的跨平臺型十分良好，無論是 linux、 unix、 mac 還是 windows 系統(tǒng)都可以執(zhí)行， java 語言具有“一次編譯到處執(zhí)行”的優(yōu)點。下面是開發(fā)環(huán)境的具體配置： ： MyEclipse ： Dreamweaver 8 ： ： Apache ：安裝 支持 Java 運行。 ： JSP， SSH 框架。 MVC 和 B/S 模式。 10 第三章 相關(guān)技術(shù)簡介 MVC 模式 圖 圖 為 MVC 編程模式結(jié)構(gòu)圖，全名為 Model View Controller，這是一種軟件設(shè)計典范，這種模式將業(yè)務(wù)邏輯與數(shù)據(jù)顯示分離，傳統(tǒng)的 web 開發(fā)中，將地址的處理、頁面參數(shù)的處理和頁面的轉(zhuǎn)向集合到一個類中，在地址處理中用大量的 ifelse 語句然后再 if語句中處理頁面參數(shù)并完成頁面轉(zhuǎn)向，這種開發(fā)模式適用于小型項目，在大型項目中這種模式不利于項目的維護(hù)，而且會使得程序的結(jié)構(gòu)十分繁重。 隨著編程技術(shù)不斷進(jìn)步，人們急需一種編程思想解決這種問題，于是 MVC 模式的誕生解決 了這些問題，目前 MVC 編程模式在全世界范圍內(nèi)十分流行， MVC 模式中將數(shù)據(jù)處理、邏輯處理封裝到 Model 里面，將頁面交給 jsp 完成，而 Controller 的任務(wù)是負(fù)責(zé) Model 中數(shù)據(jù)處理完畢后選擇合適的頁面。 這種模式完全符合人們希望將程序中不同功能的模塊分開的愿望，這樣使得程序前期分析變得十分清晰，所以一旦完成了程序分析階段，再根據(jù) MVC 模式中每個模塊的任務(wù)編程，就使得程序員的任務(wù)變輕，也不容易出錯，更重要的是程序的維護(hù)變得方便，在修改程序時按照程序所需要修改的地方來改，不會影響其他部分的功能，程序的結(jié)構(gòu)一 旦清晰，使得程序分析、數(shù)據(jù)關(guān)系建立、程序編寫、代碼維護(hù)甚至在與客戶溝通的時候也十分容易理解。 Model View Controller 11 MVC 模式的優(yōu)缺點 度降低 將界面 層和業(yè)務(wù)層 分開后 ， 更改界面層的代碼就不用改變模型和控制器的代碼 ， 同理 ， 改變一個程序的業(yè)務(wù)邏輯只需要修改 MVC 中模型層的代碼就可以 。 由于 模型與控制器 還有 視圖 這三個層次之間是相互分離的 ， 因此改變業(yè)務(wù)邏輯變得十分方便 。 模型 中的細(xì)則 是 由自己來定義的 ，并且 是和 控制器 、 視圖相 分開 ， 因此改變應(yīng)用程序中業(yè)務(wù)邏輯非常容易 。 例如 把數(shù)據(jù)庫從 MySQL 改變?yōu)?Oracle，只 需要 改變模型 的代碼就行了 。 模型一旦正確的定義出來 ， 那么 不管數(shù)據(jù) 是 來自數(shù)據(jù)庫或 者是 服務(wù)器，視圖都 將正確的顯示 這些信息 。 由于 MVC 模式中程序的三個層面 是相互獨立，改變其中一個不會影響其它兩個， 因此 MVC 模式可以構(gòu)建出非常良好的松耦合的部件。 由于網(wǎng)絡(luò)信息的不斷發(fā)展，傳統(tǒng)中 WEB 應(yīng)用只能在 PC 端操作，而現(xiàn) 在我們可以用更多的方式來訪問應(yīng)用程序。 MVC 模式中三個層次互不影響這個特點讓程序能夠使用不同樣式的視圖來訪問同一個服務(wù)器，因為一個模型可以被多個視圖共同利用，它包括任何 WEB 瀏覽器或者無線瀏覽器，例如，用戶可以在電腦上訂購某個產(chǎn)品也可以在手機(jī)上來完成訂購，訂購方式雖然不一樣，但是程序中處理訂購產(chǎn)品這個邏輯是一樣的。模型中返回的處理數(shù)據(jù)并沒有被格式化，所以同樣的數(shù)據(jù)能被不同的界面使用。比如，信息數(shù)據(jù)可以用 html 頁面來顯示也可以用 WAP 顯示，而改變數(shù)據(jù)的傳導(dǎo)方向只需要改變視圖選擇的命令就可以，因此模型中的代碼 并沒有被改變。所以數(shù)據(jù)和業(yè)務(wù)處理邏輯從視圖中分離可以保證模型中代碼的復(fù)用。模型中有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，比如，在電子商務(wù)網(wǎng)站中，購物車是基于回話，而其中的電子商務(wù)過程可以被 Flash網(wǎng)站和無線聯(lián)網(wǎng)的應(yīng)用程序復(fù)用。 成本低 使用 MVC 模式可以讓模型中處理業(yè)務(wù)過程的接口的實現(xiàn)變得簡單。 在沒有 MVC 模式之前，程序員需要完成數(shù)據(jù)處理、界面制作、數(shù)據(jù)傳遞等，而現(xiàn)在程序員可以分工 協(xié)作，專注于界面的程序可以將精力集中在表現(xiàn)形式上面，而處理邏輯的程序員只需要專注于業(yè)務(wù)，這樣的分工協(xié)作使得程序的開發(fā)變得更加效率，開發(fā)時間得到相當(dāng)大的縮減。 由于每個模塊中的功能單一，因此當(dāng)需要改變某一部分時只需要找到該模塊進(jìn)行修 12 改即可，對其他模塊并沒有影響。 在 MVC 模式中每個層次的功能十分明顯，而每一層中的應(yīng)用都有相同的特點，因此有利于實現(xiàn)程序的工程化、工具化管理。其中控制器就有一個好處，它可以用來連接不通的模型和視圖來完成用戶所需要的軟件，控制是夠著應(yīng)用程序的一 個非常重要的部分。如果設(shè)計好了模型和視圖，控制器就可以根據(jù)用戶的需求進(jìn)行模型和視圖的組合，將數(shù)據(jù)處理結(jié)果通過所需要的視圖顯示給用戶。 缺點 ： MVC 并沒有一個完整的定義，所以并不容易完全理解 MVC 模式 。 在 使用 MVC 之前是 需要精心的計劃 的 ， 雖然 MVC 模式理解起來很簡單，但是 它的內(nèi)部原理 十分 復(fù)雜，因此 需要花費一些時間去思考。同時由于模型和視圖要嚴(yán)格的分 開 ，這樣 就 給調(diào)試應(yīng)用程序帶來了一定的困難 。所以必須在完成某一小部分模塊時就進(jìn)行測試，保證每個模塊的正確性，這樣在進(jìn)行模塊組合時才能保證程序的正 確性，不然再將代碼組合后再測試就會非常麻煩。 、 中等規(guī)模的應(yīng)用程序 MVC 模式的誕生是由于現(xiàn)在項目的規(guī)模越來越高， MVC 模式只適合大型項目，小、中型的應(yīng)用程序并不適合，用了 MVC 模式后反而會適得其反。 了 系統(tǒng)的 結(jié)構(gòu) 復(fù)雜性 界面相對簡單的程序中 ， 如果使用 MVC 模式 ， 讓 模型 和 視圖與控制器分離，會 使得 結(jié)構(gòu)的復(fù)雜性 變高 ， 這樣還會降低程序的運行效率。 視圖與控制器 雖然看似 是相互分離 的 ， 其實不然，他們是 聯(lián)系緊密的部件，視圖 如果 沒有控制器的存在，其應(yīng)用是 非常 有限， 這樣 反而 妨礙了他們的獨立重用。 在 MVC 模式中視圖與模型中數(shù)據(jù)處理之間要經(jīng)過很多步驟，因此視圖中要想獲得數(shù)據(jù)需要在程序中進(jìn)行多次接口的調(diào)用，因此如果數(shù)據(jù)并沒有改變，反而會使得不必要的頻繁訪問數(shù)據(jù)庫，這樣程序的性能會降低。 很多高級界面工具并不支持 MVC 模式，所以改變這些工具來適應(yīng) MVC 模式中建立模塊的相互分離的代價是很高的，會造成 MVC 使用的困難。 13 SSH 框架 SSH 框架指的是 strusts、 hibernate、 spring 這 3 大框架，利用 SSH 框架實現(xiàn)良好的MVC 模式編程和完全的面向?qū)ο缶幊蹋瓤梢宰畲笙薅鹊膶崿F(xiàn)程序的“低耦合”，又可以有效的減少程序員不必干預(yù)的計算機(jī)底層處理任務(wù)，例如數(shù)據(jù)庫的連接、數(shù)據(jù)的處理，讓程序員集中精力去實現(xiàn)程序的業(yè)務(wù)邏輯即可，在代碼維護(hù)階段也有較大的優(yōu)勢，不必去更改程序的代碼。 struts 框架 在沒有 strust 框架之前，程序員編寫的 web 程序都是在一個 servlet 中將參數(shù)處理、邏輯處理、視圖選擇封裝到一個類中，在編寫小型程序時確實是使得程序的封裝性很好，功能性很集中，但是隨著項目的規(guī) 模越來越大，人們發(fā)現(xiàn)這樣的方式使程序開發(fā)十分不便，結(jié)構(gòu)復(fù)雜，不便于維護(hù)，也并不遵循程序開發(fā)中的功能單一原則，于是應(yīng) MVC 模式的號召， strust 框架將 web 程序中的請求響應(yīng)的處理、業(yè)務(wù)流程處理、視圖的選擇分開。這樣即使遇到大型項目也不會對程序開發(fā)者造成很大的困擾，也使得程序的靈活度更好。 hibernate 框架 Hibernate 中間件是連接 Java 對象和關(guān)系型數(shù)據(jù)庫的橋梁，將 java 對象映射為各種關(guān)系型數(shù)據(jù)庫中的二維關(guān)系，或者反之，將關(guān)系數(shù)據(jù)庫中所存儲的關(guān)系映射為 java 對象，這便是 Hibernate 的主要職責(zé)。同時， Hibernate 還屏蔽了 Java 對于各種關(guān)系型數(shù)據(jù)庫的操作，使得程序員對數(shù)據(jù)庫的編程變得更加容易。 Hibernate 是一種中間件工具，在 ORM（對象與關(guān)系映射）框架中，是接數(shù)據(jù)庫與實體類之間的橋梁，在沒有中間件這個概念之前，程序員直接與最底層的軟件和硬件打交道，由于越底層的東西越負(fù)責(zé)，因此程序員不得不面對很多問題，比如數(shù)據(jù)庫源的不同、復(fù)雜的網(wǎng)絡(luò)環(huán)境、數(shù)據(jù)庫的存儲格式、不同的操作系統(tǒng)等，這些問題與程序沒有直接關(guān)系，在軟件思想中不符合程序員將大量精力集中到業(yè)務(wù)邏輯的開發(fā)的規(guī)則，因此 中間件在應(yīng)用軟件與硬件和操作系統(tǒng)之間解決了這個問題。 spring 框架 Spring 框架式一個輕量級的控制反轉(zhuǎn)（ IOC）技術(shù)和面向切面編程（ AOP）技術(shù)的容器框架，利用 Spring 框架中的 IOC 技術(shù)可以實現(xiàn) J2EE 平臺中所倡導(dǎo)的由容器實現(xiàn)對象的生命周期管理，而利用 Spring 框架中的 AOP 技術(shù)可以實現(xiàn) J2EE 平臺中所倡導(dǎo)的分離應(yīng)用系統(tǒng)中業(yè)務(wù)邏輯組件和通用的技術(shù)服務(wù)組件。應(yīng)用系統(tǒng)的開發(fā)者在應(yīng)用系統(tǒng)中應(yīng)用 Spring 框架后能夠達(dá)到“解耦”和“脫離容器”的設(shè)計和實現(xiàn)的目的。 14 圖 為傳統(tǒng) MVC 模式： 圖 不難得出缺點如下： 對于連接邏輯處理和視圖選擇的控制器，通過代碼來完成十分繁瑣； 如果客戶希望邏輯的實現(xiàn)方式改變或者在程序維護(hù)和升級時需要改變實現(xiàn)方 式，那么需要改動原代碼； 數(shù)據(jù)庫的連接、關(guān)閉需要程序員手動完成，那么數(shù)據(jù)庫一旦改變，又不得不改動原代碼，而且在數(shù)據(jù)庫存儲時的代碼量大。 圖 為 SSH 框架整合的 MVC 模式： 圖 15 利用 SSH 框架后，可以解 決上述 3 個缺點，視圖與邏輯處理的連接用 strusts 框架完成，因此改變連接方向不必改動原代碼，只需要在 strusts 框架的配置文件中更改；對象的調(diào)用方式發(fā)生改變時，只需要在 spring 的配置文件中更改； 數(shù)據(jù)庫連接、關(guān)閉、數(shù)據(jù)保存等交給計算機(jī)來完成，即使數(shù)據(jù)庫改變了，也只需要去 hibernate 配置文件中更改即可。 小結(jié) ，人們不斷的發(fā)現(xiàn)缺點，不斷的提出新的思想，最終認(rèn)為一個優(yōu)秀的軟件系統(tǒng)要有以下幾個特點： ，系統(tǒng)具有控制、業(yè)務(wù)處理、數(shù)據(jù)存儲 3 個大的構(gòu)架 ，在業(yè)務(wù)邏輯中將功能單一化，能夠提高代碼的重用率。 3/在程序更新和維護(hù)時盡量不要去更改原代碼，因為原代碼的改動就需要進(jìn)行大量的分布測試，框架技術(shù)將每個模塊建立連接后交給計算機(jī)來完成，可以避免出錯。 ，程序員的主要任務(wù)是完成具有應(yīng)用價值的業(yè)務(wù)邏輯。 16 第四章 數(shù)據(jù)庫設(shè)計 數(shù)據(jù)庫的設(shè)計關(guān)系到業(yè)務(wù)邏輯的編寫，因此在進(jìn)行數(shù)據(jù)庫分析時應(yīng)根據(jù)規(guī)范要求來嚴(yán)格完成數(shù)據(jù)庫的創(chuàng)建，必須要減少不必要的數(shù)據(jù)，建立數(shù)據(jù)之間良好的關(guān)系結(jié)構(gòu)，大致有以下要求： 構(gòu)要層次分明，每個表的包含的信息能夠體現(xiàn)出某一功能； ，在進(jìn)行程序大致分析時，對數(shù)據(jù)訪問量進(jìn)行評估，訪問量的評估則關(guān)心到數(shù)據(jù)庫的性能、消耗，根據(jù)業(yè)務(wù)邏輯添加”鎖“機(jī)制，保證事務(wù)的完整性。 ，數(shù)據(jù)庫在系統(tǒng)中起到”系統(tǒng)源“的地位，因此一個優(yōu)秀的系統(tǒng)必須要能”保護(hù)數(shù)據(jù)庫“。 ，易于維護(hù)。 數(shù)據(jù)庫需求分析 根據(jù)業(yè)務(wù)邏輯中所產(chǎn)生的數(shù)據(jù)存儲，確定數(shù)據(jù)庫的設(shè)計，數(shù)據(jù)庫需求分析的目的就是為了確定系統(tǒng)中的數(shù)據(jù)存儲和關(guān)系。 根據(jù)分析，可以確定該系 統(tǒng)的集中信息存儲，即：學(xué)生信息、老師信息、專業(yè)信息、院系信息、試卷分?jǐn)?shù)、科目信息。 數(shù)據(jù)庫設(shè)計概要 概要設(shè)計是將需求分析所獲得的存儲信息轉(zhuǎn)換為抽象的關(guān)系模式，在概要設(shè)計中可以大體得出該數(shù)據(jù)表的具體功能和負(fù)責(zé)存儲的信息。 圖 為學(xué)生的 ER 圖： 圖 學(xué)生