經(jīng)過一段時間使用struts，隨著系統(tǒng)越做越大，現(xiàn)在，我終于要拋棄struts了，因為到現(xiàn)在，struts的巨大不足和缺陷越來越影響到我的項目的進度和開發(fā)效率了。
背景：現(xiàn)在，我負責(zé)著一個大型企業(yè)的人力資源管理系統(tǒng)，整個系統(tǒng)管理的人員大約有1.6萬人左右，系統(tǒng)基于jboss+oracle，java技術(shù)框架為struts，少許的報表用到了 servlet，項目開發(fā)的時間差不多一年，好，轉(zhuǎn)入正題。
到現(xiàn)在為止，我認為formbean 的好處就是和頁面表單對應(yīng)起來,在系統(tǒng)業(yè)務(wù)處理中，可以實例化formbean之就可以取出頁面表單的值來,方便于在業(yè)務(wù)邏輯中引用。使得業(yè)務(wù)處理層和展示層可以分離開來，到現(xiàn)在為止，這也是我發(fā)現(xiàn)struts的唯一好處。
但struts帶給我的煩惱，各位，實在太多太多了，主要的幾點我羅列如下：
一、轉(zhuǎn)到展示層時，需要配置forward，每一次轉(zhuǎn)到展示層，相信大多數(shù)都是直接轉(zhuǎn)到j(luò)sp，而涉及到轉(zhuǎn)向，需要配置forward，如果有十個展示層的jsp，需要配置十次struts，而且還不包括有時候目錄、文件變更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整個項目，而tomcate這樣的服務(wù)器，還必須重新啟動服務(wù)器，如果業(yè)務(wù)變更復(fù)雜頻繁的系統(tǒng)，這樣的操作簡單不可想象。現(xiàn)在就是這樣，幾十上百個人同時在線使用我們的 系統(tǒng)，大家可以想象一下，我的煩惱有多大。
二、當(dāng)頁面表單需要自動變化或者頻繁變化時。
對于一個成熟的MIS系統(tǒng)來說,頁面表單肯定是不固定的,甚至象有些系統(tǒng)，頁面表單是存在數(shù)據(jù)庫中，需要填寫的表單在頁面自動生成，比如填寫一個人員基本信息,本來只需要填寫 姓名、性別、出生年月 三個指標(biāo)，而我后來需要增加籍貫這樣的指標(biāo)，我只需要在數(shù)據(jù)庫中添加籍貫這個記錄，并在頁面就能自動增加籍貫這樣的表單。而 struts在這方面，其優(yōu)勢反而變成了不足，我參考了非常多的人力資源管理系 統(tǒng)，這些系統(tǒng)幾乎都能夠做系統(tǒng)里面就可以控制人員信息的指示，進行使展示層能隨之靈活變化，如果使用了struts，這些靈活性就根本用不上。
同時，如果頁面表單頻繁變化時，就需要頻繁修改formbean對應(yīng)的方法和屬性，而每次修改之后，就要求重新部署，或者重新啟動服務(wù)器……。
三、要引入struts包，引入strtus標(biāo)簽庫，現(xiàn)到現(xiàn)為止，我們有所見即所得的dreamwaver、frontpage、webeditor，對于繁雜頁面的設(shè)計，是非常方便的，而對于struts標(biāo)簽庫，沒有哪一種軟件能夠支持。jbuilder我沒用過，不知道支持不支持，而為了維護這些標(biāo)簽庫，增加工作量支持，也非常容易出錯，稍微不小心，就一堆異常拋出來，系統(tǒng)他死給你看。
總結(jié)：
現(xiàn)在為什么asp.net越來越流行，非常重要的一點，就是asp.net這樣的模式，簡單，易于控制。而且我現(xiàn)在仍然覺得，利用jsp的文件名作為路徑的映射非常方便，而struts還非常去配置action,使之有帶有象.do、.main這樣后綴的路徑訪問方式，不但增加了系統(tǒng)功能的復(fù)雜性，影響了系統(tǒng)的性能不說，還增加了非常多的系統(tǒng)不可掌握因素。其實 javabean+jsp，利用javabean處理業(yè)務(wù)邏輯，只利用jsp來展示數(shù)據(jù)，這正是.net的原型，同樣，即可以不用去配置struts、也不需要象serlet一樣去配置web.xml帶來的麻煩。 所以，并不是所有的框架都是好的，越簡單越易于控制。
所以，現(xiàn)在，我決定放棄struts，轉(zhuǎn)而采用javabean+jsp的技術(shù)結(jié)構(gòu)