亚洲免费综合色在线视频,亚洲一二成人精品区,亚洲人成网7777777国产

Introducing to Spring Framework

Introducing to Spring Framework

作者：Rod Johnson
譯者：yanger，taowen
校對(duì)：taowen

關(guān)于Spring Framework，今年夏天你可能已經(jīng)聽見很多的議論。在本文中,我將試圖解釋Spring能完成什么，和我怎么會(huì)認(rèn)為它能幫助你開發(fā)J2EE應(yīng)用程序。

又來一個(gè)framework？

你可能正在想“不過是另外一個(gè)的framework”。當(dāng)已經(jīng)有許多開放源代碼(和專有) J2EE framework時(shí)，為什么你還要耐下心子讀這篇文章或去下載Spring Framework？

我相信Spring是獨(dú)特的，有幾個(gè)原因：

Spring不會(huì)給你的工程添加對(duì)其他的框架依賴。Spring也許稱得上是個(gè)一站式解決方案，提供了一個(gè)典型應(yīng)用所需要的大部分基礎(chǔ)架構(gòu)。它還涉及到了其他framework沒有考慮到的內(nèi)容。

盡管它僅僅是一個(gè)從2003年2月才開始的開源項(xiàng)目，但Spring有深厚的歷史根基。這個(gè)開源工程是起源自我在2002年晚些時(shí)候出版的《Expert One-on-One J2EE設(shè)計(jì)與開發(fā)》書中的基礎(chǔ)性代碼。這本書展示了Spring背后的基礎(chǔ)性架構(gòu)思想。然而，對(duì)這個(gè)基礎(chǔ)架構(gòu)的概念可以追溯到2000年的早些時(shí)候,并且反映了我為一系列商業(yè)工程開發(fā)基礎(chǔ)結(jié)構(gòu)的成功經(jīng)驗(yàn)。

2003年1月，Spring已經(jīng)落戶于SourceForge上了。現(xiàn)在有10個(gè)開發(fā)人員，其中6個(gè)是高度投入的積極分子。

Spring架構(gòu)上的好處

在我們進(jìn)入細(xì)節(jié)之前，讓我們來看看Spring能夠給工程帶來的種種好處：

Spring確實(shí)使你能通過最簡(jiǎn)單可行的解決辦法來解決你的問題。而這是有有很大價(jià)值的。

Spring做了些什么？

Spring提供許多功能，在此我將依次快速地展示其各個(gè)主要方面。

任務(wù)描述

首先,讓我們明確Spring范圍。盡管Spring覆蓋了許多方面，但我們對(duì)它應(yīng)該涉什么，什么不應(yīng)該涉及有清楚的認(rèn)識(shí)。

Spring的主要目的是使J2EE易用和促進(jìn)好編程習(xí)慣。

Spring 不重新輪子。因此，你發(fā)現(xiàn)在Spring中沒有l(wèi)ogging，沒有連接池，沒有分布式事務(wù)調(diào)度。所有這些東西均有開源項(xiàng)目提供(例如我們用于處理所有日志輸出的Commons Logging以及Commons DBCP)，或由你的應(yīng)用程序服務(wù)器提供了。出于同樣的的原因，我們沒有提供O/R mapping層。對(duì)于這個(gè)問題已經(jīng)有了像Hibernate和JDO這樣的優(yōu)秀解決方案。

Spring的目標(biāo)就是讓已有的技術(shù)更加易用。例如，盡管我們沒有底層事務(wù)協(xié)調(diào)處理，但我們提供了一個(gè)抽象層覆蓋了JTA或任何其他的事務(wù)策略。

Spring 沒有直接和其他的開源項(xiàng)目競(jìng)爭(zhēng)，除非我們感到我們能提供新的一些東西。例如，象許多開發(fā)人員一樣，我們從來沒有對(duì)Struts感到高興過，并且覺得到在 MVC web framework中還有改進(jìn)的余地。在某些領(lǐng)域，例如輕量級(jí)的IoC容器和AOP框架，Spring確實(shí)有直接的競(jìng)爭(zhēng)，但是在這些領(lǐng)域還沒有已經(jīng)較為流行的解決方案。(Spring在這些領(lǐng)域是開路先鋒。)

Spring也得益于內(nèi)在的一致性。所有的開發(fā)者都在唱同樣的的贊歌，基礎(chǔ)想法依然與Expert One-on-One J2EE設(shè)計(jì)與開發(fā)中提出的差不多。并且我們已經(jīng)能夠在多個(gè)領(lǐng)域中使用一些中心的概念，例如Inversion of Control。

Spring在應(yīng)用服務(wù)器之間是可移植的。當(dāng)然保證可移植性總是一種挑戰(zhàn)，但是我們避免使用任何平臺(tái)特有或非標(biāo)準(zhǔn)的東西，并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的應(yīng)用服務(wù)器上的用戶。

Inversion of Control 容器

Spring設(shè)計(jì)的核心是 org.springframework.beans 包, 它是為與JavaBeans一起工作而設(shè)計(jì)的。這個(gè)包一般不直接被用戶使用，而是作為許多其他功能的基礎(chǔ)。

下一個(gè)層面高一些的抽象是"Bean Factory"。一個(gè)Spring bean factory 是一個(gè)通用的Factory，它使對(duì)象能夠按名稱獲取，并且能管理對(duì)象之間的關(guān)系。

Bean factories 支持兩種模式的對(duì)象：

由于 org.springframwork.beans.factory.BeanFactory是一個(gè)簡(jiǎn)單的接口，它能被大量底層存儲(chǔ)方法實(shí)現(xiàn)。你能夠方便地實(shí)現(xiàn)你自己的BeanFactory，盡管很少用戶需要這么做。最為常用的BeanFactory定義是：

每個(gè)bean定義可能是一個(gè)POJO（通過類名和JavaBean初始屬性定義），或是一個(gè)FactoryBean。FactoryBean接口添加了一個(gè)間接層。通常，這用于創(chuàng)建使用AOP或其他方法的代理對(duì)象：例如，添加聲明性事務(wù)管理的代理。（這在概念上和EJB的interception相似，但實(shí)現(xiàn)得更簡(jiǎn)單。）

BeanFactories能在一個(gè)層次結(jié)構(gòu)中選擇性地參與，繼承ancestor（祖先）的定義。這使得在整個(gè)應(yīng)用中公共配置的共享成為可能，雖然個(gè)別資源，如controller servlets，還擁有他們自己的獨(dú)立的對(duì)象集合。

