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