目前情況：
自動工單管理系統(tǒng)，使用自開發(fā)的類似struts的架構(gòu)，數(shù)據(jù)庫訪問經(jīng)過包裝，返回string數(shù)組。 其架構(gòu)問題：
Action使用同步鎖，導(dǎo)致在同一時間只能進(jìn)行一次web訪問，如同時有其他訪問，將不必要的被阻塞。
結(jié)構(gòu)不夠清晰，不能夠完全按mvc的思想明確的分離各層邏輯。jsp代碼過多且結(jié)構(gòu)零亂，沒有把通用的代碼用taglib等技術(shù)抽象，后續(xù)開發(fā)困難
業(yè)務(wù)邏輯和數(shù)據(jù)庫緊密相關(guān)，而沒有從表實現(xiàn)中抽象出來。同時，在每次使用同樣的業(yè)務(wù)邏輯的時候都要反復(fù)的進(jìn)行相關(guān)sql編程。故而與數(shù)據(jù)庫有強耦合，相關(guān)程序重用性低，可讀性差。其翻頁機制邏輯橫貫架構(gòu)，使層次高度耦合，而數(shù)據(jù)庫封裝也可能存在性能問題。
同時，客戶也提出了不少整改意見，而在原版本的修改和升級都會較為困難，而且對長期的維護(hù)不利。
項目分析：
目前的各種業(yè)務(wù)管理系統(tǒng)還是將以j2ee的b/s架構(gòu)為主流，所以有必要完成一個通用的，穩(wěn)固的整體架構(gòu)作為以后各種應(yīng)用的堅實基礎(chǔ)。
我認(rèn)為應(yīng)盡可能使用業(yè)內(nèi)先進(jìn)的免費框架技術(shù)而不是自開發(fā)框架。好處是：
這些框架技術(shù)凝聚很多業(yè)內(nèi)精英的智慧，而且經(jīng)過發(fā)布和使用，技術(shù)體系已經(jīng)成熟，性能有所保障。
層次清晰，符合先進(jìn)的技術(shù)理念和設(shè)計模式。同時也容易找到熟悉相關(guān)技術(shù)的人才，維護(hù)和后續(xù)開發(fā)方便。
相比之下自開發(fā)框架因為技術(shù)實力和時間問題，很難達(dá)到這些業(yè)內(nèi)領(lǐng)先框架的技術(shù)高度。
分析一般的j2ee應(yīng)用，應(yīng)有如下層次：
顯示層 負(fù)責(zé)界面顯示，接受用戶指令
顯示層有較為經(jīng)典的MVC，即model,view,control，進(jìn)一步了細(xì)化了顯示層的工作。此類著名框架有struts，webwork,spring-mvc等。經(jīng)考察，我認(rèn)為struts雖然是時間最長最成熟的技術(shù)，但易用性和一些架構(gòu)理念不如webwork，而view層的開發(fā)應(yīng)盡可能簡單快速。故選定用webwork.
邏輯層 負(fù)責(zé)進(jìn)行業(yè)務(wù)邏輯的實現(xiàn)
目前的開發(fā)過程，往往陷入邏輯層和數(shù)據(jù)訪問層不能分離的情況。面向?qū)ο蟮捻椖块_發(fā)最后演變成成程序員在程序各處手工寫sql操表。這樣做的優(yōu)點是開發(fā)迅速有效，問題是結(jié)構(gòu)將日益混亂，每次邏輯的變化將不得不修改分散于各處的sql語句，而后續(xù)的程序員也必須了解整個程序和數(shù)據(jù)庫結(jié)構(gòu)才能進(jìn)行修改。如果是短期小型項目，可以用這種方式。否則的話，我認(rèn)為應(yīng)盡可能貫徹面向?qū)ο笏枷?，把業(yè)務(wù)邏輯抽象出來。
而邏輯層的工作就是針對實體對象進(jìn)行業(yè)務(wù)邏輯的實現(xiàn)。我們針對所有的業(yè)務(wù)操作，對外提供service接口，既服務(wù)接口。這類似tuxedo和ejb所采用的業(yè)務(wù)外觀模式。而為填補service生存周期管理的空白，我們使用著名的spring框架。優(yōu)點：
實現(xiàn)Ioc，使各層次的耦合可配置化。
按需要實現(xiàn)單例模式等，進(jìn)行生存周期管理
事務(wù)管理。Spring的宣言事務(wù)管理（Declarative transaction management）使得一般場景的代碼中將不需要考慮事務(wù)問題而集中于業(yè)務(wù)邏輯
攔截機制將為程序提供很好的擴展空間
3. 數(shù)據(jù)訪問層 負(fù)責(zé)將類操作映射為數(shù)據(jù)庫操作。進(jìn)行實體類的持久化。從而將所有的數(shù)據(jù)訪問工作集中起來
這一層我們將完成實體類持久化(persistence)，有若干選擇：
1 jdbc實現(xiàn)
2 使用ORM工具 如hibernate,ibatis,jdo
經(jīng)過實寫代碼，感覺用jdbc實現(xiàn)dao效率非常低，而且容易出錯。經(jīng)過考量選用hibernate。和ibatis相比雖然上手慢且不夠靈活，但其架構(gòu)思想和強大功能都受到業(yè)內(nèi)一致好評，甚至是ejb3也深受hibernate影響 。所以hibernate是很好的選擇。
項目設(shè)計
綜上，我們使用 webwork+spring+hibernate的架構(gòu)。
版本：webwork-2.1.7 spring1.2 hibernate-3.0.3
經(jīng)過一段時間的開發(fā)，目前架構(gòu)基本成形：
|
|
在src目錄下為java源碼
dao 負(fù)責(zé)數(shù)據(jù)訪問對象的定義和實現(xiàn)
其中Dao結(jié)尾為接口，Impl結(jié)尾為實現(xiàn)。目前一般用hibernate做實現(xiàn)。
domain 實體對象
logic 針對實體對象封裝的邏輯
這里service是外觀接口，serviceimpl是實現(xiàn)，考慮目前情況簡單，并沒有進(jìn)一步分離邏輯，業(yè)務(wù)邏輯都在impl中完成。
web 界面相關(guān)的java類
common是一些常用類，如處理中文問題的filter.
displaytag中放了displaytag相關(guān)的類，多為wrapper.
webwork中都是對應(yīng)的action，
其中 BaseAction是基本的抽象類，基本后續(xù)開發(fā)應(yīng)繼承此類
CrudAction是為了一般的Crud工作而作的一個抽象類，可以繼承用來簡化工作。
而CaseDispatcher負(fù)責(zé)菜單點擊后分發(fā)到相關(guān)Action，同時處理權(quán)限和session工作。
其他action按模塊進(jìn)行了組織 |
|
|
左邊是webroot的結(jié)構(gòu)
重要的配置文件有：
Spring
applicationContext.xml
applicationContext-db.xml
Webwork
xwork.xml
webwork.properties
i18n
labels.properties
log4j
log4j.properties
displaytag
displaytag.properties
dbConnect
jdbc.properties |
關(guān)于一些技術(shù)難點和細(xì)節(jié)：
1． 各框架連接：spring到hibernate使用spring的hibernate支持。Spring到webwork使用autoware的攔截機制自動裝配。
2． 列表的問題，采用displaytag。功能強大，使用簡潔，可實現(xiàn)排序和數(shù)據(jù)導(dǎo)出。
3． 數(shù)據(jù)下載，使用displaytag自帶的excel下載
4． 文件上傳，使用webwork提供的解決方案，用攔截機制實現(xiàn)。
5．jsp代碼組織方面，我們使用taglib和css技術(shù)使jsp中頁面邏輯減少到最小，一般情況完全可以不使用<% %>的script段 。同時我們使用兩個include來包含常用的taglib定義，js引用和html結(jié)構(gòu)，使jsp代碼非常簡潔。
6． 中文問題 我們使用filter來解決頁面gbk到java程序unicode的轉(zhuǎn)換，同時通過正確的設(shè)置數(shù)據(jù)庫連接url完成和數(shù)據(jù)庫之間的交互。
7． I18n國際化。我們要求在jsp代碼中不出現(xiàn)中文，所有提示信息都通過資源文件labels.properties來完成。頁面中可以使用jstl或webwork標(biāo)簽來調(diào)用。
8． 界面驗證問題。使用webwork的validate機制用xml定義，或在action中代碼判斷。