這種使用JavaBeans的動(dòng)機(jī)在《Expert One-on-One J2EE Design and Development》的第四章中有描述，在TheServerSide網(wǎng)站上的有免費(fèi)的PDF版本(http: //www.theserverside.com/resources/article.jsp?l=RodJohnsonInterview)。

通過BeanFactory概念，Spring成為一個(gè)Inversion of Control的容器。(我不怎么喜歡container這個(gè)詞，因?yàn)樗谷寺?lián)想到重量級(jí)容器，如EJB容器。Spring的BeanFactory是一個(gè)可通過一行代碼創(chuàng)建的容器，并且不需要特殊的部署步驟。)

Inversion of Control背后的概念經(jīng)常表述為Hollywood原則的：“Don’t call me， I’ll call you。” IoC將控制創(chuàng)建的職責(zé)搬進(jìn)了框架中，并把它從應(yīng)用代碼脫離開來。涉及到配置的地方，意思是說在傳統(tǒng)的容器體系結(jié)構(gòu)中，如EJB，一個(gè)組件可以調(diào)用容器并問“我需要它給我做工作的對(duì)象X在哪里?”；使用IoC容器則只需指出組件需要X對(duì)象，在運(yùn)行時(shí)容器會(huì)提供給它。容器是通過查看方法的參數(shù)表（例如 JavaBean的屬性）做到的，也可能根據(jù)配置數(shù)據(jù)如XML。

IoC有幾個(gè)重要的好處，例如：

最后應(yīng)該強(qiáng)調(diào)的是，IoC 不同于傳統(tǒng)的容器的體系結(jié)構(gòu)，如EJB，應(yīng)用代碼最小程度地依靠于容器。這意味著你的業(yè)務(wù)對(duì)象可以潛在的被運(yùn)行在不同的IoC 框架上——或者在任何框架之外——不需要任何代碼的改動(dòng)。

以我和其他Spring用戶的經(jīng)驗(yàn)來說，再怎么強(qiáng)調(diào)IoC給應(yīng)用程序代碼帶來的好處也不為過。

IoC 不是一個(gè)新概念，但是它在J2EE團(tuán)體里面剛剛到達(dá)黃金時(shí)間。有一些可供選擇的IoC 容器: 例如 Apache Avalon, PicoContainer 和 HiveMind。Avalon 從沒怎么流行，盡管它很強(qiáng)大而且有很長(zhǎng)的歷史。Avalon相當(dāng)?shù)闹睾蛷?fù)雜，并且看起來比新的IoC解決方案更具侵入性。 PicoContainer是一個(gè)輕量級(jí)而且更強(qiáng)調(diào)通過構(gòu)造函數(shù)表達(dá)依賴性而不是JavaBean 屬性。與Spring不同，它的設(shè)計(jì)允許每個(gè)類型一個(gè)對(duì)象的定義(可能是因?yàn)樗芙^任何Java代碼外的元數(shù)據(jù)導(dǎo)致的局限性)。在Spring， PicoContainer 和其他 IoC frameworks之間做比較，可參看文章Spring網(wǎng)站上的"The Spring Framework - A Lightweight Container"位于http: //www.springframework.org/docs/lightweight_container.html。這個(gè)頁(yè)面里面包含了 PicoContainer站點(diǎn)的鏈接。

Spring BeanFactories 是非常輕量級(jí)的。用戶已經(jīng)成功地將他們應(yīng)用在applets和單獨(dú)的Swing應(yīng)用中。(它們也很好地工作在EJB容器中。) 沒有特殊的部署步驟和察覺得到的啟動(dòng)時(shí)間。這個(gè)能力表明一個(gè)容器在應(yīng)用的任何層面幾乎立即可以發(fā)揮非常大的價(jià)值。

Spring BeanFactory 概念貫穿于Spring始終，而且是Spring如此內(nèi)在一致的關(guān)鍵原因。在IoC容器中，Spring也是唯一的，它使用IoC作為基礎(chǔ)概念貫穿于整個(gè)功能豐富的框架。

對(duì)應(yīng)用開發(fā)人員，最重要的是，一個(gè)或多個(gè)BeanFactory提供了一個(gè)定義明確的業(yè)務(wù)對(duì)象層。這類似于local session bean層，但比它更簡(jiǎn)單。與EJBs不同，在這個(gè)層中的對(duì)象可能是相關(guān)的，并且他們的關(guān)系被擁有它們的factory管理。有一個(gè)定義明確的業(yè)務(wù)對(duì)象層對(duì)于成功的體系結(jié)構(gòu)是非常重要的。

Spring ApplicationContext 是BeanFactory的子接口，為下列東西提供支持：

XmlBeanFactory 例子

Spring 用戶通常在XML的“bean定義”文件中配置他們的應(yīng)用。Spring的XML bean定義文檔的根是<beans> 元素。該元素包含一個(gè)或多個(gè) <bean>定義。我們一般給每個(gè)bean定義的指定類和屬性。我們還必須指定ID作為標(biāo)識(shí)，這將成為在代碼中使用該bean的名字。

讓我們來看一個(gè)簡(jiǎn)單的例子，它配置了三個(gè)應(yīng)用程序?qū)ο螅g的關(guān)系在J2EE應(yīng)用中常常能夠看到：

在下面的例子中，我們使用一個(gè)來自Jakarta Commons DBCP項(xiàng)目的BasicDataSource。這個(gè)class（和其他許多已有的class一樣）可以簡(jiǎn)單地被應(yīng)用在Spring bean factory中，只要它提供了JavaBean格式的配置。需要在shutdown時(shí)被調(diào)用的Close方法可通過Spring的"destroy- method"屬性被注冊(cè)，以避免BasicDataSource需要實(shí)現(xiàn)任何Spring 的接口。

代碼:

<beans>

<bean id="myDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
<property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property>
<property name="username"><value>root</value></property>
</bean>

BasicDataSource中我們感興趣的所有屬性都是String類型的，因此我們用<value>元素來指定他們的值。如果必要的話，Spring使用標(biāo)準(zhǔn)的 JavaBean屬性編輯器機(jī)制來把String轉(zhuǎn)換為其他的類型。

現(xiàn)在，我們定義DAO，它有一個(gè)對(duì)DataSource的bean引用。Bean間關(guān)系通過<ref>元素來指定：

代碼:

