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