1.struct

Struts跟Tomcat、Turbine等諸 多Apache專案一樣，是開源軟體，這是它的一大優點。使開發者能更深入的瞭解其內部實現機制。 Struts開放原始碼框架的建立是為了使開發者在構建基於Java Servlet和JavaServer Pages（JSP）技術的Web應用時更加容易。Struts框架為開放者提供了一個統一的標準框架，通過使用Struts作為基礎，開發者能夠更專注 於應用程式的商業邏輯。Struts框架本身是使用JavaServlet和JavaServerPages技術的一種Model-View-Controller（MVC）實現.

具體來講,

Struts的優點有:

1. 實現MVC模式，結構清晰,使開發者只關注業務邏輯的實現.

2. 有豐富的tag可以用 ,Struts的標記庫(Taglib)，如能靈活動用，則能大大提高開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的常用標記外，很少開發自己的標記，或許Struts是一個很好的起點。

3. 頁面導航.頁面導航將是今後的一個發展方向，事實上，這樣做，使系統的脈絡更加清晰。通過一個配置檔案，即可把握整個系統各部分之間的聯絡，這對於後期的維護有著莫大的好處。尤其是當另一批開發者接手這個專案時，這種優勢體現得更加明顯。

4. 提供Exception處理機制 .

5. 資料庫連結池管理

6. 支援I18N

缺點:

一、轉到展示層時，需要配置forward，每一次轉到展示層，相信大多數都是直接轉到jsp，而涉及到轉向， 需要配置forward，如果有十個展示層的jsp，需要配置十次struts，而且還不包括有時候目錄、檔案變更，需要重新修改forward，注意， 每次修改配置之後，要求重新部署整個專案，而tomcate這樣的伺服器，還必須重新啟動伺服器，如果業務變更復雜頻繁的系統，這樣的操作簡單不可想象。現在就是這樣，幾十上百個人同時線上使用我們的系統，大家可以想象一下，我的煩惱有多大。

二、 Struts 的Action必需是thread－safe方式，它僅僅允許一個例項去處理所有的請求。所以action用到的所有的資源都必需統一同步，這個就引起了執行緒安全的問題。

三、 測試不方便. Struts的每個Action都同Web層耦合在一起，這樣它的測試依賴於Web容器，單元測試也很難實現。不過有一個Junit的擴充套件工具Struts TestCase可以實現它的單元測試。

四、 型別的轉換. Struts的FormBean把所有的資料都作為String型別，它可以使用工具Commons-Beanutils進行型別轉化。但它的轉化都是在Class級別，而且轉化的型別是不可配置的。型別轉化時的錯誤資訊返回給使用者也是非常困難的。

五、 對Servlet的依賴性過強. Struts處理Action時必需要依賴ServletRequest和ServletResponse，所有它擺脫不了Servlet容器。

六、前端表示式語言方面.Struts集成了JSTL，所以它主要使用JSTL的表示式語言來獲取資料。可是JSTL的表示式語言在Collection和索引屬性方面處理顯得很弱。

七、 對Action執行的控制困難.Struts建立一個Action，如果想控制它的執行順序將會非常困難。甚至你要重新去寫Servlet來實現你的這個功能需求。

八、 對Action 執行前和後的處理. Struts處理Action的時候是基於class的hierarchies，很難在action處理前和後進行操作。

九、 對事件支援不夠. 在struts中，實際是一個表單Form對應一個Action類(或DispatchAction)，換一句話說：在Struts中實際是一個表單只能 對應一個事件，struts這種事件方式稱為application event，application event和component event相比是一種粗粒度的事件。

Struts重要的表單物件ActionForm是一種物件，它代表了一種應用，這個物件中至少包含幾個欄位，這些欄位是Jsp頁面表單中的input欄位，因為一個表單對應一個事件，所以，當我們需要將事件粒度細化到表單中這些欄位時，也就是說，一個欄位對應一個事件時，單純使用Struts就不太可能，當然通過結合JavaScript也是可以轉彎實現的。

2．Hibernate

Hibernate是一個開放原始碼的物件關係對映框架，它對JDBC進行了非常輕量級的物件封裝，使得Java程式設計師可以隨心所欲的使用物件程式設計思維來操縱資料庫。

Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程式實用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成資料持久化的重任。