<bean id="exampleDataAccessObject"
class="example.ExampleDataAccessObject">
<property name="dataSource"><ref bean="myDataSource"/></property>
</bean>

The business object has a reference to the DAO, and an int property (exampleParam):
<bean id="exampleBusinessObject"
class="example.ExampleBusinessObject">
<property name="dataAccessObject"><ref bean="exampleDataAccessObject"/></property>
<property name="exampleParam"><value>10</value></property>
</bean>

</beans>

對(duì)象間的關(guān)系一般在配置中明確地設(shè)置，象這個(gè)例子一樣。我們認(rèn)為這樣做是件好事情。然而Spring還提供了我們稱做"autowire"的支持，一個(gè)la PicoContainer，其中它指出了bean間的依賴關(guān)系。這樣做的局限性——PicoContainer也是如此——是如果有一個(gè)特殊類型的多個(gè) Bean，要確定那個(gè)類型所依賴的是哪個(gè)實(shí)例是不可能。好的方面是，不滿足的依賴可以在factory初始化后被捕獲到。（Spring 也為顯式的配置提供了一種可選的依賴檢查，它可以完成這個(gè)目的）

在上面的例子中，如果我們不想顯式的編寫他們的關(guān)系，可使用如下的autowire特性：

代碼:

使用這個(gè)特性，Spring會(huì)找出exampleBusinessObject的dataSource屬性應(yīng)該被設(shè)置為在當(dāng)前BeanFactory中找到的DataSource實(shí)現(xiàn)。在當(dāng)前的BeanFactory中，如果所需要類型的bean不存在或多于一個(gè)，將產(chǎn)生一個(gè)錯(cuò)誤。我們依然要設(shè)置 exampleParam屬性，因?yàn)樗皇且粋€(gè)引用。

Autowire支持和依賴檢查剛剛加入CVS并將在Spring 1.0 M2(到10/20,2003)中提供。本文中所討論的所有其他特性都包含在當(dāng)前1.0 M1版本中。

把管理從Java代碼中移出來比硬編碼有很大的好處，因?yàn)檫@樣可以只改變XML文件而無需改變一行Java代碼。例如，我們可以簡(jiǎn)單地改變 myDataSource的bean定義引用不同的bean class以使用別的連接池，或者一個(gè)用于測(cè)試的數(shù)據(jù)源。 XML節(jié)變成另一種，我們可以用Spring的JNDI location FactoryBean從應(yīng)用服務(wù)器獲取一個(gè)數(shù)據(jù)源。

現(xiàn)在讓我們來看看例子中業(yè)務(wù)對(duì)象的java 代碼。注意下面列出的代碼中沒有對(duì)Spring的依賴。不像EJB容器，Spring BeanFactory不具有侵入性：在應(yīng)用對(duì)象里面你通常不需要對(duì)Spring的存在硬編碼。

代碼:

public class ExampleBusinessObject implements MyBusinessObject {

private ExampleDataAccessObject dao;
private int exampleParam;

public void setDataAccessObject(ExampleDataAccessObject dao) {
   this.dao = dao;
}

public void setExampleParam(int exampleParam) {
   this.exampleParam = exampleParam;
}

public void myBusinessMethod() {
   // do stuff using dao
}
}

注意那些property setter，它們對(duì)應(yīng)于bean定義文檔中的XML引用。這些將在對(duì)象被使用之前由Spring調(diào)用。

這些應(yīng)用程序的bean不需要依賴于Spring：他們不需要實(shí)現(xiàn)任何Spring的接口或者繼承Spring的類。他們只需要遵守JavaBeans的命名習(xí)慣。在Spring 應(yīng)用環(huán)境之外重用它們是非常簡(jiǎn)單的，例如，在一個(gè)測(cè)試環(huán)境中。只需要用它們的缺省構(gòu)造函數(shù)實(shí)例化它們，并且通過調(diào)用setDataSource()和 setExampleParam()手工設(shè)置它的屬性。如果你想以一行代碼支持程序化的創(chuàng)建，只要你有一個(gè)無參數(shù)的構(gòu)造器，你就可以自由定義其他需要多個(gè)屬性的構(gòu)造函數(shù)。

注意在業(yè)務(wù)接口中沒有聲明將會(huì)一起使用的JavaBean屬性。他們是一個(gè)實(shí)現(xiàn)細(xì)節(jié)。我們可以“插入”帶有不同bean屬性的不同的實(shí)現(xiàn)類而不影響連接著的對(duì)象或者調(diào)用的代碼。

當(dāng)然，Spring XML bean factories 有更多的功能沒有在這里描述，但是，應(yīng)當(dāng)讓你對(duì)基本使用有了一些感覺。以及，簡(jiǎn)單的屬性，有JavaBean屬性編輯器的屬性，Spring可以自動(dòng)處理 lists，maps和java.util.Properties。

Bean factories 和application contexts 通常和J2EE server定義的一個(gè)范圍相關(guān)聯(lián)，例如：

這些J2EE規(guī)范提供的hook通常避免了使用Singleton來創(chuàng)造一個(gè)bean factory。

然而，如果我們?cè)敢獾脑捒梢杂么a創(chuàng)建一個(gè)BeanFactory，雖然是沒有什么意義的。例如，我們?cè)谝韵氯写a中可以創(chuàng)建bean factory并且得到一個(gè)業(yè)務(wù)對(duì)象的引用：

代碼:

InputStream is = getClass().getResourceAsStream("myFile.xml");
XmlBeanFactory bf = new XmlBeanFactory(is);
MyBusinessObject mbo = (MyBusinessObject) bf.getBean("exampleBusinessObject");

這段代碼將能工作在一個(gè)應(yīng)用服務(wù)器之外：甚至不依賴J2EE，因?yàn)镾pring 的IoC容器是純java的。

JDBC 抽象和數(shù)據(jù)存儲(chǔ)異常層次

數(shù)據(jù)訪問是Spring 的另一個(gè)閃光點(diǎn)。

JDBC 提供了還算不錯(cuò)的數(shù)據(jù)庫(kù)抽象，但是需要用痛苦的API。這些問題包括：

Spring用兩種方法解決這些問題：

Spring提供兩層JDBC API。第一個(gè)時(shí)，在org.springframework.jdbc.core包中，使用回調(diào)機(jī)制移動(dòng)控制權(quán)——并且因而把錯(cuò)誤處理和連接獲取和釋放 ——從程序的代碼移到了框架之中。這是一種不同的Inversion of Control，但是和用于配置管理的幾乎有同等重要的意義。

