框架學習之框架的優缺點

Struts的優勢有：

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

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

3. 頁面導航.頁面導航將是從此的一個發展方向，事實上，這樣作，使系統的脈絡更加清晰。經過一個配置文件，便可把握整個系統各部分之間的聯繫，這對於後期的維護有着莫大的好處。尤爲是當另外一批開發者接手這個項目時，這種優點體現得更加明顯。

4. 提供Exception處理機制 .

5. 數據庫連接池管理

6. 支持I18N

缺點：

1、 轉到展現層時，須要配置forward，每一次轉到展現層，相信大多數都是直接轉到jsp，而涉及到轉向，須要配置forward，若是有十個展現層的jsp，須要配置十次struts，並且還不包括有時候目錄、文件變動，須要從新修改forward，注意，每次修改配置以後，要求從新部署整個項目，而tomcat這樣的服務器，還必須從新啓動服務器，若是業務變動複雜頻繁的系統，這樣的操做簡單不可想象。

2、 Struts 的Action必需是線程安全方式，它僅僅容許一個實例去處理全部的請求，因此action用到的全部的資源都必需統一同步，這個就引發了線程安全的問題。

3、 測試不方便. Struts的每一個Action都同Web層耦合在一塊兒，這樣它的測試依賴於Web容器，單元測試也很難實現。不過有一個Junit的擴展工具Struts TestCase能夠實現它的單元測試。

4、 類型的轉換. Struts的FormBean把全部的數據都做爲String類型，它可使用工具Commons-Beanutils進行類型轉化。但它的轉化都是在Class級別，並且轉化的類型是不可配置的。類型轉化時的錯誤信息返回給用戶也是很是困難的。

5、 對Servlet的依賴性過強. Struts處理Action時必須要依賴ServletRequest 和ServletResponse，全部它擺脫不了Servlet容器。

6、 前端表達式語言方面.Struts集成了JSTL，因此它主要使用JSTL的表達式語言來獲取數據。但是JSTL的表達式語言在Collection和索引屬性方面處理顯得很弱。

7、 對Action執行的控制困難. Struts建立一個Action，若是想控制它的執行順序將會很是困難。甚至你要從新去寫Servlet來實現你的這個功能需求。

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

9、 對事件支持不夠. 在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 這樣有市場衝擊力。

3． Spring框架的優缺點

優勢

　　它是一個開源的項目，並且目前很是活躍；它基於IoC（Inversion of Control，反向控制）和AOP的構架多層j2ee系統的框架，但它不強迫你必須在每一層中必須使用Spring，由於它模塊化的很好，容許你根據本身的須要選擇使用它的某一個模塊；它實現了很優雅的MVC，對不一樣的數據訪問技術提供了統一的接口，採用IoC使得能夠很容易的實現bean的裝配，提供了簡潔的AOP並據此實現Transcation Managment，等等

   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產品

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

缺點：jsp中要寫不少代碼、控制器過於靈活，缺乏一個公用控制器。 

Struts工做原理

　　MVC即Model-View-Controller的縮寫，是一種經常使用的設計模式。MVC減弱了業務邏輯接口和數據接口之間的耦合，以及讓視圖層更富於變化。MVC的工做原理,以下圖1所示：
    Struts 是MVC的一種實現，它將 Servlet和 JSP 標記（屬於 J2EE 規範）用做實現的一部分。Struts繼承了MVC的各項特性，並根據J2EE的特色，作了相應的變化與擴展。Struts的工做原理，

　　視圖：主要由JSP生成頁面完成視圖，Struts提供豐富的JSP 標籤庫： Html，Bean，Logic，Template等，這有利於分開表現邏輯和程序邏輯。

　　控制：在Struts中，承擔MVC中Controller角色的是一個Servlet，叫ActionServlet。ActionServlet是一個通用的控制組件。這個控制組件提供了處理全部發送到Struts的HTTP請求的入口點。它截取和分發這些請求到相應的動做類（這些動做類都是Action類的子類）。另外控制組件也負責用相應的請求參數填充 Action From（一般稱之爲FromBean）,並傳給動做類（一般稱之爲ActionBean）。動做類實現核心商業邏輯，它能夠訪問java bean 或調用EJB。最後動做類把控制權傳給後續的JSP 文件，後者生成視圖。全部這些控制邏輯利用Struts-config.xml文件來配置。

　　模型：模型以一個或多個java bean的形式存在。這些bean分爲三類：Action Form、Action、JavaBean or EJB。Action Form一般稱之爲FormBean，封裝了來自於Client的用戶請求信息，如表單信息。Action一般稱之爲ActionBean，獲取從ActionSevlet傳來的FormBean，取出FormBean中的相關信息，並作出相關的處理，通常是調用Java Bean或EJB等。

