【導(dǎo)讀】起止時間：2021年3月2日至2021年6月12日

　　

【正文】 所有的這些角色都合并在一個單獨的對象里。 WebWork允許你在表單中使用現(xiàn)有的業(yè)務(wù)對象，但是只能把它們定義成不同 Action類的 bean屬性。更重要的是，在運算和表單賦值時，使用的是同一個處理請求的 Action 實例。因此，引用數(shù)據(jù)也需要被定義成 Action的 bean屬性。這樣在 一個對象就承擔了太多的角色。 對于視圖： Spring的視圖解析相當靈活。一個控制器實現(xiàn)甚至可以直接輸出一個視圖作為響應(yīng)，這需要使用 null返回 ModelAndView。在一般的情況下，一個 ModelAndView 實例包含視圖名字和模型映射表，模型映射表提供了 bean 的名字及其對象（比如命令對象或表單對象，引用數(shù)據(jù)等等）的對應(yīng)關(guān)系。視圖名解析的配置是非常靈活的，可以通過 bean的名字，屬性文件或者你自己的 ViewResolver 來實現(xiàn)。抽象的模型映射表完全抽象了表現(xiàn)層，沒有任何限制： JSP， Velocity， 或者其它的技術(shù) —— 任何表現(xiàn)層都可以直接和 Spring集成。模型映射表僅僅將數(shù)據(jù)轉(zhuǎn)換成合適的格式，比如 JSP 請求屬性或者 Velocity 模版模型。 MVC實現(xiàn)的可擴展性 許多團隊努力爭取在技術(shù)和工具方面能使他們的投入更有價值，無論是現(xiàn)有的項目還是新的項目都是這樣。具體地說， Struts 不僅有大量的書籍和工具，而且有許多開發(fā)者熟悉它。因此，如果你能忍受 Struts的架構(gòu)性缺陷，它仍然是 web層一個很好的選擇。 WebWork和其它 web框架也是這樣。 如果你不想使用 Spring的 web MVC框架，而僅僅想使用 Spring提供的其它功能，你可以 很 容 易 地將 你 選 擇的 web 框 架和 Spring 結(jié) 合 起 來。 只 要通 過 Spring 的ContextLoadListener 啟動一個 Spring的根應(yīng)用上下文，并且通過它的 ServletContext 屬性（或者 Spring的各種幫助方法）在 Struts或 WebWork的 Action中訪問。注意到現(xiàn)在沒有提到任何具體的 “plugins” ，因此這里也沒有提及如何集成：從 web層的角度看，你可以僅僅把 Spring作為一個庫使用，根應(yīng)用上下文實例作為入口。 所有你注冊的 bean和 Spring的 服務(wù)可以在沒有 Spring的 web MVC下被訪問。 Spring并沒有在使用方法上和 Struts 或 WebWork 競爭，它只是提供單一 web 框架所沒有的功能，從 bean的配置到數(shù)據(jù)訪問和事務(wù)處理。所以你可以使用 Spring 的中間層和（或者）數(shù)據(jù)訪問層來增強你的應(yīng)用，即使你只是使用象 JDBC或 Hibernate 事務(wù)抽象這樣的功能。 Spring MVC 框架的特點 如果僅僅關(guān)注于 web方面的支持， Spring 有下面一些特點： 清晰的角色劃分：控制器，驗證器，命令對象，表單對象和模型對象；分發(fā)器，處理器映射和視圖解 析器；等等。 直接將框架類和應(yīng)用類都作為 JavaBean 配置，包括通過應(yīng)用上下文配置中間層引用，例如，從 web控制器到業(yè)務(wù)對象和驗證器的引用。 可適應(yīng)性，但不具有強制性：根據(jù)不同的情況，使用任何你需要的控制器子類（普通控制器，命令，表單，向?qū)?，多個行為，或者自定義的），而不是要求任何東西都要從Action/ActionForm 繼承。 可重用的業(yè)務(wù)代碼，而不需要代碼重復(fù)：你可以使用現(xiàn)有的業(yè)務(wù)對象作為命令對象或表單對象，而不需要在 ActionForm 的子類中重復(fù)它們的定義。 可定制的綁定和驗證：將類型不匹配作為應(yīng)用級的驗證錯誤，這可以保存錯誤的值，以及本地化的日期和數(shù)字綁定等，而不是只能使用字符串表單對象，手動解析它并轉(zhuǎn)換到業(yè)務(wù)對象。 可定制的處理器映射，可定制的視圖解析：靈活的模型可以根據(jù)名字 /值映射，處理器映射和視圖解析使應(yīng)用策略從簡單過渡到復(fù)雜，而不是只有一種單一的方法。 可定制的本地化和主題解析，支持 JSP，無論有沒有使用 Spring 標簽庫，支持 JSTL，支持不需要額外過渡的 Velocity，等等。 簡單而強大的標簽庫，它盡可能地避免在 HTML生成時的開銷，提供在標記方 面的最大靈活性。 使用 ORM工具進行數(shù)據(jù)訪問 Spring 在資源管理， DAO 實現(xiàn)支持以及實物策略等方面提供了與 Hibernate, JDO 和iBATIS SQL 映射的集成。 對 Hibernate， Spring使用了很多 IoC的方便的特性提供了一流的支持，幫助你處理很多典型的 Hibernate 整合的問題。所有的這些都遵守 Spring 通用的事務(wù)和 DAO異常體系 .。 當您選擇使用 O/R 映射來創(chuàng)建數(shù)據(jù)訪問應(yīng)用程序的時候， Spring 的增加部分就會向您提供重要的支持。首先你應(yīng)該了解的是，一旦你使用了 Spring 對 O/R 映射的支持，你不需要親自作所有的事情。在決定花費力氣，冒著風險建造類似的內(nèi)部底層結(jié)構(gòu)之前，我們都建議您考慮和利用 Spring 的解決方案。不管你使用的是何種技術(shù)，大部分的 O/R 映射支持都可以以 library 樣式被使用，因為所有的東西都是被設(shè)計成一組可重復(fù)利用的 JavaBeans。在 ApplicationContext 和 BeanFactory 中使用更是提供了配置和部署簡單的好處，因此，這一章里的大多數(shù)例子都是在 ApplicationContext 中配置。 使用 Spring構(gòu)建你的 ORM應(yīng)用的好處包括 : 測試簡單 . Spring 的 IoC使得很容易替換掉不同的實現(xiàn)， Hibernate SessionFacotory的位置， datasource, 事務(wù)管理 , 映射對象的實現(xiàn)。這樣就很容易隔離測試持久化相關(guān)代碼的各個部分。 異常包裝。 Spring 能夠包裝 Hibernate 異常，把它們從專有的， checked exception變?yōu)橐唤M抽象的 runtime exception。這樣你就可以僅僅在恰當?shù)膶犹幚泶蟛糠值牟豢苫謴?fù)的異常，使你避免了很多討厭的 catch/throw以及異常聲明。你還是可以在你需要的地方捕捉和處理異常?；叵胍幌?JDBC異常（包括與 DB相關(guān)的方言）被轉(zhuǎn)變?yōu)橥瑯拥漠惓ｓw系，這就意味著你可以在一致的編程模型中處理 JDBC操作。 通用的資源管理。 Spring 的 application context 能夠處理諸如 Hibernate 的SessionFactory， JDBC 的 datasource， iBatis 的 SQLMaps 配置對象以及其他相關(guān)資源的定位和配置。這使得這些配置的值很容易被管理和修改。 Spring 提供了有效，簡單和安全的 Hibernate Session 處理。一般的使用 Hibernate 的代碼則需要使用同一個 Hibernate Session 對象以確保有效和恰當?shù)厥聞?wù)處理。而 Spring 讓我們可以很容易透明地創(chuàng)建和綁定一個 session 到當前線程；你可以使用以下兩種辦法之一：聲明式的 AOP方法攔截器，或通過使用一個外部的 template 包裝類在 Java 代碼層次實現(xiàn)。這樣， Spring就解決了在很多 Hibernate 論壇上出現(xiàn)的使用問題。 綜合的事務(wù)管理 。 Spring 允許你包裝你的 ORM代碼，通過使用聲明式的 AOP 方法攔截器或者在代碼級別使用外部的 template 包裝類。不管使用哪一種， 事務(wù)相關(guān)的語義都會為你處理，萬一有異常發(fā)生也會幫你做適當?shù)氖聞?wù)操作（比如 rollback）。就象我們下面要討論的一樣，你能夠使用和替換各種 transaction managers，卻不會使你的 Hibernate 相關(guān)的代碼受到影響。更好的是， JDBC 相關(guān)的代碼可以完全和 Hibernate 代碼 integrate transactionaly。這對于處理那些沒有用 Hibernate 或 iBatis 實現(xiàn)的功能非常有用。 避免綁定特殊的技術(shù)，允許 mixandmatch的實現(xiàn)策略。 雖然 Hibernate 非常強大，靈 活，開源而且免費，但它還是使用了自己的特定的 API。此外有人也許會爭辯： iBatis更輕便而且在不需要復(fù)雜的 O/R映射策略的應(yīng)用中使用也很優(yōu)秀。能夠選擇的話，使用標準或抽象的 API來實現(xiàn)主要的應(yīng)用需求，通常是更好的。尤其，當你可能會因為功能，性能或其他方面的原因而需要切換到另一個實現(xiàn)的時候。舉例來說， Spring 對 Hibernate 事務(wù)和異常的抽象，以及能夠讓你輕松交換 mapper和 DAO對象（實現(xiàn)數(shù)據(jù)訪問功能）的 IoC機制，這兩個特性可以讓你在不犧牲 Hibernate性能的情況下，在你的應(yīng)用程序中隔離 Hibernate的相關(guān)代碼。處理 DAO的高層次的 service 代碼不需要知道 DAO的具體實現(xiàn)。這個方法可以很容易使用 mixandmatch方案互不干擾地實現(xiàn)數(shù)據(jù)訪問層（比如在一些地方用 Hibernate，一些地方使用 JDBC，其他地方使用 iBatis）， mixandmatch有利于處理遺留下來的代碼以及利用各種技術(shù)（ JDBC,Hibernate,iBatis）的長處 .。 Spring 提供了一致的事務(wù)管理抽象。這個抽象是 Spring 最重要的抽象之一， 它有如下的優(yōu)點： 為不同的事務(wù) API提供一致的編程模 型，如 JTA、 JDBC、 Hibernate、 iBATIS數(shù)據(jù)庫層 和JDO 提供比大多數(shù)事務(wù) API更簡單的，易于使用的編程式事務(wù)管理 API 整合 Spring數(shù)據(jù)訪問抽象 支持 Spring聲明式事務(wù)管理 傳統(tǒng)上， J2EE開發(fā)者有兩個事務(wù)管理的選擇 : 全局事務(wù)或 局部事務(wù)。全局事務(wù)由應(yīng)用服務(wù)器管理，使用 JTA。局部事務(wù)是和資源相關(guān)的：例如，一個和 JDBC 連接關(guān)聯(lián)的事務(wù)。這個選擇有深刻的含義。 全局事務(wù)可以用于多個事務(wù)性的資源（需要指出的是多數(shù)應(yīng)用使用單一事務(wù)性 的資源）。使用局部事務(wù)，應(yīng)用服務(wù)器不需要參與事務(wù)管 理，并且不能幫助確保 跨越多個資源的事務(wù)的正確性。 全局事務(wù)有一個顯著的不利方面，代碼需要使用 JTA：一個笨重的 API（部分是 因為它的異常模型）。此外， JTA的 UserTransaction 通常需 要從 JNDI獲得，這意味著我為了 JTA需要同時使用 JNDI和 JTA。 顯然全部使用全局事務(wù)限制了應(yīng)用代碼的重用性，因為 JTA通常只在應(yīng)用服務(wù)器的環(huán)境中才能使用。 使用全局事務(wù)的比較好的方法是通過 EJB 的 CMT （容器管理的事務(wù)）： 聲明式事務(wù)管理的一種形式（區(qū)別于編程式事務(wù)管理 ）。 EJB 的 CMT 不需要任何和事 務(wù)相關(guān)的 JNDI 查找，雖然使用 EJB 本身 肯定需要使用 JNDI。它消除大多數(shù) —— 不是全部 —— 書寫 Java 代碼控制事務(wù)的需求。 顯著的缺點是 CMT綁定在 JTA和應(yīng)用服務(wù)器環(huán)境上，并且只有我們選擇 使用 EJB實現(xiàn)業(yè)務(wù)邏輯，或者至少處于一個事務(wù)化 EJB的外觀（ Facade）后 才能使用它。 EJB有如此多的詬病，當存在其它聲明式事務(wù)管理時， EJB不是一個吸引人的建議。 局部事務(wù)容易使用，但也有明顯的缺點：它們不能用于多個事務(wù)性資 源，并且趨向侵入的編程模型。例如，使用 JDBC連接事務(wù)管理的代碼不能用于 全局的 JTA事務(wù)中。 Spring 解決了這些問題。它使應(yīng)用開發(fā)者能夠使用在任何環(huán)境 下使用一致的編程模型。你可以只寫一次你的代碼，這在不同環(huán)境 下的不同事務(wù)管理策略中很有益處。 Spring同時提供聲明式和編程式事務(wù)管理。 使用編程式事務(wù)管理，開發(fā)者直接使用 Spring事務(wù)抽象，這個抽象可以使用在任何 底層事務(wù)基礎(chǔ)之上。使用首選的聲明式模型，開發(fā)者通常書寫很少的事務(wù)相關(guān)代 碼，因此不依賴 Spring或任何其他事務(wù) API。