Spring使用類似的回調(diào)機(jī)制關(guān)注其他包含特殊獲取和清理資源步驟的API，例如JDO（獲取和釋放是由PersistenceManager完成的），事務(wù)管理（使用JTA）和JNDI。Spring中完成這些回調(diào)的類被稱作template。

例如，Spring的JdbcTemplate對(duì)象能夠用于執(zhí)行SQL查詢并且在如下的列表中保存結(jié)果：

代碼:

JdbcTemplate template = new JdbcTemplate(dataSource);
final List names = new LinkedList();
template.query("SELECT USER.NAME FROM USER",
new RowCallbackHandler() {
   public void processRow(ResultSet rs) throws SQLException {
      names.add(rs.getString(1));
   }
});

注意回調(diào)中的程序代碼是能夠自由拋出SQLException的：Spring將會(huì)捕捉到這些異常并且用自己的類層次重新拋出。程序的開發(fā)者可以選擇哪個(gè)異常，如果有的話，被捕捉然后處理。

JdbcTemplate提供許多支持不同情景包括prepared statements和批量更新的方法。Spring的JDBC抽象有比起標(biāo)準(zhǔn)JDBC來說性能損失非常小，甚至在當(dāng)應(yīng)用中需要的結(jié)果集數(shù)量很大的時(shí)候。

在org.springframework.jdbc.object 包中是對(duì)JDBC的更高層次的抽象。這是建立在核心的JDBC回調(diào)功能基礎(chǔ)紙上的，但是提供了一個(gè)能夠?qū)DBMS操作——無論是查詢，更新或者是存儲(chǔ)過程——使用Java對(duì)象來建模的API。這個(gè)API部分是受到JDO查詢API的影響，我發(fā)現(xiàn)它直觀而且非常有用。

一個(gè)用于返回User對(duì)象的查詢對(duì)象可能是這樣的：

代碼:

class UserQuery extends MappingSqlQuery {

public UserQuery(DataSource datasource) {
   super(datasource, "SELECT * FROM PUB_USER_ADDRESS WHERE USER_ID = ?");
   declareParameter(new SqlParameter(Types.NUMERIC));
   compile();
}

// Map a result set row to a Java object
protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
   User user = new User();
   user.setId(rs.getLong("USER_ID"));
   user.setForename(rs.getString("FORENAME"));
   return user;
}

public User findUser(long id) {
   // Use superclass convenience method to provide strong typing
   return (User) findObject(id);
}
}

這個(gè)類可以在下面用上：

代碼:

User user = userQuery.findUser(25);

這樣的對(duì)象經(jīng)常可以用作DAO的inner class。它們是線程安全的，除非子類作了一些超出常規(guī)的事情。

在org.springframework.jdbc.object 包中另一個(gè)重要的類是StoredProcedure類。Spring讓存儲(chǔ)過程通過帶有一個(gè)業(yè)務(wù)方法的Java類進(jìn)行代理。如果你喜歡的話，你可以定義一個(gè)存儲(chǔ)過程實(shí)現(xiàn)的接口，意味著你能夠把你的程序代碼從對(duì)存儲(chǔ)過程的依賴中完全解脫出來。

Spring數(shù)據(jù)訪問異常層次是基于unchecked（運(yùn)行時(shí)）exception的。在幾個(gè)工程中使用了Spring之后，我越來越確信這個(gè)決定是正確的。

數(shù)據(jù)訪問異常一般是不可恢復(fù)的。例如，如果我們不能鏈接到數(shù)據(jù)庫(kù)，某個(gè)業(yè)務(wù)對(duì)象很有可能就不能完成要解決的問題了。一個(gè)可能的異常是optimistic locking violation，但是不是所有的程序使用optimistic locking。強(qiáng)制編寫捕捉其無法有效處理的致命的異常通常是不好的。讓它們傳播到上層的handler，比如servlet或者EJB 容器通常更加合適。所有的Spring對(duì)象訪問異常都是DataAccessException的子類，因而如果我們確實(shí)選擇了捕捉所有的Spring數(shù)據(jù)訪問異常，我們可以很容易做到這點(diǎn)。

注意如果我們確實(shí)需要從unchecked數(shù)據(jù)訪問異常中恢復(fù)，我們?nèi)匀豢梢赃@么做。我們可以編寫代碼僅僅處理可恢復(fù)的情況。例如，如果我們認(rèn)為只有optimistic locking violation是可恢復(fù)的，我們可以在Spring的DAO中如下這么寫：

代碼:

try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}

如果Spring的數(shù)據(jù)訪問異常是checked的，我們需要編寫如下的代碼。注意我們還是可以選擇這么寫：

代碼:

try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}
catch (DataAccessException ex) {
// Fatal; just rethrow it
}

第一個(gè)例子的潛在缺陷是——編譯器不能強(qiáng)制處理可能的可恢復(fù)的異常——這對(duì)于第二個(gè)也是如此。因?yàn)槲覀儽粡?qiáng)制捕捉base exception（DataAccessException），編譯器不會(huì)強(qiáng)制對(duì)子類（OptimisticLockingFailureException）的檢查。因而編譯器可能強(qiáng)制我們編寫處理不可恢復(fù)問題的代碼，但是對(duì)于強(qiáng)制我們處理可恢復(fù)的問題并未有任何幫助。

Spring對(duì)于數(shù)據(jù)訪問異常的unchecked使用和許多——可能是大多數(shù)——成功的持久化框架是一致的。（確實(shí)，它部分是受到JDO的影響。）JDBC是少數(shù)幾個(gè)使用checked exception的數(shù)據(jù)訪問API之一。例如TopLink和JDO大量使用unchecked exception。Gavin King現(xiàn)在相信Hibernate也應(yīng)該選擇使用unchecked exception。

Spring的JDBC能夠用以下辦法幫助你：

在實(shí)踐中，我們發(fā)現(xiàn)所有這些都確實(shí)有助于生產(chǎn)力的提高和更少的bug。我過去常常厭惡編寫JDBC代碼；現(xiàn)在我發(fā)現(xiàn)我能夠集中精力于我要執(zhí)行的SQL，而不是煩雜的JDBC資源管理。

如果需要的話Spring的JDBC抽象可以獨(dú)立使用——不強(qiáng)迫你把它們用作Spring的一部分。

O/R mapping 集成