大多數開發機構經常採取建立各自獨立的資料持久層。一旦底層的資料結構發生改變，那麼修改應用的其餘部分使之適應這種改變的代價將是十分巨大的。 Hibernate適時的填補了這一空白，它為Java應用提供了一個易用的、高效率的物件關係對映框架。hibernate是個輕量級的永續性框架，功能卻非常豐富。

優點：

a.Hibernate 使用 Java 反射機制而不是位元組碼增強程式來實現透明性。

b.Hibernate 的效能非常好，因為它是個輕量級框架。對映的靈活性很出色。

c.它支援各種關係資料庫，從一對一到多對多的各種複雜關係。

缺點：

它限制您所使用的物件模型。(例如，一個永續性類不能對映到多個表)其獨有的介面和可憐的市場份額也讓人不安，儘管如此，Hibernate 還是以其強大的發展動力減輕了這些風險。其他的開源永續性框架也有一些，不過都沒有 Hibernate 這樣有市場衝擊力。

上面回貼情緒有點激動，希望諒解，我不是因為有人批評Hibernate而感到不快，而是因為帖子裡面的觀點實在讓我覺得荒謬。不管覺得 Hibernate好也吧，不好也吧，我唯一覺得遺憾的是，在中文論壇裡面找不到一個對Hibernate的真正高水平的評價。在TSS上有一個關於Hibernate的hot thread，跟了幾百貼，其中包括Hibernate作者Gavin和LiDO JDO的CTO，對於JDO和Hibernate有過一些激烈的爭論，我曾經耐心的看了一遍，仍然沒有發現針對Hibernate真正有力的攻擊，那些所 謂的攻擊無非針對Hibernate沒有一個GUI的配置工具，沒有商業公司支援，沒有標準化等等這些站不住腳的理由。

補充幾點我的意見：

一、Hibernate是JDBC的輕量級的物件封裝，它是一個獨立的物件持久層框架，和App Server，和EJB沒有什麼必然的聯絡。Hibernate可以用在任何JDBC可以使用的場合，例如Java應用程式的資料庫訪問程式碼，DAO介面 的實現類，甚至可以是BMP裡面的訪問資料庫的程式碼。從這個意義上來說，Hibernate和EB不是一個範疇的東西，也不存在非此即彼的關係。

二、Hibernate是一個和JDBC密切關聯的框架，所以Hibernate的相容性和JDBC驅動，和資料庫都有一定的關係，但是和使用它的Java程式，和App Server沒有任何關係，也不存在相容性問題。

三、Hibernate不能用來直接和Entity Bean做對比，只有放在整個J2EE專案的框架中才能比較。並且即使是放在軟體整體框架中來看，Hibernate也是做為JDBC的替代者出現的，而 不是Entity Bean的替代者出現的，讓我再列一次我已經列n次的框架結構：

傳統的架構：

1) Session Bean <-> Entity Bean<-> DB

為了解決效能障礙的替代架構：

2) Session Bean <-> DAO <->JDBC <-> DB

使用Hibernate來提高上面架構的開發效率的架構：

3) Session Bean <-> DAO <->Hibernate <-> DB

就上面3個架構來分析：

1、記憶體消耗：採用JDBC的架構2無疑是最省記憶體的，Hibernate的架構3次之，EB的架構1最差。

2、執行效率：如果JDBC的程式碼寫的非常優化，那麼JDBC架構執行效率最高，但是實際專案中，這一點幾乎做不到，這需要程式設計師非常精通JDBC，運用 Batch語句，調整PreapredStatement的Batch Size和Fetch Size等引數，以及在必要的情況下采用結果集cache等等。而一般情況下程式設計師是做不到這一點的。因此Hibernate架構表現出最快的執行效率。 EB的架構效率會差的很遠。

3、開發效率：在有JBuilder的支援下以及簡單的專案，EB架構開發效率最高，JDBC次之，Hibernate最差。但是在大的專案，特別是持久層關係對映很複雜的情況下，Hibernate效率高的驚人，JDBC次之，而EB架構很可能會失敗。

4、分散式，安全檢查，叢集，負載均衡的支援

由於有SB做為Facade，3個架構沒有區別。

四、EB和Hibernate學習難度在哪裡？

