1.3 使用方案 · Java 開源項目中文文檔

## 1.3 使用方案前面描述的模塊使得 Spring 可以在很多方案中作為業務邏輯實現的選擇，從 applet 到使用了 Spring 的事務管理功能和 Web 框架整合，功能完善的企業級應用程序。 ![image](img/Image_004.jpg) 典型地功能完善的 Spring Web 應用 Spring 的聲明式事務管理特性（11.5 節）使得 Web 應用程序可以全部事務化，就好像使用了 EJB 容器管理的事務。全部的自定義業務邏輯可以使用簡單的 POJO 來實現并且被 Spring 的 IoC 容器來管理。其它的服務包含對發送郵件的支持，驗證對 Web 層獨立，這可以讓你選擇在哪里執行驗證規則。Spring 的 ORM 支持對 JPA，Hibernate,JDO 和 iBatis 進行了整合；比如，當使用 Hibernate 時，你可以繼續使用已有的映射文件和標準的 Hibernate 的 SessionFactory 配置。表單控制器無縫地整合了 Web 層和領域模型，也去除了 ActionForm 或其它為領域模型轉換 HTTP 參數的類的需要。 ![image](img/Image_005.jpg) 使用了第三方 Web 框架的 Spring 中間層有時，開發和運行環境并不允許你完全轉換到一個不同的框架中。Spring Framework 不強制你使用其中的部分；它并不是一個所有或沒有的方案。已有使用了 WebWork，Struts， Tapestry 或其它 UI 框架構建的前端應用程序也可以使用基于 Spring 的中間層來進行整合，這就允許你去使用 Spring 的事務特性。你僅僅需要做的是給業務邏輯裝上 ApplicationContext，對整合的 Web 層使用 WebApplicationContext。 ![image](img/Image_006.jpg) 遠程調用使用方案當你需要通過 Web Service 訪問已有的代碼時，你可以使用 Spring 的 Hessian-， Burlap-，Rmi-或 JaxPpcProxyFactory 類。對已有的應用程序開啟遠程訪問并不困難。 ![image](img/Image_007.jpg) EJB – 包裝已有的 POJO Spring Framework 也提供了對企業級 Java Bean（EJB，譯者注）的訪問和抽象層（第 21 章），這就可以重用已有的 POJO，可以擴展、包裝它們到無狀態會話 bean，不安全的 Web 應用程序可能也需要聲明式安全。 ### 1.3.1 依賴管理和命名規約依賴管理和依賴注入是不同的概念。要在應用程序中添加 Spring 的優雅特性（比如依賴注入），你需要放置所需的類庫（jar 文件），并且添加到運行時環境的類路徑中，通常在編譯時也是需要這些類庫文件的。這些依賴不是注入的虛擬組件，而是文件系統（通常來說是這樣）上的物理資源。依賴管理的過程包括定位資源，存儲它們，并將它們添加到類路徑中。依賴可以是直接的（比如應用程序在運行時需要 Spring），或者是間接的（比如應用程序需要的 commons-dbcp 組件還依賴于 commons-pool 組件）。間接的依賴也被認為是“過度的”，而且那些依賴本身就難以識別和管理。如果你決定使用 Spring，那么你需要獲得 Spring 的 jar 包，其中要包括你所需要使用的 Spring 的模塊。為了使用的便捷，Spring 被打包成各個模塊的集合，盡可能地分離其中的相互依賴，那么如果你不想編寫 Web 應用程序，就不需要添加 spring-web 模塊的 jar 包。要參考 Spring 模塊的庫，本指南使用了一個可以速記的命名規約， spring-* 或者 spring-*.jar ，這里的“ * ” 代表了各模塊的短名稱（比如， spring-core ， spring-webmvc，spring-jms 等）。實際上 jar 文件命名或許就是這種形式的（參考下面的示例），但也有可能不是這種情況，通常它的文件名中還包含一個版本號（比如， spring-core-3.0.0.RELEASE.jar）。通常，Spring 在四個不同的地方發布組件： * 在社區下載點 [http://www.springsource.org/dow nloads/comm unity](http://www.springsource.org/downloads/community)。在這兒你可以找到所有的 Spring jar 包，它們被壓縮到一個 zip 文件中，可以自由下載。這里 jar 包的命名從 3.0 版本開始，都以 org.springframework.*-<version>.jar 格式進行。 * Maven 的中央庫，也是 Maven 默認檢索的資源庫，它并不會檢索特殊的配置來使用。很多 Spring 所依賴的常用類庫也可以從 Maven 的中央庫中獲得，同時 Spring 社區的絕大多數用戶都使用 Maven 作為依賴管理工具，這對于他們來說是很方便的。這里的 jar 包的命名規則是 spring-*-<version>.jar 格式的，并且 Maven 里的 groupId 是 org.springframework。 * 企業級資源庫（Enterprise Bundle Repository，EBR），這是由 SpringSource 組織運營的，同時也提供了和 Spring 整合的所有類庫。對于所有 Spring 的 jar 包及其依賴，這里也有 Maven 和 Ivy 的資源庫，同時這里還有很多開發人員在使用 Spring 編寫應用程序時能用到的其它大量常用類庫。而且，發布的版本，里程碑版本和開發版本也都部署在這里。這里 jar 文件的命名規則和從社區下載的（`org.springframework.*-<version>.jar`）一致，并且所依賴的外部類庫（不是來自 SpringSource 的）也是使用的這種“長命名”的形式，并以 com.springsource 作為前綴。可以參考 [FAQ](http://ebr.springsource.com/repository/app/faq) 部分獲取更多信息。 * 在 Amazon S3 為開發和里程碑版本發布（最終發布的版本這里也會有）而設置的公共Maven 資源庫。Jar 文件的名稱和 Maven 中央庫是一樣的，那么這里是獲取 Spring 開發版本的地方，其它的類庫是部署于 Maven 中央庫的。那么，首先你要決定的事情是如何管理這些依賴：很多人使用自動化的系統，比如 Maven 和 Ivy，但是你也可以手動下載所有的 jar 文件。當使用 Maven 或 Ivy 獲取 Spring 時，之后你就需要決定從哪里來獲取它們。通常來說，如果你關注 OSGi 的話，那么就使用 EBR，因為它對所有的 Spring 依賴兼容 OSGi，比如 Hibernate 和 Freemarker。如果對 OSGi 不感興趣，那么使用哪個下載都是可以的，但是他們也各有利弊。通常來講，為你的項目選擇一個或者備用的一個；但是請不要混用。因為相對于 Maven 中央庫而言，EBR 組件非常需要一個不同的命名規則，那么這就特別重要了。表 1.1 Maven 中央庫和 SpringSource EBR 資源庫的比較 | 特性 | Maven 中央庫 | EBR | | --- | --- | --- | | OSGi 的兼容 | 不明確 | 是 | | 組件數量 | 成千上萬；所有種類 | 幾百個；是 Spring 整合中會用到的 | | 一致的命名規約 | 沒有 | 有 | | 命名規約：GroupId | 相異。新組件通常使用域名，比如 org.slf4j。老組件通常僅僅使用組件名，比如 log4j。 | 原始的域名或主包的根路徑，比如 org.springframework | | 命名規約：ArtifactId | 相異。通常是項目或模塊名，使用連字符“-”分隔，比如 spring-core，log4j。 | 捆綁符號名稱，從主包的路徑分離，比如 org.springframework.beans。如果 jar 需要修補以保證兼容 OSGi，那么就附加 com.springsource ，比如 com.springsource.org.apache.log4j | | 命名規約：Version | 相異。很多新的組件使用 m.m.m 或 m.m.m.X（m 是數字，X 是文本）。老的使用 m.m。有一些也不是。順序是確定的但通常并不可靠，所以不是嚴格的可靠。 | OSGi 版本數字 m.m.m.X，比如 3.0.0.RC3。文本標識符使用相同的數字值規定版本的字母順序。 | | 發布 | 通常是自動通過 rsync 或源碼控制更新。項目作者可以上傳獨立的 jar 文件到 JIRA。 | 手動（由 SpringSource 控制的 JIRA） | | 質量保證 | 根據政策。精確度是作者的責任。 | 寬泛的 OSGi 清單，Maven POM 和 Ivy 元數據。QA 由 Spring 團隊執行。 | | 主機 | Contegix 提供。由 Sonatype 和一些鏡像構成。 | 由 SpringSource 的 S3 構成 | | 搜索工具 | 很多 | [http://www.springsource.com/repository](http://www.springsource.com/repository) | | 和 SpringSource 工具整合 | 通過和 Maven 依賴管理的 STS 來整合 | 通過 Maven ，Roo ，CloudFoundry 的STS 進行寬泛整合 | #### 1.3.1.1 Spring 依賴和基于 Spring 盡管 Spring 提供對整合的支持，以及對大量企業級應用及其外部工具的支持，那么它也有心保持它的強制依賴在一個絕對小的數目上：你不需要為了簡單的使用去定位并下載（甚至是自動地）大量的 jar 來使用 Spring。對于基本的依賴注入那只需要一個必須的外部依賴，就是日志（可以參考下面關于日志的深入介紹）。下面，我們來概述一下配置一個基于 Spring 的應用程序所需的基本配置，首先使用 Maven 和 Ivy。在所有的示例中，如果有哪一點不清楚，可以參考你所使用的依賴管理系統的相關文檔，或者參考一些示例代碼 – Spring 本身在構建時使用了 Ivy 來管理依賴，而我們大多數的示例卻使用 Maven。 #### 1.3.1.2 Maven 依賴管理如果你正使用 Maven 來進行依賴管理，那么你就不需要明確地提供日志依賴。比如，要為應用程序配置創建應用上下文并使用依賴注入特性，那么，你的 Maven 依賴配置文件可以是這樣的： ``` <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>3.0.0.RELEASE</version> <scope>runtime</scope> </dependency> </dependencies> ``` 就是這么簡單。要注意的是，如果你在編譯代碼時不需要使用 Spring 的 API，那么 scope 元素可以聲明為 runtime，這就可以用于典型的依賴注入用例。在上面的示例中，我們使用了 Maven 中央庫中的命名規約，那么它就可以在 Maven 中央庫或 SpringSource S3 的 Maven 資源庫中起作用。要使用 S3 的 Maven 資源庫（比如里程碑版本或開發快照）版本，那就需要在 Maven 的配置文件中明確地指定資源庫的位置。對于完整發布版，配置如下： ``` <repositories> <repository> <id>com.springsource.repository.maven.release</id> <url>http://maven.springframework.org/release/</url> <snapshots><enabled>false</enabled></snapshots> </repository> </repositories> ``` 對于里程碑版本配置如下： ``` <repositories> <repository> <id>com.springsource.repository.maven.milestone</id> <url>http://maven.springframework.org/milestone/</url> <snapshots><enabled>false</enabled></snapshots> </repository> </repositories> ``` 對于開發快照版本配置如下： ``` <repositories> <repository> <id>com.springsource.repository.maven.snapshot</id> <url>http://maven.springframework.org/snapshot/</url> <snapshots><enabled>true</enabled>< /snapshots> </repository> </repositories> ``` 要使用 SrpingSource 的 EBR 的話，你還需要一個對依賴不同的命名規約。名稱通常很容易去猜測，比如這個示例中，就是： ``` <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>org.springframework.context</artifactId> <version>3.0.0.RELEASE</version> <scope>runtime</scope> </dependency> </dependencies> ``` 你也可能需要明確地聲明資源庫的位置（僅僅 URL 是重要的）： ``` <repositories> <repository> <id>com.springsource.repository.bundles.release</id> <url>http://repository.springsource.com/maven/bundles/release/</url> </repository> </repositories> ``` 如果你要手動地去管理依賴，在上面這個聲明的資源庫 URL 是不可以瀏覽的，但是它也有一個用戶界面，地址是 [http://www.springsource.com/repositor y](http://www.springsource.com/repository)，這可以用來搜索和下載依賴。它也有 Maven 和 Ivy 配置的代碼片段，你可以復制下來并粘貼到你所使用的工具中，很方便使用。 #### 1.3.1.3 Ivy 依賴管理如果你使用 [Ivy](http://ant.apache.org/ivy) 來管理依賴，那么有一些簡單的命名規約和配置選項。要配置 Ivy 定位到 SpringSource EBR 中，需要添加如下的解析器元素到你的配置文件 ivysettings.xml 中： ``` <resolvers> <url name="com.springsource.repository.bundles.release"> <ivy pattern="http://repository.springsource.com/ivy/bundles/release / [organisation]/[module]/[revision]/[artifact] -[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/bundles/release / [organisation]/[module]/[revision]/ [artifact]-[revision].[ext]" /> </url> <url name="com.springsource.repository.bundles.external"> <ivy pattern="http://repository.springsource.com/ivy/bundles/externa l/ [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/bundles/externa l/ [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> </url> </resolvers> ``` 上面的 XML 并不是合法的格式，因為行太長了 – 如果你要復制粘貼，那么要移除中部 url 模式部分結尾額外的行。（本文檔中已經去除）一旦 Ivy 配置好去查看 EBR，那么添加依賴就很簡單了。只要拉起在資源庫瀏覽器中的捆綁詳細信息頁面，你就會發現為你準備好的 Ivy 代碼片段，那么就可以將它包含到你的依賴部分中了。比如（在 ivy.xml 中）： ``` <dependency org="org.springframework" name="org.springframework.core" rev="3.0.0.RELEASE" conf="compile->runtime"/> ``` ### 1.3.2 日志對于 Spring 來說，日志是一個非常重要的依賴，因為 a)這是唯一強制的外部依賴，b) 開發人員都會想看到他們所使用的工具的一些輸出內容，而且 c)Spring 整合了多種實用工具，它們都會選擇一種日志依賴包。應用程序開發人員的目標之一就是在核心位置對整個應用程序有一個統一的日志配置，包括對所有的外部組件。因為日志框架有多種選擇，那么這就可能有些難以確定了。 Spring 中強制的日志依賴包是 Jakarta 的 Commons Logging API（JCL）。我們對 Spring 的編譯是基于 JCL 的，而且我們使擴展了 Spring Framework 的類對 JCL 包的 Log 對象都是可見的。對于用戶來說，所有 Spring 的版本都使用相同的日志包也是很重要的：因為保留了向后兼容的特性，那么遷移是很容易進行的，同理，擴展 Spring 的應用程序也是這樣。我們這樣做就是使得 Spring 中的模塊明確地使用基于 commons-logging（JCL 的典型實現）的日志實現，在編譯時也使得其它模塊都基于這個日志包。如果你正在使用 Maven 的話，同時想知道在哪兒獲取到的 commons-logging 依賴，那就是從 Spring 中被稱作是 spring-core 的核心模塊中獲取的。關于 commons-logging 比較好的做法是你不需要做其它的步驟就可以使應用程序運行起來。它有一個運行時的查找算法，在我們都知道的類路徑下尋找其它的日志框架，并且使用 Spring 認為是比較合適的（或者告訴 Spring 你需要使用的具體是哪一個）一個。如果沒有找到可用的，那么你會得到一個來自 JDK（java.util.logging 或者簡稱為 JUL）本身看起來還不錯的日志依賴。那么，你會發現在很多時候，Spring 應用程序運行中會有日志信息打印到控制臺上，這點是很重要的。 #### 1.3.2.1 不使用 Commons Logging 不幸的是，commons-logging 的運行時查找算法對最終用戶方便是有些問題的。如果我們可以讓時光倒流并讓 Spring 從現在開始作為一個新的項目進行，那么我們會使用不同的日志依賴。首選的日志依賴可能就是 Java 簡單的日志門面（[SLF4 J](http://www.slf4j.org/)），SLF4J 也被 Spring 的開發人員在他們其它應用程序中的很多工具所使用。關閉 commons-logging 也很簡單：僅僅要確認在運行時，它的包不在類路徑下就可以了。在 Maven 中要去掉這個依賴，因為 Spring 依賴聲明的時候會帶進來，那么就需要這么來進行。 ``` <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>3.0.0.RELEASE</version> <scope>runtime</scope> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> </dependencies> ``` 目前這個應用程序可能就不能運行了，因為在類路徑中已經沒有了 JCL API 的實現了，所以要修復這個問題的話，就要提供另外一種日志的實現了。在下一節中，我們來說明如何提供一個其它的 JCL 的實現，這里，我們使用 SLF4J 作為示例。 #### 1.3.2.2 使用 SLF4J SLF4J 是一個整潔的日志依賴，在運行時的效率也比 commons-logging 更高，因為 SLF4J 使用了編譯時構建，而不是運行時去查找其它整合的日志框架。這也就意味著你可以更明確地在運行時去做些什么，并且去聲明或配置。SLF4J 為很多通用的日志框架提供的綁定，所以通常你可以選擇已有的一個，并去綁定配置或管理。 SLF4J 為很多通用日志框架提供綁定，包括 JCL，并且也可以反向進行：橋接其它的日志框架和 SLF4J 本身。所以如果要在 Spring 中使用 SLF4J，那么就需要使用 SLF4J-JCL 橋來代替 commons-logging 依賴。只要配置好了，那么來自 Spring 的日志調用就會被翻譯成調用 SLF4J 的 API 了，如果在應用程序中的其它類庫使用了原有的 API，那么會有一個單獨的地方來進行配置和管理的日志。一個常用的選擇就是橋接 Spring 到 SLF4J API，之后提供從 SLF4J 到 Log4J 的明確綁定。你需要提供 4 種依賴（并排除已經存在的 commons-logging 依賴）：橋接工具，SLF4J 的 API，綁定到 Log4J 的工具，還有 Log4J 本身的實現。那么在 Maven 的配置文件中，你就可以這樣來做： ``` <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>3.0.0.RELEASE</version> <scope>runtime</scope> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.5.8</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.5.8</version> <scope>runtime</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.5.8</version> <scope>runtime</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> <scope>runtime</scope> </dependency> </dependencies> ``` 這樣，看起來好像很多依賴都需要日志了。情況確實是這樣，但 SLF4J 是可選的，而且它的性能要比含有類加載器問題的 commons-logging 依賴好很多，尤其是如果你使用了一個嚴格限制的容器，比如 OSGi 平臺。據稱那也會有性能優勢，因為綁定是編譯時進行的，而不是在運行時。另外，在 SLF4J 的用戶中一個較為常見的選擇是使用很少步驟，同時產生更少的依賴，那也就是直接綁定到 [Logback](http://logback.qos.ch/) 上。這會去掉很多額外的綁定步驟，因為 Logback 本身直接實現了 SLF4J ，這樣的話，你就僅需要兩個依賴的類庫，而不原先的是四個了（就是 jcl-over-slf4j 和 logback）。如果你也確實那么來做了，你可能還需要從其它外部依賴（而不是 Spring）中去掉 slf4j-api 的依賴，因為在類路徑中只保留一個 API 的一個版本就行了。 #### 1.3.2.3 使用 Log4J 很多用戶出于配置和管理的目的而使用 [Log4j](http://logging.apache.org/log4j) 作為日志框架。這樣也同樣很有效率并且易于創建，而且，Log4j 也是我們事實上在構建和測試 Spring 時，和運行時環境中使用的日志框架。Spring 本身也提供一些工具來配置和初始化 Log4j，所以，在某些模塊中它也提供了可選的在編譯時對 Log4j 框架的依賴。要讓 Log4j 框架和默認的 JCL 依賴（commons-logging）同時起作用，你所要做的就是要將 Log4j 的類庫放到類路徑下，并且提供配置文件（在類路徑的根路徑下放置 log4j.properties 或 log4j.xml 為名的文件）。而對于使用 Maven 的用戶來說，下面的代碼可以是對依賴的聲明： ``` <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>3.0.0.RELEASE</version> <scope>runtime</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> <scope>runtime</scope> </dependency> </dependencies> ``` 下面是 log4j.properties 打印到控制臺的日志的配置示例： ``` log4j.rootCategory=INFO, stdout log4j.appender.stdout=org.apache.log4j .ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n log4j.category.org.springframework.beans.factory=DEBUG ``` 運行時容器和本地的 JCL 很多用戶在容器中運行 Spring 的應用程序，而該容器本身也提供了 JCL 的實現。比如 IBM 的 Webshphere 應用服務器（WAS）就是這種類型的。這通常就會引起問題，而不幸的是沒有什么解決的方法；很多情況下僅僅從應用程序中去掉 commons-logging 依賴是不夠的。我們要清楚地認識這一點：這個問題通常和 JCL 本身一同報告出來，或者是和 commons-logging：而不是綁定 commons-logging 到另外的框架（這里，通常是 Log4J）。這就可能會引發問題，因為 commons-logging 改變了它們在運行時環境里，在一些容器中查找老版本（1.0）的方式，而現在很多人使用的是新版本（1.1）。Spring 不會使用任何不通用的 JCL API 部分，所以這里不會有問題，但是 Spring 本身或應用程序嘗試去進行日志記錄，你可以發現綁定到 Log4J 是不起作用的。這種在 WAS 上的情況，最簡單的做法就是顛倒類加載器的層次（IBM 稱之為“parent last”），那么就是使應用程序來控制，而不是容器來控制 JCL 的依賴。這種選擇并不總是開放的，但是在公共領域中的替代方法也有其它的建議，根據確切的版本和容器的特性集，您所要求的效果可能會有不同。