當(dāng)然你經(jīng)常需要使用O/R mapping，而不是使用關(guān)系數(shù)據(jù)訪問。你總體的應(yīng)用程序框架也必須支持它。因而提供了對(duì)Hibernate 2.x和JDO的集成支持。它的數(shù)據(jù)訪問架構(gòu)使得它能和任何底層的數(shù)據(jù)訪問技術(shù)集成。Spring和Hibernate集成得尤其好。

為什么你要使用Hibernate加Spring，而不是直接使用Hibernate？

事務(wù)管理
抽象出一個(gè)數(shù)據(jù)訪問的API是不夠的；我們還需要考慮事務(wù)管理。JTA是顯而易見的選擇，但是它是一個(gè)直接用起來很笨重的API，因而許多J2EE開發(fā)者感到EJB CMT是對(duì)于事務(wù)管理唯一合理的選擇。

Spring提供了它自己對(duì)事務(wù)管理的抽象。Spring提供了這些：

Spring的事務(wù)抽象式唯一的，它不綁定到JTA或者任何其他事務(wù)管理技術(shù)。Spring使用事務(wù)策略的概念把程序代碼和底層的事務(wù)架構(gòu)（例如JDBC）解藕。

為什么你要關(guān)心這些？JTA不是所有事務(wù)管理的最好答案嗎？如果你正在編寫僅僅使用一個(gè)數(shù)據(jù)庫(kù)的程序，你不需要JTA的復(fù)雜度。你不關(guān)心XA事務(wù)或者兩階段提交。你甚至不需要提供這些東西的高端應(yīng)用服務(wù)器。但是另一方面，你不會(huì)希望在需要和多個(gè)數(shù)據(jù)源打交道的時(shí)候重寫你的代碼。

假定你決定通過直接使用JDBC或者Hibernate的事務(wù)以避免JTA帶來的額外負(fù)擔(dān)。一旦你需要處理多個(gè)數(shù)據(jù)源，你必須剝開所有的事務(wù)管理代碼并且使用 JTA事務(wù)來替代。這不是非常有吸引力的并且導(dǎo)致大部分J2EE程序員，包括我自己，推薦只使用全局JTA事務(wù)。然而使用Spring事務(wù)抽象，你只需要重新配置Spring讓它使用JTA，而不是JDBC或者Hibernate的事務(wù)策略，就一切OK了。這是一個(gè)配置上的改變，而不是代碼的改動(dòng)。因而， Spring使得你能夠自由縮放應(yīng)用。

AOP

最近在應(yīng)用AOP來解決企業(yè)關(guān)注點(diǎn)方面大家有了很大的興趣，例如事務(wù)管理，這些都是EJB所要解決的。

Spring 的AOP支持的首要目標(biāo)是要給POJOs提供J2EE服務(wù)。這類似于JBoss 4的目標(biāo)，Spring AOP由它能夠在應(yīng)用服務(wù)器之間移植的優(yōu)勢(shì)，因而沒有綁死在廠商身上的風(fēng)險(xiǎn)。它既可以在web或者EJB容器中使用，也能夠在WebLogic， Tomcat，JBoss，Resin，Jetty，Orion和許多其他應(yīng)用服務(wù)器和web容器上使用。

Spring AOP支持method interception。所支持關(guān)鍵的AOP概念包括：

Spring既支持有狀態(tài)（一個(gè)advised對(duì)象一個(gè)實(shí)例）也支持無狀態(tài)的interceptors（所有advice使用一個(gè)實(shí)例）。

Spring 不支持field interception。這是一個(gè)經(jīng)過深思熟慮的設(shè)計(jì)決定。我總是感覺field interception違反了封裝。我比較傾向于把AOP作為補(bǔ)全物，而不是與OOP沖突的東西。如果在5年或者10年后，我們?cè)贏OP學(xué)習(xí)曲線上走得更遠(yuǎn)了并且覺得應(yīng)該在程序設(shè)計(jì)的桌面上給AOP一個(gè)位置，我不會(huì)驚訝的。（然而在那個(gè)時(shí)候基于語(yǔ)言的解決方案例如AspectJ可能比它們今天看來更加具有吸引力。）

Spring使用動(dòng)態(tài)代理實(shí)現(xiàn)AOP（其中存在一個(gè)接口）或者在運(yùn)行時(shí)使用CGLIB生成字節(jié)碼（這使得能夠代理類）。兩種方法都能夠在任何應(yīng)用服務(wù)器中使用。

Spring是第一個(gè)實(shí)現(xiàn)AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。這些是定義在不同AOP框架中能夠互操作interceptors的嘗試。

在TheServerSide 和其他地方有一個(gè)正在進(jìn)行但是不是那么引人注目的爭(zhēng)論，就是這種interception是不是“true AOP”。我倒不怎么在意它叫什么；僅僅需要知道它是否在實(shí)踐中有用就好了。我也樂于稱它為“declarative middleware”（聲明式中間件）。把Spring AOP認(rèn)做簡(jiǎn)單，輕量級(jí)的無狀態(tài)beans的替代物，這樣就不需要monolithic EJB容器了，而這些僅僅是讓你能夠構(gòu)建有你需要的服務(wù)的容器。我不推薦advising任何一個(gè)POJO，對(duì)local SLSBs的類比有助于你理解推薦的粒度。（然而，與EJB不同的是，在恰當(dāng)?shù)巧僖姷那闆r下，你可以自由地把Spring的AOP應(yīng)用到粒度更好的對(duì)象上。）

因?yàn)镾pring在實(shí)例上advises 對(duì)象，而不是在class loader層面上，使用有不同advice的同一個(gè)類的多個(gè)實(shí)例是可能的，或者與advised實(shí)例一道使用unadvised 實(shí)例。

可能Spring AOP最常見的應(yīng)用是聲明式事務(wù)管理。這是基于前面描述的TansactionTemplate抽象上的，并且可以給任何POJO提供聲明式事務(wù)管理。取決于事務(wù)策略，底層的機(jī)制可以是JTA，JDBC，Hibernate或者任何其他提供事務(wù)管理的API。

Spring的聲明式事務(wù)管理類似于EJB CMT，在以下方面有些不同：

當(dāng)然還可以使用Spring AOP實(shí)現(xiàn)程序特有的aspects。取決于你對(duì)AOP概念的接受程度，決定你是否選擇這么做，而不是Spring的能力，但是它確實(shí)非常有用。我們所見過的成功例子包括：