流程：在Struts中，用戶的請求通常以*.do做爲請求服務名，全部的*.do請求均被指向ActionSevlet，ActionSevlet根據Struts-config.xml中的配置信息，將用戶請求封裝成一個指定名稱的FormBean，並將此FormBean傳至指定名稱的ActionBean，由ActionBean完成相應的業務操做，如文件操做，數據庫操做等。每個*.do均有對應的FormBean名稱和ActionBean名稱，這些在Struts-config.xml中配置。

核心：Struts的核心是ActionSevlet，ActionSevlet的核心是Struts-config.xml。

Hibernate的主要接口：

核心接口 　　如下5個核心接口幾乎在任何實際開發中都會用到。經過這些接口，你不只能夠存儲和得到持久對象，而且可以進行事務控制。 　　

Session接口 　　Session接口對於Hibernate 開發人員來講是一個最重要的接口。然而在Hibernate中，實例化的Session是一個輕量級的類，建立和銷燬它都不會佔用不少資源。這在實際項目中確實很重要，由於在客戶程序中，可能會不斷地建立以及銷燬Session對象，若是Session的開銷太大，會給系統帶來不良影響。　　

SessionFactory 接口 　這裏用到了一個設計模式――工廠模式，用戶程序從工廠類SessionFactory中取得Session的實例。令你感到奇怪的是SessionFactory並非輕量級的！實際上它的設計者的意圖是讓它能在整個應用中共享。典型地來講，一個項目一般只須要一個SessionFactory就夠了，可是當你的項目要操做多個數據庫時，那你必須爲每一個數據庫指定一個SessionFactory。 SessionFactory在Hibernate中實際起到了一個緩衝區的做用，它緩衝了Hibernate自動生成的SQL語句和一些其它的映射數據，還緩衝了一些未來有可能重複利用的數據。 　　

Configuration 接口 　Configuration接口的做用是對Hibernate進行配置，以及對它進行啓動。在Hibernate的啓動過程當中，Configuration類的實例首先定位映射文檔的位置，讀取這些配置，而後建立一個SessionFactory對象。 　　　　

Query和Criteria接口  Query接口讓你方便地對數據庫及持久對象進行查詢，它能夠有兩種表達方式：HQL語言或本地數據庫的SQL語句。Query常常被用來綁定查詢參數、限制查詢記錄數量，並最終執行查詢操做。Criteria接口與Query接口很是相似，它容許你建立並執行面向對象的標準化查詢,值得注意的是Query接口也是輕量級的，它不能在Session以外使用。 　　

Callback 接口 當一些有用的事件發生時――例如持久對象的載入、存儲、刪除時，Callback接口會通知Hibernate去接收一個通知消息。通常而言，Callback接口在用戶程序中並非必須的，但你要在你的項目中建立審計日誌時，你可能會用到它。如下是它的策略接口：

· 主鍵的生成 (IdentifierGenerator 接口) 　　

· 本地SQL語言支持 (Dialect 抽象類) 　　

· 緩衝機制 (Cache 和CacheProvider 接口) 　　

· JDBC 鏈接管理 (ConnectionProvider接口) 　　

.事務管理 (TransactionFactory, Transaction, 和 TransactionManagerLookup 接口) 　　

· ORM 策略 (ClassPersister 接口) 　　

· 屬性訪問策略 (PropertyAccessor 接口) 　　

· 代理對象的建立 (ProxyFactory接口) 　　

Hibernate爲以上所列的機制分別建立了一個缺省的實現，所以若是你只是要加強它的某個策略的功能的話，只需簡單地繼承這個類就能夠了，沒有必要從頭開始寫代碼。

Hibernate運行在兩種環境下：可管理環境和不可管理環境 　　

· 可管理環境――這種環境可管理以下資源：池資源管理，諸如數據庫鏈接池和還有事務管理、安全定義。一些典型的J2EE服務器（JBoss、Weblogic、WebSphere）已經實現了這些。 　　

· 不可管理環境――只是提供了一些基本的功能，諸如像Jetty或Tomcat這樣的servlet容器環境。

傳統的架構：
1) Session Bean <-> Entity Bean <-> DB

爲了解決性能障礙的替代架構：
2) Session Bean <-> DAO <-> JDBC <-> DB

使用Hibernate來提升上面架構的開發效率的架構：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3個架構來分析：
一、內存消耗：採用JDBC的架構2無疑是最省內存的，Hibernate的架構次之，EB的架構1最差。
二、運行效率：若是JDBC的代碼寫的很是優化，那麼JDBC架構運行效率最高，可是實際項目中，這一點幾乎作不到，這須要程序員很是精通JDBC，運用Batch語句，調整PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的狀況下采用結果集cache等等。而通常狀況下程序員是作不到這一點的。所以Hibernate架構表現出最快的運行效率。EB的架構效率會差的很遠。
三、開發效率：在有JBuilder的支持下以及簡單的項目，EB架構開發效率最高，JDBC次之，Hibernate最差。可是在大的項目，特別是持久層關係映射很複雜的狀況下，Hibernate效率高的驚人，JDBC次之，而EB架構極可能會失敗。