EB的難度在哪裡？不在複雜的XML配置檔案上，而在於EB運用稍微不慎，就有嚴重的效能障礙。所以難在你需要學習很多EJB設計模式來避開效能問題，需 要學習App Server和EB的配置來優化EB的執行效率。做EB的開發工作，程式設計師的大部分精力都被放到了EB的效能問題上了，反而沒有更多的精力關注本身就主要 投入精力去考慮的物件持久層的設計上來。

Hibernate難在哪裡？不在Hibernate本身的複雜，實際上Hibernate非常的簡單，難在Hibernate太靈活了。

當你用EB來實現持久層的時候，你會發現EB實在是太笨拙了，笨拙到你根本沒有什麼可以選擇的餘地，所以你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮選擇哪個方案，因為只有唯一的方案擺在你面前，你只能這麼做，沒得選擇。

Hibernate相反，它太靈活了，相同的問題，你至少可以設計出十幾種方案來解決，所以特別的犯難，究竟用這個，還是用那個呢？這些方案之間到底有什麼區別呢？他們的執行原理有什麼不同？執行效率哪個比較好？光是主鍵生成，就有七八種方案供你選擇，你為難不為難？集合屬性可以用Set，可以用 List，還可以用Bag，到底哪個效率高，你為難不為難？查詢可以用iterator，可以用list，哪個好，有什麼區別？你為難不為難？複合主鍵你 可以直接在hbm裡面配置，也可以自定義CustomerType，哪種比較好些？你為難不為難？對於一個表，你可以選擇單一對映一個物件，也可以對映成 父子物件，還可以對映成兩個1:1的物件，在什麼情況下用哪種方案比較好，你為難不為難？

這個列表可以一直開列下去，直到你不想再看下去為止。當你面前擺著無數的眼花繚亂的方案的時候，你會覺得幸福呢？還是悲哀呢？如果你是一個負責的程式設計師，那麼你一定會仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，你會覺得你已經陷入進去拔不出來了。如果是用EB，你第一秒種就已經做出了決 定，根本沒得選擇，比如說集合屬性，你只能用Collection，如果是Hibernate，你會在Bag，List和Set之間來回猶豫不決，甚至搞 不清楚的話，程式都沒有辦法寫。

3． Spring

它是一個開源的專案，而且目前非常活躍；它基於IoC（Inversion ofControl，反向控制）和AOP的構架多層j2ee系統的框架，但它不強迫你必須在每一層中必須使用Spring，因為它模組化的很好，允許你根據自 己的需要選擇使用它的某一個模組；它實現了很優雅的MVC，對不同的資料訪問技術提供了統一的介面，採用IoC使得可以很容易的實現bean的裝配，提供 了簡潔的AOP並據此實現TranscationManagment，等等

優點：

a. Spring能有效地組織你的中間層物件，不管你是否選擇使用了EJB。如果你僅僅使用了Struts或其他為J2EE的 API特製的framework，Spring致力於解決剩下的問題。

b. Spring能消除在許多工程中常見的對Singleton的過多使用。根據我的經驗，這是一個很大的問題，它降低了系統的可測試性和麵向物件的程度。

c. 通過一種在不同應用程式和專案間一致的方法來處理配置檔案，Spring能消除各種各樣自定義格式的屬性檔案的需要。曾經對某個類要尋找的是哪個魔法般的屬性項或系統屬性感到不解，為此不得不去讀Javadoc甚至源編碼？有了Spring，你僅僅需要看看類的JavaBean屬性。Inversion of Control的使用（在下面討論）幫助完成了這種簡化。

d.通過把對介面程式設計而不是對類程式設計的代價幾乎減少到沒有，Spring能夠促進養成好的程式設計習慣。

e. Spring被設計為讓使用它建立的應用盡可能少的依賴於他的APIs。在Spring應用中的大多數業務物件沒有依賴於Spring。

f. 使用Spring構建的應用程式易於單元測試。

g.Spring能使EJB的使用成為一個實現選擇,而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務介面，卻不會影響呼叫程式碼。

h. Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適用於許多web應用。例如，Spring能使用AOP提供宣告性事務管理而不通過EJB容器，如果你僅僅需要與單個數據庫打交道，甚至不需要一個JTA實現。

i. Spring為資料存取提供了一個一致的框架,不論是使用的是JDBC還是O/R mapping產品（如Hibernate）。

Spring確實使你能通過最簡單可行的解決辦法來解決你的問題。而這是有有很大價值的。

缺點：

jsp中要寫很多程式碼、控制器過於靈活，缺少一個公用控制器。