程序自定的aspects能夠成為消除需要許多函數(shù)的樣板代碼的有利武器。

Spring AOP透明地與Spring BeanFactory概念集成。包含一個(gè)來自Spring BeanFactory對(duì)象地代碼不需要知道它是還是不是advised。和任何對(duì)象一樣，契約實(shí)在接口和對(duì)象實(shí)現(xiàn)中定義的。

下面的XML片斷展示了如何定義一個(gè)AOP代理：

代碼:

<bean id="myTest"
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyInterfaces">
   <value>org.springframework.beans.ITestBean</value>
</property>
<property name="interceptorNames">
   <list>
      <value>txInterceptor</value>
      <value>target</value>
   </list>
</property>
</bean>

注意bean類的定義總是AOP框架的ProxyFactoryBean，雖然bean的類型在引用中使用或者由BeanFactory的getBean ()方法返回時(shí)依賴的是代理接口。（多個(gè)代理方法是被支持的。）ProxyFactoryBean的“interceptorNames”屬性需要一個(gè)字符串列表。（因?yàn)槿绻硎且粋€(gè)“prototype”而不是singleton，有狀態(tài)interceptors可能需要?jiǎng)?chuàng)建新的實(shí)例，所以必須使用 Bean的名字而不是bean的引用。）列表中的名字可以是interceptor或者pointcuts（interceptors和有關(guān)它們合適被使用的信息）。列表中的“target”值自動(dòng)創(chuàng)建一個(gè)“invoker interceptor”封裝target對(duì)象。實(shí)現(xiàn)代理接口的是在factory中的bean的名字。這個(gè)例子中的myTest可以和其他bean factory中的bean一樣使用。例如，其他對(duì)象可以使用<ref>元素引用它而且這些引用是由Spring IoC設(shè)置的。

還可以不用BeanFactory，編程構(gòu)建AOP代理，雖然這個(gè)很少用得上：

代碼:

TestBean target = new TestBean();
DebugInterceptor di = new DebugInterceptor();
MyInterceptor mi = new MyInterceptor();
ProxyFactory factory = new ProxyFactory(target);
factory.addInterceptor(0, di);
factory.addInterceptor(1, mi);
// An "invoker interceptor" is automatically added to wrap the target
ITestBean tb = (ITestBean) factory.getProxy();

我們相信最好把程序裝配從Java代碼中移出來，而AOP也不例外。

Spring在它的AOP能力方面的直接競(jìng)爭(zhēng)者是Jon Tirsen的Nanning Aspects（http://nanning.codehaus.org）。

我覺得AOP作為EJB的替代無提供企業(yè)服務(wù)這個(gè)用法方面的進(jìn)步是重要的。隨著時(shí)間，這將成為Spring很重要的關(guān)注點(diǎn)。
MVC web 框架

Spring包括一個(gè)強(qiáng)大而且高度可配置的MVC web 框架。

Spring的MVC model類似于Struts。在多線程服務(wù)對(duì)象這點(diǎn)上，Spring的Controller類似于Struts Action，只有一個(gè)實(shí)例處理所有客戶的請(qǐng)求。然而，我們相信Spring的MVC比起Struts有很多優(yōu)點(diǎn)，例如：

如在Struts 1.1中所見的，你可以有和你在Spring MVC 應(yīng)用程序中所需要的一樣多的dispatcher servlets。

下面的例子展示了一個(gè)簡(jiǎn)單的Spring Controller如何能夠訪問定義在應(yīng)用程序context中的業(yè)務(wù)對(duì)象。這個(gè)controller在它的handleRequest()方法中執(zhí)行了Google搜索：

代碼:

public class GoogleSearchController
   implements Controller {

private IGoogleSearchPort google;

private String googleKey;

public void setGoogle(IGoogleSearchPort google) {
   this.google = google;
}

public void setGoogleKey(String googleKey) {
   this.googleKey = googleKey;
}

public ModelAndView handleRequest(
         HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
   String query = request.getParameter("query");
   GoogleSearchResult result =
      // Google property definitions omitted...

      // Use google business object
      google.doGoogleSearch(this.googleKey, query,
         start, maxResults, filter, restrict,
         safeSearch, lr, ie, oe);

   return new ModelAndView("googleResults", "result", result);
}
}

這段代碼使用的prototype中，IGoogleSearchPort是一個(gè)GLUE web services代理，由Spring FActoryBean返回。然而，Spring把controller從底層web service庫(kù)中分離出來。接口可以使用普通的Java對(duì)象，test stub，mock對(duì)象或者如下面要討論的EJB代理實(shí)現(xiàn)。這個(gè)contorller不包括資源查找；除了支持它的web交互的必要代碼之外沒有別的什么了。

Spring還提供了數(shù)據(jù)綁定，forms，wizards和更復(fù)雜的工作流的支持。

對(duì)Spring MVC 框架的優(yōu)秀簡(jiǎn)介是Thomas Risberg的Spring MVC 教程（http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step- by-step.html）。還可以參見“Web MVC with the Spring Framework”（http://www.springframework.org/docs/web_mvc.html）。

如果你樂于使用你鐘情的MVC框架，Spring的分層架構(gòu)使得你能夠使用Spring的其他部分而不用MVC層。我們有使用Spring做中間層管理和數(shù)據(jù)訪問，但是在web層使用Struts，WebWork或者Tapestry的用戶。
實(shí)現(xiàn)EJB

如果你選擇使用EJB，Spring能在EJB實(shí)現(xiàn)和客戶端訪問EJB兩方面都提供很大的好處。

對(duì)業(yè)務(wù)邏輯進(jìn)行重構(gòu)，把它從EJB facades中取出到POJO已經(jīng)得到了廣泛的認(rèn)同。（不講別的，這使得業(yè)務(wù)邏輯更容易單元測(cè)試，因?yàn)镋JB嚴(yán)重依賴于容器而難于分離測(cè)試。） Spring為session bean和message driver bean提供了方便的超類，使得通過自動(dòng)載入基于包含在EJB Jar文件中的XML文檔BeanFactory讓這變得很容易。

這意味著stateless session EJB可以這么獲得和使用所需對(duì)象：

代碼:

import org.springframework.ejb.support.AbstractStatelessSessionBean;

