java EE web開發經常使用框架使用感言

java EE web項目開發，從前到後...

從訪問地址處處理完成轉到JSP頁面的轉向方式：
    Struts:採用XML配置文件方式，路徑配置集中。
    Spring MVC:採用標記注入和return頁面方式，路徑配置分散在每一個java文件中。

    從對比中，我以爲Spring的這種方式存在難於集中維護項目路徑的缺憾。而Struts這種方式，咱們就能夠很方便集中的管理項目的路徑。若是項目已經很龐大，路徑不少，咱們如今還要在這個項目上作新東西，繼續加新路徑來完成新業務的訪問。在Struts中，咱們就能夠很方便的經過查看僅有的那幾個XML配置文件來肯定咱們要新加的路徑是否和已有的存在衝突、重複等。而spring在這時就顯得很悲劇了，路徑分散在各個controller java文件中，你要怎麼去肯定呢，難道一個一個打開去看它們佔有的路徑？
    這時你能夠說，能夠用eclipse來查全部的controller吖，也很簡單就能肯定是否和已有路徑衝突。固然這樣的思路能夠解決大部分問題，但不是所有。首先，spring的@RequestMapping 路徑定義標籤是能夠做用於類，也能夠做用於方法的，且都容許「/」路徑符號。問題隨之而來，「/a/b/c/d」這樣的路徑，就能夠分紅數種寫法而分開寫在controller類上或類中的具體方法上，當有人把它們分段寫開的時候，你還怎麼來查你想定義的路徑是否已經存在呢？而對於Struts，上面的那種路徑，你只能寫成namespace="/a/b/c"，而後在其中定義action的name="d"，由於Struts的name默認是不容許「/」路徑符號的，這時你的查找就變的很簡單。
    上面說明的特色，就Struts來講，也更便於後來者來根據訪問路徑快速找到具體的處理方法，這樣後來者要維護或改動action時就在找到目標這個事情上節省不少功夫。
    同時spring的這種return到jsp頁面的方式，讓人真懷疑是否是又要返回servlet時代。同時大量的路徑類字符串被寫在java類中（@RequestMapping中的、最後的return中的）總讓我以爲不是一個很好的方式，綁的太死的感受。
    就spring的路徑維護來講，若是項目組有一個很好的controller類的管理方式，固然也能很大程度上減小路徑方面帶來的困擾。好比com.xx.aProject.controller總包下，全部的controller java類文件都有一個和它訪問路徑對應的包結構，並在controller類上就使用@RequestMapping來標識此類的總訪問路徑，同時要求方法的@RequestMapping定義上不準使用「/」路徑符號。如上面提到的路徑，對應的類文件就應該是com.xx.aProject.controller.a.b包下的c.java文件，d方法。在類上使用@RequestMapping(value = "/a/b/c"),具體處理方法上使用@RequestMapping(value = "/d")。
   
    綜上，struts適合做爲路徑超多的大型超大型項目的路徑管理策略，而srping就顯得單薄了；同時spring卻提供了一種快速配置方案，而這種策略則較適合訪問路徑很少且相對開發完成不多改動的中小型項目。固然，我我的認爲，「Spring MVC的出現象徵着Struts的末日」這種說法，有點太誇大了點Spring。


中間業務邏輯處理類的管理：
    很汗顏，我沒有接觸過這一層的除Spring外的其它框架，因此仍是Spring吧，不說其它了。

最後的數據庫訪問：     hibernate：封裝的很是徹底，並且如今支持model類內的標籤注入類與表的關係、屬性與表字段的關係。     ibatis/mybatis:全手寫SQL，並將其放入XML文件中，在java中經過ID標記調用XML中的SQL語句執行的方式。     JDBC：不說了，你們剛開始學習時都從它開始的。     上面已經說明的方式，註定了hibernate的優勢，開發DAO層代碼快速簡單，同時也註定了它的缺點，查詢速率不佳，由於框架自己要兼顧多款數據庫，因此咱們調用一個簡單查詢時，它會運行許多兼顧左右的"廢話"；同時須要與JDBC配合起來使用才能達到項目要求，通常都這樣，由於hibernate不可能想到你的所有查詢需求，有時你必須在java中拼接SQL或者HQL，而後調用JDBC來完成查詢。那麼，使用hibernate，你就註定了要看在java文件中寫的處處是的亂七八糟的SQL語句，而後把你噁心個半死。在java文件中拼接字符串，並且是很容易拼接錯誤的SQL語句（單引號，雙引號之類），並且通常hibernate沒提供的查詢都是複雜查詢，SQL語句串又臭又長，這對不少程序員來講是個看到就頭疼的挑戰。     ibatis/mybatis相對於SQL語句方面的處理策略就使得開發人員舒心了不少，而且不用再用JDBC。你也不用再在java文件中拼接SQL語句了（最少不用噁心了），同時由於全部SQL是你本身針對本身當前使用的數據庫編寫的，查詢效率徹底由你而定，若是你是個SQL高手，那麼恭喜你。但這樣的方式也有它的缺點，全部的SQL都要你本身一個一個寫，這樣相對於hibernate，開發效率上就有所不及，但若是已經有了一個固定的開發模式，這個問題基本還很容易解決，複製已有XML，改改裏面的表名類名字段名而已。     綜上，你給本身作項目，而且但願它查詢響應快速，代碼優雅，便於之後DAO層維護，那就ibatis/mybatis吧；若是你只是接單來作項目，工期緊張，想省成本，也不用之後回頭來看那些噁心的java中SQL，那就hibernate吧。