## 1.3 使用方案 前面描述的模塊使得 Spring 可以在很多方案中作為業務邏輯實現的選擇，從 applet 到 使用了 Spring 的事務管理功能和 Web 框架整合，功能完善的企業級應用程序。  典型地功能完善的 Spring Web 應用 Spring 的聲明式事務管理特性（11.5 節）使得 Web 應用程序可以全部事務化，就好像 使用了 EJB 容器管理的事務。全部的自定義業務邏輯可以使用簡單的 POJO 來實現并且被 Spring 的 IoC 容器來管理。其它的服務包含對發送郵件的支持，驗證對 Web 層獨立，這可以 讓你選擇在哪里執行驗證規則。Spring 的 ORM 支持對 JPA，Hibernate,JDO 和 iBatis 進行了整合；比如，當使用 Hibernate 時，你可以繼續使用已有的映射文件和標準的 Hibernate 的 SessionFactory 配置 。表 單控 制器 無縫 地整 合了 Web 層 和領 域模 型， 也去 除了 ActionForm 或其它為領域模型轉換 HTTP 參數的類的需要。  使用了第三方 Web 框架的 Spring 中間層 有時，開發和運行環境并不允許你完全轉換到一個不同的框架中。Spring Framework 不強制你使用其中的部分；它并不是一個所有或沒有的方案。已有使用了 WebWork，Struts， Tapestry 或其它 UI 框架構建的前端應用程序也可以使用基于 Spring 的中間層來進行整合， 這 就 允 許 你 去 使用 Spring 的 事 務 特 性 。 你 僅 僅 需 要 做 的 是 給 業 務 邏 輯 裝 上 ApplicationContext，對整合的 Web 層使用 WebApplicationContext。  遠程調用使用方案 當你需要通過 Web Service 訪問已有的代碼時，你可以使用 Spring 的 Hessian-， Burlap-，Rmi-或 JaxPpcProxyFactory 類。對已有的應用程序開啟遠程訪問并不困難。  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 的依賴。這種選擇并不總是開 放的，但是在公共領域中的替代方法也有其它的建議，根據確切的版本和容器的特性集，您所要求的效果可能會有不同。