public class MyEJB extends AbstractStatelessSessionBean
      implements MyBusinessInterface {
private MyPOJO myPOJO;

protected void onEjbCreate() {
   this.myPOJO = getBeanFactory().getBean("myPOJO");
}

public void myBusinessMethod() {
   this.myPOJO.invokeMethod();
}
}

假定MyPOJO是一個(gè)接口，它的實(shí)現(xiàn)類——以及任何它需要的配置，注入基本的屬性和更多的合作者——在XML bean factory 定義中隱藏。

我們通過在ejb-jar.xmldeployment descriptor中名為ejb/BeanFactoryPath的環(huán)境變量定義告訴Spring去哪兒裝載XML文檔。如下：

代碼:

<session>
<ejb-name>myComponent</ejb-name>
<local-home>com.test.ejb.myEjbBeanLocalHome</local-home>
<local>com.mycom.MyComponentLocal</local>
<ejb-class>com.mycom.MyComponentEJB</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>

<env-entry>
   <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
   <env-entry-type>java.lang.String</env-entry-type>
   <env-entry-value>/myComponent-ejb-beans.xml</env-entry-value></env-entry>
</env-entry>
</session>

myComponent-ejb-beans.xml 文件將會(huì)從classpath裝載：在本例中，是EJB Jar文件的根目錄。每個(gè)EJB都能指定自己的XML文檔，因而這個(gè)機(jī)制能在每個(gè)EJB Jar文件中使用多次。

Spring 的超類實(shí)現(xiàn)了EJB中諸如setSessionContext()和ejbCreate()的生命周期管理的方法，讓應(yīng)用程序開發(fā)者只需選擇是否實(shí)現(xiàn)Spring的onEjbCreate()方法。
使用EJB

Spring還讓實(shí)現(xiàn)EJB變得更加容易。許多EJB程序使用Service Locator和Business Delegate模式。這些比在客戶代碼中遍布JNDI查找強(qiáng)多了，但是它們常見的實(shí)現(xiàn)方式有顯著的缺點(diǎn)，例如：

基于這些和其他原因，傳統(tǒng)的EJB訪問，如在Sun Adventure Builder和OTN J2EE Virtual Shopping Mall中展示的那樣，會(huì)降低生產(chǎn)率并且?guī)盹@著的復(fù)雜度。

Spring 通過引入codeless business delegate前進(jìn)了一步。有了Spring，你不再需要再編寫另一個(gè)Service Locator，另一個(gè)JNDI查找，或者在硬編碼的Business Delegate中重復(fù)代碼，除非你肯定這增加了價(jià)值。

例如，假定我們有使用local EJB的web controller。我們將遵循最佳實(shí)踐，使用EJB Business Methods Interface模式，EJB的local interface extend非EJB專有的業(yè)務(wù)方法接口。（這么做的主要的一個(gè)原因是確保在本地接口和bean實(shí)現(xiàn)類中方法簽名的自動(dòng)同步。）讓我們調(diào)用這個(gè)業(yè)務(wù)方法接口MyComponent。當(dāng)然我們還需要實(shí)現(xiàn)local home接口并且提供實(shí)現(xiàn)SessionBean和MyComponent業(yè)務(wù)方法的bean的實(shí)現(xiàn)類。

用了Spring EJB 訪問，我們把我們的web層controller和EJB實(shí)現(xiàn)掛接上所需要進(jìn)行的Java編碼僅僅是在我們的controller中暴露一個(gè)類型MyComponent的setter方法。這將如下保存作為實(shí)例變量的引用：

代碼:

private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
this.myComponent = myComponent;
}

我們隨后在任何業(yè)務(wù)方法中使用這個(gè)實(shí)例變量。

Spring 自動(dòng)完稱剩下的工作，通過像這樣的XML bean定義。LocalStatelessSessionProxyFactoryBean是一個(gè)可以用于任何EJB的通用factory bean。它創(chuàng)建的對(duì)象能夠自動(dòng)被Spring轉(zhuǎn)型為MyComponent類型。

代碼:

<bean id="myComponent"
class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">

<property name="jndiName"><value>myComponent</value></property>
<property name="businessInterface"><value>com.mycom.MyComponent</value></property>
</bean>

<bean id="myController"
class = "com.mycom.myController"
>
<property name="myComponent"><ref bean="myComponent"/></property>
</bean>

在幕后有許多魔法般的事情發(fā)生，Spring AOP framework的殷勤，雖然不強(qiáng)迫你使用AOP的概念享受這些結(jié)果。“myComponent”bean定義為EJB創(chuàng)建一個(gè)代理，它實(shí)現(xiàn)了業(yè)務(wù)方法的接口。EJB local home在啟動(dòng)的時(shí)候被緩存，因而只需要一次JNDI查找。每次EJB被調(diào)用的時(shí)候，代理調(diào)用local EJB中的create()方法并且調(diào)用EJB中對(duì)應(yīng)的業(yè)務(wù)方法。

myController bean定義為這個(gè)代理設(shè)置controller類的myController屬性。

這個(gè)EJB訪問機(jī)制極大簡(jiǎn)化了應(yīng)用程序的代碼：

在實(shí)際程序中的性能測(cè)試和經(jīng)驗(yàn)標(biāo)明這種方法（包括對(duì)目標(biāo)EJB的反射調(diào)用）的性能影響是很小的，在典型的應(yīng)用中檢測(cè)不出。記住無論如何我們都不希望使用fine-grained的EJB調(diào)用，因?yàn)闀?huì)有有關(guān)應(yīng)用服務(wù)器上的EJB的底層架構(gòu)方面的代價(jià)。

我們可以把相同方法應(yīng)用于遠(yuǎn)程EJB，通過類似 org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean factory bean的方法。然而我們無法隱藏遠(yuǎn)程EJB的業(yè)務(wù)方法接口中的RemoteException。

測(cè)試

如你可能已經(jīng)注意到的，我和其他Spring開發(fā)這是全面單元測(cè)試重要性的堅(jiān)定支持者。我們相信框架被徹底單元測(cè)試過的是非常重要的，而且我們框架設(shè)計(jì)的主要目標(biāo)是讓建立在框架之上的程序易于單元測(cè)試。

Spring 自身有一個(gè)極好的單元測(cè)試包。我們的1.0 M1的單元測(cè)試覆蓋率是75%，而且我們希望在1.0 RC1的時(shí)候能夠達(dá)到80%的單元測(cè)試覆蓋率。我們發(fā)現(xiàn)在這個(gè)項(xiàng)目中測(cè)試優(yōu)先的開發(fā)帶來的好處是實(shí)實(shí)在在的。例如，它使得作為國(guó)際化分布式開發(fā)團(tuán)隊(duì)的工作極端有效率，而且用戶評(píng)論CVS snapshots趨向于穩(wěn)定和使用安全。

因?yàn)橐韵吕碛桑覀兿嘈庞肧pring構(gòu)建的應(yīng)用程序是非常易于測(cè)試的：

在容器外可以設(shè)置Spring bean factory的能力提供了對(duì)開發(fā)過程有趣的可選項(xiàng)。在幾個(gè)使用Spring的web應(yīng)用中，工作是從定義業(yè)務(wù)接口和在web容器外集成測(cè)試開始的。在業(yè)務(wù)功能已經(jīng)足夠完整之后，web接口不過是添加在其上的薄薄一層。

誰(shuí)在使用Spring

雖然相對(duì)來說Spring還是一個(gè)新的項(xiàng)目，但是我們已經(jīng)有了一個(gè)令人印象深刻并且不斷增長(zhǎng)的用戶群。它們已經(jīng)有許多產(chǎn)品使用著Spring。用戶包括一個(gè)主要的全球投資銀行（做大型項(xiàng)目的），一些知名的網(wǎng)絡(luò)公司，幾個(gè)web開發(fā)顧問機(jī)構(gòu)，衛(wèi)生保健公司，以及學(xué)院機(jī)構(gòu)。

許多用戶完整地使用Spring，但是一些只單獨(dú)使用一些組件。例如，大量用戶使用我們地JDBC或者其他數(shù)據(jù)訪問功能。
Roadmap

在今年晚些時(shí)候我們主要要做的是讓Spring發(fā)布release 1.0。然而，我們還有一些更長(zhǎng)遠(yuǎn)的目標(biāo)。

為1.0 final規(guī)劃地主要改進(jìn)式源代碼級(jí)地元數(shù)據(jù)支持，它主要用于（但不局限于）AOP框架。這將使得C#風(fēng)格的attribute驅(qū)動(dòng)的事務(wù)管理，并且讓聲明式企業(yè)服務(wù)在典型應(yīng)用情況下非常容易配置。Attribute支持將會(huì)在Spring的1.0 final release支持中加入，并且設(shè)計(jì)的是在發(fā)布的那個(gè)時(shí)候能與JSR-175集成。

1.0之后，一些可能的改進(jìn)地方包括：

作為一個(gè)敏捷項(xiàng)目，我們主要是受到用戶需求的驅(qū)動(dòng)。因而我們不會(huì)開發(fā)沒有一個(gè)用戶需要的特性，并且我們會(huì)仔細(xì)傾聽來自用戶群的聲音。

總結(jié)

Spring是一個(gè)解決了許多在J2EE開發(fā)中常見的問題的強(qiáng)大框架。

Spring 提供了管理業(yè)務(wù)對(duì)象的一致方法并且鼓勵(lì)了注入對(duì)接口編程而不是對(duì)類編程的良好習(xí)慣。Spring的架構(gòu)基礎(chǔ)是基于使用JavaBean屬性的 Inversion of Control容器。然而，這僅僅是完整圖景中的一部分：Spring在使用IoC容器作為構(gòu)建完關(guān)注所有架構(gòu)層的完整解決方案方面是獨(dú)一無二的。

Spring提供了唯一的數(shù)據(jù)訪問抽象，包括簡(jiǎn)單和有效率的JDBC框架，極大的改進(jìn)了效率并且減少了可能的錯(cuò)誤。Spring的數(shù)據(jù)訪問架構(gòu)還集成了Hibernate和其他O/R mapping解決方案。

Spring還提供了唯一的事務(wù)管理抽象，它能夠在各種底層事務(wù)管理技術(shù)，例如JTA或者JDBC紙上提供一個(gè)一致的編程模型。

Spring提供了一個(gè)用標(biāo)準(zhǔn)Java語(yǔ)言編寫的AOP框架，它給POJOs提供了聲明式的事務(wù)管理和其他企業(yè)事務(wù)——如果你需要——還能實(shí)現(xiàn)你自己的aspects。這個(gè)框架足夠強(qiáng)大，使得應(yīng)用程序能夠拋開EJB的復(fù)雜性，同時(shí)享受著和傳統(tǒng)EJB相關(guān)的關(guān)鍵服務(wù)。

Spring還提供了可以和總體的IoC容器集成的強(qiáng)大而靈活的MVC web框架。

更多信息

參見以下資源獲得關(guān)于Spring的更多信息：

我們正在盡我們可能去改進(jìn)Spring的文檔和示例。我們還為在信件和郵件列表中極好的回復(fù)率自豪。我們希望你能快速融入我們的社區(qū)！

關(guān)于作者

Rod Johnson 作為Java開發(fā)者和架構(gòu)師已經(jīng)有了7年的經(jīng)驗(yàn)了并且在J2EE平臺(tái)出現(xiàn)之初就在其上進(jìn)行開發(fā)了。他是《Expert One-on-One J2EE Design and Development》(Wrox，2002)的作者并且貢獻(xiàn)了其他好幾本關(guān)于J2EE的書。他當(dāng)前正在為Wiley撰寫另外一本有關(guān)J2EE架構(gòu)的書。Rod在兩個(gè)Java標(biāo)準(zhǔn)委員會(huì)服務(wù)并且經(jīng)常師大會(huì)發(fā)言人。現(xiàn)在他在UK做一個(gè)咨詢顧問。

posted on 2007-08-19 18:15 前方的路閱讀(222) 評(píng)論(0) 編輯收藏所屬分類: 軟件架構(gòu)

常用鏈接

留言簿(7)

隨筆分類(85)

隨筆檔案(72)

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關(guān)文章: 你是個(gè)軟件架構(gòu)師嗎？（轉(zhuǎn)） osgi介紹 OpenCore中的核心概念：服務(wù)(Service)與插件(Plugin)的定義大型Web 2.0企業(yè)技術(shù)架構(gòu)集插件系統(tǒng)框架分析使用 WebSphere 集群環(huán)境構(gòu)建強(qiáng)大而靈活的 J2EE 應(yīng)用程序在WAS6.0 ND中實(shí)現(xiàn)集群 Spring框架與AOP思想的研究與應(yīng)用 J2EE框架設(shè)計(jì)技術(shù)分析負(fù)載均衡技術(shù)全攻略