1. MySQL(http://www.mysql.com)mm.mysql-2.0.2-bin.jar ;
Class.forName( "org.gjt.mm.mysql.Driver" );
cn = DriverManager.getConnection( "jdbc:mysql://MyDbComputerNameOrIP:3306/myDatabaseName", sUsr, sPwd );
2. PostgreSQL(http://www.de.postgresql.org)pgjdbc2.jar ;
Class.forName( "org.postgresql.Driver" );
cn = DriverManager.getConnection( "jdbc:postgresql://MyDbComputerNameOrIP/myDatabaseName", sUsr, sPwd );
3. Oracle(http://www.oracle.com/ip/deploy/database/oracle9i/)classes12.zip ;
Class.forName( "oracle.jdbc.driver.OracleDriver" );
cn = DriverManager.getConnection( "jdbc:oracle:thin:@MyDbComputerNameOrIP:1521:ORCL", sUsr, sPwd );
4. Sybase(http://jtds.sourceforge.net)jconn2.jar ;
Class.forName( "com.sybase.jdbc2.jdbc.SybDriver" );
cn = DriverManager.getConnection( "jdbc:sybase:Tds:MyDbComputerNameOrIP:2638", sUsr, sPwd );
// (Default-Username/Password: "dba"/"sql")
5. Microsoft SQLServer(http://jtds.sourceforge.net) ;
Class.forName( "net.sourceforge.jtds.jdbc.Driver" );
cn = DriverManager.getConnection( "jdbc:jtds:sqlserver://MyDbComputerNameOrIP:1433/master", sUsr, sPwd );
6. Microsoft SQLServer(http://www.microsoft.com) ;
Class.forName( "com.microsoft.jdbc.sqlserver.SQLServerDriver" );
cn = DriverManager.getConnection( "jdbc:microsoft:sqlserver://MyDbComputerNameOrIP:1433;databaseName=master", sUsr, sPwd );
7. ODBC
Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" );
Connection cn = DriverManager.getConnection( "jdbc:odbc:" + sDsn, sUsr, sPwd );
8.DB2
Class.forName("Com.ibm.db2.jdbc.net.DB2Driver");
String url="jdbc:db2://192.9.200.108:6789/SAMPLE"
cn = DriverManager.getConnection( url, sUsr, sPwd );
| 什么是 Java 技术？ |  |
||||||
|
|||||||
| Java 技术为什么重要？ | |
|||||||
|
||||||||
| 什么是 Java 组件技术？ | |
|||||||
|
||||||||
| Java 技术如何与 Web 服务联系起来？ | |
|||||||
|
||||||||
| 如何提高 Java 编程技能？ | |
|||||||
|
||||||||
| Java 编程人员可以使用哪些 IBM 工具和产品？ | |
|
|
||
1、java数据库操作基本流程
2、几个常用的重要技巧：
可滚动、更新的记录集
批量更新
事务处理
java数据库操作基本流程：取得数据库连接 – 执行sql语句 – 处理执行结果 – 释放数据库连接
1、取得数据库连接
1）用DriverManager取数据库连接
例子：
| String className,url,uid,pwd; className = "oracle.jdbc.driver.OracleDriver"; url = "jdbc:oracle:thin:@127.0.0.1:1521:orasvr; uid = "system"; pwd = "manager"; Class.forName(className); Connection cn = DriverManager.getConnection(url,uid,pwd); |
2）用jndi(java的命名和目录服务)方式
例子
| String jndi = "jdbc/db"; Context ctx = (Context) new InitialContext().lookup("java:comp/env"); DataSource ds = (DataSource) ctx.lookup(jndi); Connection cn = ds.getConnection(); |
多用于jsp中
2、执行sql语句
1）用Statement来执行sql语句
| String sql; Statement sm = cn.createStatement(); sm.executeQuery(sql); // 执行数据查询语句（select） sm.executeUpdate(sql); // 执行数据更新语句（delete、update、insert、drop等）statement.close(); |
2）用PreparedStatement来执行sql语句
| String sql; sql = "insert into user (id,name) values (?,?)"; PreparedStatement ps = cn.prepareStatement(sql); ps.setInt(1,xxx); ps.setString(2,xxx); … ResultSet rs = ps.executeQuery(); // 查询 int c = ps.executeUpdate(); // 更新 |
3、处理执行结果
查询语句，返回记录集ResultSet。
更新语句，返回数字，表示该更新影响的记录数。
ResultSet的方法：
1、next()，将游标往后移动一行，如果成功返回true；否则返回false。
2、getInt("id")或getSting("name")，返回当前游标下某个字段的值。
3、释放连接。
| cn.close(); |
一般，先关闭ResultSet，然后关闭Statement（或者PreparedStatement）；最后关闭Connection
可滚动、更新的记录集
1、创建可滚动、更新的Statement
| Statement sm = cn.createStatement(ResultSet.TYPE_SCROLL_ENSITIVE,ResultSet.CONCUR_READ_ONLY); |
该Statement取得的ResultSet就是可滚动的
2、创建PreparedStatement时指定参数
| PreparedStatemet ps = cn.prepareStatement(sql,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY); ResultSet.absolute(9000); |
批量更新
1、Statement
| Statement sm = cn.createStatement(); sm.addBatch(sql1); sm.addBatch(sql2); … sm.executeBatch() |
一个Statement对象，可以执行多个sql语句以后，批量更新。这多个语句可以是delete、update、insert等或兼有
2、PreparedStatement
| PreparedStatement ps = cn.preparedStatement(sql); { ps.setXXX(1,xxx); … ps.addBatch(); } ps.executeBatch(); |
一个PreparedStatement，可以把一个sql语句，变换参数多次执行，一次更新。
事务的处理
1、关闭Connection的自动提交
| cn.setAutoCommit(false); |
2、执行一系列sql语句
要点：执行每一个新的sql语句前，上一次执行sql语句的Statement（或者PreparedStatemet）必须先close
| Statement sm ; sm = cn.createStatement(insert into user…); sm.executeUpdate(); sm.close(); sm = cn.createStatement("insert into corp…); sm.executeUpdate(); sm.close(); |
3、提交
| cn.commit(); |
4、如果发生异常，那么回滚
| cn.rollback(); |
关于Spring Framework，今年夏天你可能已经听见很多的议论。在本文中,我将试图解释Spring能完成什么，和我怎么会认为它能帮助你开发J2EE应用程序。
又来一个framework？
你可能正在想“不过是另外一个的framework”。当已经有许多开放源代码(和专有) J2EE framework时，为什么你还要耐下心子读这篇文章或去下载Spring Framework？
我相信Spring是独特的，有几个原因：
它关注的领域是其他许多流行的Framework未曾关注的。Spring要提供的是一种管理你的业务对象的方法。
Spring既是全面的又是模块化的。Spring有分层的体系结构，这意味着你能选择仅仅使用它任何一个独立的部分，而它的架构又是内部一致。因此你能从你的学习中，得到最大的价值。例如，你可能选择仅仅使用Spring来简单化JDBC的使用，或用来管理所有的业务对象。
它的设计从一开始就是要帮助你编写易于测试的代码。Spring是使用测试驱动开发的工程的理想框架。
Spring不会给你的工程添加对其他的框架依赖。Spring也许称得上是个一站式解决方案，提供了一个典型应用所需要的大部分基础架构。它还涉及到了其他framework没有考虑到的内容。
尽管它仅仅是一个从2003年2月才开始的开源项目，但Spring有深厚的历史根基。这个开源工程是起源自我在2002年晚些时候出版的《Expert One-on-One J2EE设计与开发》书中的基础性代码。这本书展示了Spring背后的基础性架构思想。然而，对这个基础架构的概念可以追溯到2000年的早些时候,并且反映了我为一系列商业工程开发基础结构的成功经验。
2003年1月，Spring已经落户于SourceForge上了。现在有10个开发人员，其中6个是高度投入的积极分子。
Spring架构上的好处
在我们进入细节之前，让我们来看看Spring能够给工程带来的种种好处：
Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。如果你仅仅使用了Struts或其他为J2EE的 API特制的framework，Spring致力于解决剩下的问题。
Spring能消除在许多工程中常见的对Singleton的过多使用。根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。
通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码？有了Spring，你仅仅需要看看类的JavaBean属性。Inversion of Control的使用（在下面讨论）帮助完成了这种简化。
通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。
Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。
使用Spring构建的应用程序易于单元测试。
Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。
Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。
Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/R mapping产品（如Hibernate）。
Spring确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。
Spring做了些什么？
Spring提供许多功能，在此我将依次快速地展示其各个主要方面。
任务描述
首先,让我们明确Spring范围。尽管Spring覆盖了许多方面，但我们对它应该涉什么，什么不应该涉及有清楚的认识。
Spring的主要目的是使J2EE易用和促进好编程习惯。
Spring不重新轮子。因此，你发现在Spring中没有logging，没有连接池，没有分布式事务调度。所有这些东西均有开源项目提供(例如我们用于处理所有日志输出的Commons Logging以及Commons DBCP)，或由你的应用程序服务器提供了。出于同样的的原因，我们没有提供O/R mapping层。对于这个问题已经有了像Hibernate和JDO这样的优秀解决方案。
Spring的目标就是让已有的技术更加易用。例如，尽管我们没有底层事务协调处理，但我们提供了一个抽象层覆盖了JTA或任何其他的事务策略。
Spring没有直接和其他的开源项目竞争，除非我们感到我们能提供新的一些东西。例如，象许多开发人员一样，我们从来没有对Struts感到高兴过，并且觉得到在MVC web framework中还有改进的余地。在某些领域，例如轻量级的IoC容器和AOP框架，Spring确实有直接的竞争，但是在这些领域还没有已经较为流行的解决方案。(Spring在这些领域是开路先锋。)
Spring也得益于内在的一致性。所有的开发者都在唱同样的的赞歌，基础想法依然与Expert One-on-One J2EE设计与开发中提出的差不多。 并且我们已经能够在多个领域中使用一些中心的概念，例如Inversion of Control。
Spring在应用服务器之间是可移植的。当然保证可移植性总是一种挑战，但是我们避免使用任何平台特有或非标准的东西，并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的应用服务器上的用户。
Inversion of Control 容器
Spring设计的核心是 org.springframework.beans 包, 它是为与JavaBeans一起工作而设计的。 这个包一般不直接被用户使用，而是作为许多其他功能的基础。
下一个层面高一些的抽象是"Bean Factory"。一个Spring bean factory 是一个通用的Factory，它使对象能够按名称获取，并且能管理对象之间的关系。
Bean factories 支持两种模式的对象：
Singleton：在此模式中，有一个具有特定名称的共享对象实例，它在查找时被获取。这是默认的，而且是最为经常使用的。它对于无状态对象是一种理想的模式。
Prototype：在此模式中，每次获取将创建一个独立的对象。例如，这可以被用于让用户拥有他们自己的对象。
由于 org.springframwork.beans.factory.BeanFactory是一个简单的接口，它能被大量底层存储方法实现。你能够方便地实现你自己的BeanFactory，尽管很少用户需要这么做。最为常用的BeanFactory定义是：
XmlBeanFactory： 可解析简单直观的定义类和命名对象属性的XML结构。 我们提供了一个DTD来使编写更容易。
ListableBeanFactoryImpl：提供了解析存放在属性文件中的bean定义的能力，并且可通过编程创建BeanFactories。
每个bean定义可能是一个POJO（通过类名和JavaBean初始属性定义），或是一个FactoryBean。FactoryBean接口添加了一个间接层。通常，这用于创建使用AOP或其他方法的代理对象：例如，添加声明性事务管理的代理。（这在概念上和EJB的interception相似，但实现得更简单。）
BeanFactories能在一个层次结构中选择性地参与，继承ancestor（祖先）的定义。这使得在整个应用中公共配置的共享成为可能，虽然个别资源，如controller servlets，还拥有他们自己的独立的对象集合。
这种使用JavaBeans的动机在《Expert One-on-One J2EE Design and Development》的第四章中有描述，在TheServerSide网站上的有免费的PDF版本(http://www.theserverside.com/resources/article.jsp?l=RodJohnsonInterview)。
通过BeanFactory概念，Spring成为一个Inversion of Control的容器。(我不怎么喜欢container这个词，因为它使人联想到重量级容器，如EJB容器。Spring的BeanFactory是一个可通过一行代码创建的容器，并且不需要特殊的部署步骤。)
Inversion of Control背后的概念经常表述为Hollywood原则的：“Don’t call me， I’ll call you。” IoC将控制创建的职责搬进了框架中，并把它从应用代码脱离开来。涉及到配置的地方，意思是说在传统的容器体系结构中，如EJB，一个组件可以调用容器并问“我需要它给我做工作的对象X在哪里?”；使用IoC容器则只需指出组件需要X对象，在运行时容器会提供给它。容器是通过查看方法的参数表（例如JavaBean的属性）做到的，也可能根据配置数据如XML。
IoC有几个重要的好处，例如：
因为组件不需要在运行时间寻找合作者，所以他们可以更简单的编写和维护。在Spring版的IoC里，组件通过暴露JavaBean的setter方法表达他们依赖的其他组件。这相当于EJB通过JNDI来查找，EJB查找需要开发人员编写代码。
同样原因，应用代码更容易测试。JavaBean属性是简单的，属于Java核心的，并且是容易测试的：仅编写一个自包含的Junit测试方法用来创建对象和设置相关属性即可。
一个好的IoC实现保留了强类型。如果你需要使用一个通用的factory来寻找合作者，你必须通过类型转换将返回结果转变为想要的类型。这不是一个大不了的问题，但是不雅观。使用IoC，你在你的代码中表达了强类型依赖，框架将负责类型转换。这意味着在框架配置应用时，类型不匹配将导致错误；在你的代码中，你无需担心类型转换异常。
大部分业务对象不依赖于IoC容器的APIs。这使得很容易使用遗留下来的代码，且很容易的使用对象无论在容器内或不在容器内。例如，Spring用户经常配置Jakarta Commons DBCP数据源为一个Spring bean：不需要些任何定制代码去做这件事。我们说一个IoC容器不是侵入性的：使用它并不会使你的代码依赖于它的APIs。任何JavaBean在Spring bean factory中都能成为一个组件。
最后应该强调的是，IoC 不同于传统的容器的体系结构，如EJB，应用代码最小程度地依靠于容器。这意味着你的业务对象可以潜在的被运行在不同的IoC 框架上——或者在任何框架之外——不需要任何代码的改动。
以我和其他Spring用户的经验来说，再怎么强调IoC给应用程序代码带来的好处也不为过。
IoC不是一个新概念，但是它在J2EE团体里面刚刚到达黄金时间。 有一些可供选择的IoC 容器: 例如 Apache Avalon, PicoContainer 和 HiveMind。Avalon 从没怎么流行，尽管它很强大而且有很长的历史。Avalon相当的重和复杂，并且看起来比新的IoC解决方案更具侵入性。 PicoContainer是一个轻量级而且更强调通过构造函数表达依赖性而不是JavaBean 属性。 与Spring不同，它的设计允许每个类型一个对象的定义(可能是因为它拒绝任何Java代码外的元数据导致的局限性)。在Spring， PicoContainer 和其他 IoC frameworks之间做比较，可参看文章Spring网站上的"The Spring Framework – A Lightweight Container"位于http://www.springframework.org/docs/lightweight_container.html。这个页面里面包含了PicoContainer站点的链接 。
Spring BeanFactories 是非常轻量级的。用户已经成功地将他们应用在applets和单独的Swing应用中。(它们也很好地工作在EJB容器中。) 没有特殊的部署步骤和察觉得到的启动时间。这个能力表明一个容器在应用的任何层面几乎立即可以发挥非常大的价值。
Spring BeanFactory 概念贯穿于Spring始终， 而且是Spring如此内在一致的关键原因。在IoC容器中，Spring也是唯一的，它使用IoC作为基础概念贯穿于整个功能丰富的框架。
对应用开发人员，最重要的是，一个或多个BeanFactory提供了一个定义明确的业务对象层。这类似于local session bean层，但比它更简单。与EJBs不同，在这个层中的对象可能是相关的，并且他们的关系被拥有它们的factory管理。有一个定义明确的业务对象层对于成功的体系结构是非常重要的。
Spring ApplicationContext 是BeanFactory的子接口，为下列东西提供支持：
信息查找，支持着国际化
事件机制，允许发布应用对象以及可选的注册以接收到事件
可移植的文件和资源访问
XmlBeanFactory 例子
Spring用户通常在XML的“bean定义”文件中配置他们的应用。Spring的XML bean定义文档的根是<beans> 元素。该元素包含一个或多个 <bean>定义。我们一般给每个bean定义的指定类和属性。我们还必须指定ID作为标识，这将成为在代码中使用该bean的名字。
让我们来看一个简单的例子，它配置了三个应用程序对象，之间的关系在J2EE应用中常常能够看到：
J2EE DataSource
使用DataSource的DAO
在处理过程中使用DAO的业务对象
在下面的例子中，我们使用一个来自Jakarta Commons DBCP项目的BasicDataSource。这个class（和其他许多已有的class一样）可以简单地被应用在Spring bean factory中，只要它提供了JavaBean格式的配置。需要在shutdown时被调用的Close方法可通过Spring的"destroy-method"属性被注册，以避免BasicDataSource需要实现任何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使用标准的 JavaBean属性编辑器机制来把String转换为其他的类型。
现在，我们定义DAO，它有一个对DataSource的bean引用。Bean间关系通过<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> |
对象间的关系一般在配置中明确地设置，象这个例子一样。我们认为这样做是件好事情。然而Spring还提供了我们称做"autowire"的支持， 一个la PicoContainer，其中它指出了bean间的依赖关系。这样做的局限性——PicoContainer也是如此——是如果有一个特殊类型的多个Bean，要确定那个类型所依赖的是哪个实例是不可能。好的方面是，不满足的依赖可以在factory初始化后被捕获到。（Spring 也为显式的配置提供了一种可选的依赖检查，它可以完成这个目的）
在上面的例子中，如果我们不想显式的编写他们的关系，可使用如下的autowire特性：
| 代码: |
| <bean id="exampleBusinessObject" class="example.ExampleBusinessObject" autowire="byType"> <property name="exampleParam"><value>10</value></property> </bean> |
使用这个特性，Spring会找出exampleBusinessObject的dataSource属性应该被设置为在当前BeanFactory中找到的DataSource实现。在当前的BeanFactory中，如果所需要类型的bean不存在或多于一个，将产生一个错误。我们依然要设置exampleParam属性，因为它不是一个引用。
Autowire支持和依赖检查刚刚加入CVS并将在Spring 1.0 M2(到10/20,2003)中提供。本文中所讨论的所有其他特性都包含在当前1.0 M1版本中。
把管理从Java代码中移出来比硬编码有很大的好处，因为这样可以只改变XML文件而无需改变一行Java代码。例如，我们可以简单地改变myDataSource的bean定义引用不同的bean class以使用别的连接池，或者一个用于测试的数据源。 XML节变成另一种，我们可以用Spring的JNDI location FactoryBean从应用服务器获取一个数据源。
现在让我们来看看例子中业务对象的java 代码。注意下面列出的代码中没有对Spring的依赖。不像EJB容器，Spring BeanFactory不具有侵入性：在应用对象里面你通常不需要对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，它们对应于bean定义文档中的XML引用。这些将在对象被使用之前由Spring调用。
这些应用程序的bean不需要依赖于Spring：他们不需要实现任何Spring的接口或者继承Spring的类。他们只需要遵守JavaBeans的命名习惯。在Spring 应用环境之外重用它们是非常简单的，例如，在一个测试环境中。只需要用它们的缺省构造函数实例化它们，并且通过调用setDataSource()和setExampleParam()手工设置它的属性。如果你想以一行代码支持程序化的创建，只要你有一个无参数的构造器，你就可以自由定义其他需要多个属性的构造函数。
注意在业务接口中没有声明将会一起使用的JavaBean属性。 他们是一个实现细节。我们可以“插入”带有不同bean属性的不同的实现类而不影响连接着的对象或者调用的代码。
当然，Spring XML bean factories 有更多的功能没有在这里描述，但是，应当让你对基本使用有了一些感觉。以及，简单的属性，有JavaBean属性编辑器的属性，Spring可以自动处理lists，maps和java.util.Properties。
Bean factories 和application contexts 通常和J2EE server定义的一个范围相关联，例如：
Servlet context.：在spring 的MVC 框架里, 每一个包含common objects的web 应用都定义有一个应用程序的context。Spring提供了通过listener或者servlet实例化这样的context的能力而不需要依赖于Spring 的MVC 框架，因而它也可以用于Struts，WebWork 或者其他的web框架之中。
A Servlet：在Spring MVC 框架里每一个servlet控制器都有它自己的应用程序context，派生于根（全应用程序范围的）应用程序context。在Struts或者其他MVC框架中实现这些也很容意。
EJB：Spring 为EJB提供方便的超类，它们简化了EJB的创建并且提供了一个从EJB Jar 文件中的XML文档载入的BeanFactory。
这些J2EE规范提供的hook通常避免了使用Singleton来创造一个bean factory。
然而，如果我们愿意的话可以用代码创建一个BeanFactory，虽然是没有什么意义的。例如，我们在以下三行代码中可以创建bean factory并且得到一个业务对象的引用：
| 代码: |
| InputStream is = getClass().getResourceAsStream("myFile.xml"); XmlBeanFactory bf = new XmlBeanFactory(is); MyBusinessObject mbo = (MyBusinessObject) bf.getBean("exampleBusinessObject"); |
JDBC 抽象和数据存储异常层次
这段代码将能工作在一个应用服务器之外：甚至不依赖J2EE，因为Spring 的IoC容器是纯java的。
数据访问是Spring 的另一个闪光点。
JDBC 提供了还算不错的数据库抽象，但是需要用痛苦的API。这些问题包括：
需要冗长的错误处理代码来确保ResultSets，Statements以及（最重要的）Connections在使用后关闭。这意味着对JDBC的正确使用可以快速地导致大量的代码量。它还是一个常见的错误来源。Connection leak可以在有负载的情况下快速宕掉应用程序。
SQLException相对来说不能说明任何问题。JDBC不提供异常的层次，而是用抛出SQLException来响应所有的错误。找出到底哪里出错了——例如，问题是死锁还是无效的SQL？——要去检查SQLState或错误代码。这意味着这些值在数据库之间是变化的。
Spring用两种方法解决这些问题： 提供API，把冗长乏味和容易出错的异常处理从程序代码移到框架之中。框架处理所有的异常处理；程序代码能够集中精力于编写恰当的SQL和提取结果上。
为你本要处理SQLException程序代码提供有意义的异常层次。当Spring第一次从数据源取得一个连接时，它检查元数据以确定数据库。它使用这些信息把SQLException映射为自己从org.springframework.dao.DataAccessException派生下来的类层次中正确的异常。因而你的代码可以与有意义的异常打交道，并且不需要为私有的SQLState或者错误码担心。Spring的数据访问异常不是JDBC特有的，因而你的DAO并不一定会因为它们可能抛出的异常而绑死在JDBC上。
Spring提供两层JDBC API。第一个时，在org.springframework.jdbc.core包中，使用回调机制移动控制权——并且因而把错误处理和连接获取和释放——从程序的代码移到了框架之中。这是一种不同的Inversion of Control，但是和用于配置管理的几乎有同等重要的意义。
Spring使用类似的回调机制关注其他包含特殊获取和清理资源步骤的API，例如JDO（获取和释放是由PersistenceManager完成的），事务管理（使用JTA）和JNDI。Spring中完成这些回调的类被称作template。
例如，Spring的JdbcTemplate对象能够用于执行SQL查询并且在如下的列表中保存结果：
代码:
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));
}
});
注意回调中的程序代码是能够自由抛出SQLException的：Spring将会捕捉到这些异常并且用自己的类层次重新抛出。程序的开发者可以选择哪个异常，如果有的话，被捕捉然后处理。
JdbcTemplate提供许多支持不同情景包括prepared statements和批量更新的方法。Spring的JDBC抽象有比起标准JDBC来说性能损失非常小，甚至在当应用中需要的结果集数量很大的时候。
在org.springframework.jdbc.object包中是对JDBC的更高层次的抽象。这是建立在核心的JDBC回调功能基础纸上的，但是提供了一个能够对RDBMS操作——无论是查询，更新或者是存储过程——使用Java对象来建模的API。这个API部分是受到JDO查询API的影响，我发现它直观而且非常有用。
一个用于返回User对象的查询对象可能是这样的：
代码:
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);
}
}
这个类可以在下面用上：
代码:
User user = userQuery.findUser(25);
这样的对象经常可以用作DAO的inner class。它们是线程安全的，除非子类作了一些超出常规的事情。
在org.springframework.jdbc.object包中另一个重要的类是StoredProcedure类。Spring让存储过程通过带有一个业务方法的Java类进行代理。如果你喜欢的话，你可以定义一个存储过程实现的接口，意味着你能够把你的程序代码从对存储过程的依赖中完全解脱出来。
Spring数据访问异常层次是基于unchecked（运行时）exception的。在几个工程中使用了Spring之后，我越来越确信这个决定是正确的。
数据访问异常一般是不可恢复的。例如，如果我们不能链接到数据库，某个业务对象很有可能就不能完成要解决的问题了。一个可能的异常是optimistic locking violation，但是不是所有的程序使用optimistic locking。强制编写捕捉其无法有效处理的致命的异常通常是不好的。让它们传播到上层的handler，比如servlet或者EJB 容器通常更加合适。所有的Spring对象访问异常都是DataAccessException的子类，因而如果我们确实选择了捕捉所有的Spring数据访问异常，我们可以很容易做到这点。
注意如果我们确实需要从unchecked数据访问异常中恢复，我们仍然可以这么做。我们可以编写代码仅仅处理可恢复的情况。例如，如果我们认为只有optimistic locking violation是可恢复的，我们可以在Spring的DAO中如下这么写：
代码:
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I’m interested in this
}
如果Spring的数据访问异常是checked的，我们需要编写如下的代码。注意我们还是可以选择这么写：
代码:
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I’m interested in this
}
catch (DataAccessException ex) {
// Fatal; just rethrow it
}
第一个例子的潜在缺陷是——编译器不能强制处理可能的可恢复的异常——这对于第二个也是如此。因为我们被强制捕捉base exception（DataAccessException），编译器不会强制对子类（OptimisticLockingFailureException）的检查。因而编译器可能强制我们编写处理不可恢复问题的代码，但是对于强制我们处理可恢复的问题并未有任何帮助。
Spring对于数据访问异常的unchecked使用和许多——可能是大多数——成功的持久化框架是一致的。（确实，它部分是受到JDO的影响。）JDBC是少数几个使用checked exception的数据访问API之一。例如TopLink和JDO大量使用unchecked exception。Gavin King现在相信Hibernate也应该选择使用unchecked exception。
Spring的JDBC能够用以下办法帮助你：
你决不需要在使用JDBC时再编写finally block。
总的来说你需要编写的代码更少了
你再也不需要挖掘你的RDBMS的文档以找出它为错误的列名称返回的某个罕见的错误代码。你的程序不再依赖于RDBMS特有的错误处理代码。
无论使用的是什么持久化技术，你都会发现容易实现DAO模式，让业务代码无需依赖于任何特定的数据访问API。
在实践中，我们发现所有这些都确实有助于生产力的提高和更少的bug。我过去常常厌恶编写JDBC代码；现在我发现我能够集中精力于我要执行的SQL，而不是烦杂的JDBC资源管理。
如果需要的话Spring的JDBC抽象可以独立使用——不强迫你把它们用作Spring的一部分。
O/R mapping 集成
当然你经常需要使用O/R mapping，而不是使用关系数据访问。你总体的应用程序框架也必须支持它。因而提供了对Hibernate 2.x和JDO的集成支持。它的数据访问架构使得它能和任何底层的数据访问技术集成。Spring和Hibernate集成得尤其好。
为什么你要使用Hibernate加Spring，而不是直接使用Hibernate？
Session 管理 Spring提供有效率的，简单的以并且是安全的处理Hibernate Session。使用Hibernate的相关代码为了效率和恰当的事务处理一般需要使用相同的Hibernate “Session”对象。Spring让它容易透明地创建和绑定Session到当前的线程，要么使用声明式，AOP的method interceptor方法，要么在Java代码层面使用显式的，“template”包装类。因而Spring解决了在Hibernate论坛上经常出现的用法问题。
资源管理 Spring的应用程序context能够处理Hiberante SessionFactories的位置和配置，JDBC数据源和其他相关资源。这使得这些值易于管理和改变。
集成的事务管理 Spring让你能够把你的Hibernate代码包装起来，要么使用声明式，AOP风格的method interceptor，要么在Java代码层面显式使用“template”包装类。在两种做法中，事务语义都为你处理了，并且在异常时也做好了恰当的事务处理（回滚，等）。如下面讨论的，你还获得了能够使用和替换不同transaction manager，而不会让你相关Hibernate代码受到影响的能力。额外的，JDBC相关的代码能够完全事务性的和Hibernate代码集成。这对于处理没有在Hibernate实现的功能很有用。
如上描述的异常包装 Spring能够包装Hibernate异常，把它们从私有的，checked异常转换为一套抽象的运行时异常。这使得你能够仅仅在恰当的层面处理大部分不可恢复的持久化异常，而不影响样板catch/throw，和异常声明。你仍然能够在任何你需要的地方捕捉和处理异常。记住JDBC异常（包括DB特有的方言）也被转换到相同的层次中，意味着你能在一致的编程模型中对JDBC执行相同的操作。
为了避免和厂商绑定 Hibernate是强大的，灵活的，开放源代码并且免费，但是它仍然使用私有的API。给出了一些选择，使用标准或者抽象API实现主要的程序功能通常是你想要的，当你需要因为功能，性能，或者其他考虑要转换到使用其他实现时。
让测试变简单 Spring的Inversion of Control方法使得改变Hibernate的session factories，数据源，transaction manager的实现和位置很容易，如果需要的话还能改变mapper object的实现。这使得更加容易分离和测试持久化相关的代码。
事务管理
抽象出一个数据访问的API是不够的；我们还需要考虑事务管理。JTA是显而易见的选择，但是它是一个直接用起来很笨重的API，因而许多J2EE开发者感到EJB CMT是对于事务管理唯一合理的选择。
Spring提供了它自己对事务管理的抽象。Spring提供了这些：
通过类似于JdbcTemplate的回调模板编程管理事务，比起直接使用JTA要容易多了
类似于EJB CMT的声明式事务管理，但是不需要EJB容器
Spring的事务抽象式唯一的，它不绑定到JTA或者任何其他事务管理技术。Spring使用事务策略的概念把程序代码和底层的事务架构（例如JDBC）解藕。
为什么你要关心这些？JTA不是所有事务管理的最好答案吗？如果你正在编写仅仅使用一个数据库的程序，你不需要JTA的复杂度。你不关心XA事务或者两阶段提交。你甚至不需要提供这些东西的高端应用服务器。但是另一方面，你不会希望在需要和多个数据源打交道的时候重写你的代码。
假定你决定通过直接使用JDBC或者Hibernate的事务以避免JTA带来的额外负担。一旦你需要处理多个数据源，你必须剥开所有的事务管理代码并且使用JTA事务来替代。这不是非常有吸引力的并且导致大部分J2EE程序员，包括我自己，推荐只使用全局JTA事务。然而使用Spring事务抽象，你只需要重新配置Spring让它使用JTA，而不是JDBC或者Hibernate的事务策略，就一切OK了。这是一个配置上的改变，而不是代码的改动。因而，Spring使得你能够自由缩放应用。
AOP
最近在应用AOP来解决企业关注点方面大家有了很大的兴趣，例如事务管理，这些都是EJB所要解决的。
Spring的AOP支持的首要目标是要给POJOs提供J2EE服务。这类似于JBoss 4的目标，Spring AOP由它能够在应用服务器之间移植的优势，因而没有绑死在厂商身上的风险。它既可以在web或者EJB容器中使用，也能够在WebLogic，Tomcat，JBoss，Resin，Jetty，Orion和许多其他应用服务器和web容器上使用。
Spring AOP支持method interception。所支持关键的AOP概念包括：
Interception：自定义行为能够在对接口和类的调用之前和之后插入。这类似于AspectJ术语中类似的“around advice”。
Introduction：指定advice会导致对象实现额外的接口。这混乱了继承。
静态和动态的pointcuts：在interception发生的程序执行处指定points。静态pointcuts concern函数签名；动态pointcuts也可以在point被求值的地方考虑函数的参数。Pointcuts独立interceptors单独定义，使得标准interceptor可以应用于不同应用程序和代码上下文。
Spring既支持有状态（一个advised对象一个实例）也支持无状态的interceptors（所有advice使用一个实例）。
Spring不支持field interception。这是一个经过深思熟虑的设计决定。我总是感觉field interception违反了封装。我比较倾向于把AOP作为补全物，而不是与OOP冲突的东西。如果在5年或者10年后，我们在AOP学习曲线上走得更远了并且觉得应该在程序设计的桌面上给AOP一个位置，我不会惊讶的。（然而在那个时候基于语言的解决方案例如AspectJ可能比它们今天看来更加具有吸引力。）
Spring使用动态代理实现AOP（其中存在一个接口）或者在运行时使用CGLIB生成字节码（这使得能够代理类）。两种方法都能够在任何应用服务器中使用。
Spring是第一个实现AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。这些是定义在不同AOP框架中能够互操作interceptors的尝试。
在TheServerSide和其他地方有一个正在进行但是不是那么引人注目的争论，就是这种interception是不是“true AOP”。我倒不怎么在意它叫什么；仅仅需要知道它是否在实践中有用就好了。我也乐于称它为“declarative middleware”（声明式中间件）。把Spring AOP认做简单，轻量级的无状态beans的替代物，这样就不需要monolithic EJB容器了，而这些仅仅是让你能够构建有你需要的服务的容器。我不推荐advising任何一个POJO，对local SLSBs的类比有助于你理解推荐的粒度。（然而，与EJB不同的是，在恰当但是少见的情况下，你可以自由地把Spring的AOP应用到粒度更好的对象上。）
因为Spring在实例上advises 对象，而不是在class loader层面上，使用有不同advice的同一个类的多个实例是可能的，或者与advised实例一道使用unadvised 实例。
可能Spring AOP最常见的应用是声明式事务管理。这是基于前面描述的TansactionTemplate抽象上的，并且可以给任何POJO提供声明式事务管理。取决于事务策略，底层的机制可以是JTA，JDBC，Hibernate或者任何其他提供事务管理的API。
Spring的声明式事务管理类似于EJB CMT，在以下方面有些不同：
事务管理能够应用于任何POJO。我们推荐业务对象实现接口，但是这只是一个好的编程习惯的问题，而不是由框架强制的。
通过使用Spring的事务API能够在事务性POJO中实现编程回调。我们为此提供静态的方法，使用ThreadLoacal变量，因而你不需要传播诸如EJBContext这样的context对象来确保回滚。
你可以声明式地定义“回滚规则”。EJB不会在未捕捉程序异常的时候自动回滚（仅仅在unchecked exceptions和其他Throwables的时候），应用程序开发者经常需要在任何异常发生时回滚。Spring事务管理让你能够声明式地指定什么异常什么子类能够导致自动回滚。缺省的行为和EJB是一致的，但是你能够在checked和unchecked异常时自动回滚。这个在最少化自编程回调代码方面有很大好处，而回调依赖于Spring的事务API（因为EJB的编程回调时在EJBContext中完成的）。
事务管理不绑定于JTA。如前面解释过的，Spring的事务管理能够在不同事务策略中使用。
当然还可以使用Spring AOP实现程序特有的aspects。取决于你对AOP概念的接受程度，决定你是否选择这么做，而不是Spring的能力，但是它确实非常有用。我们所见过的成功例子包括：
自定义的security interception，当安全检查的复杂度超出了J2EE安全架构的能力的时候
在开发中使用的调试和profiling aspects
发送email通知管理员用户不寻常的举动的Interceptors
程序自定的aspects能够成为消除需要许多函数的样板代码的有利武器。
Spring AOP透明地与Sp 需要冗长的错误处理代码来确保ResultSets，Statements以及（最重要的）Connections在使用后关闭。这意味着对JDBC的正确使用可以快速地导致大量的代码量。它还是一个常见的错误来源。Connection leak可以在有负载的情况下快速宕掉应用程序。
SQLException相对来说不能说明任何问题。JDBC不提供异常的层次，而是用抛出SQLException来响应所有的错误。找出到底哪里出错了——例如，问题是死锁还是无效的SQL？——要去检查SQLState或错误代码。这意味着这些值在数据库之间是变化的。
Spring用两种方法解决这些问题： 提供API，把冗长乏味和容易出错的异常处理从程序代码移到框架之中。框架处理所有的异常处理；程序代码能够集中精力于编写恰当的SQL和提取结果上。
为你本要处理SQLException程序代码提供有意义的异常层次。当Spring第一次从数据源取得一个连接时，它检查元数据以确定数据库。它使用这些信息把SQLException映射为自己从org.springframework.dao.DataAccessException派生下来的类层次中正确的异常。因而你的代码可以与有意义的异常打交道，并且不需要为私有的SQLState或者错误码担心。Spring的数据访问异常不是JDBC特有的，因而你的DAO并不一定会因为它们可能抛出的异常而绑死在JDBC上。
Spring提供两层JDBC API。第一个时，在org.springframework.jdbc.core包中，使用回调机制移动控制权——并且因而把错误处理和连接获取和释放——从程序的代码移到了框架之中。这是一种不同的Inversion of Control，但是和用于配置管理的几乎有同等重要的意义。
Spring使用类似的回调机制关注其他包含特殊获取和清理资源步骤的API，例如JDO（获取和释放是由PersistenceManager完成的），事务管理（使用JTA）和JNDI。Spring中完成这些回调的类被称作template。
例如，Spring的JdbcTemplate对象能够用于执行SQL查询并且在如下的列表中保存结果：
代码:
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));
}
});
注意回调中的程序代码是能够自由抛出SQLException的：Spring将会捕捉到这些异常并且用自己的类层次重新抛出。程序的开发者可以选择哪个异常，如果有的话，被捕捉然后处理。
JdbcTemplate提供许多支持不同情景包括prepared statements和批量更新的方法。Spring的JDBC抽象有比起标准JDBC来说性能损失非常小，甚至在当应用中需要的结果集数量很大的时候。
在org.springframework.jdbc.object包中是对JDBC的更高层次的抽象。这是建立在核心的JDBC回调功能基础纸上的，但是提供了一个能够对RDBMS操作——无论是查询，更新或者是存储过程——使用Java对象来建模的API。这个API部分是受到JDO查询API的影响，我发现它直观而且非常有用。
一个用于返回User对象的查询对象可能是这样的：
代码:
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);
}
}
这个类可以在下面用上：
代码:
User user = userQuery.findUser(25);
这样的对象经常可以用作DAO的inner class。它们是线程安全的，除非子类作了一些超出常规的事情。
在org.springframework.jdbc.object包中另一个重要的类是StoredProcedure类。Spring让存储过程通过带有一个业务方法的Java类进行代理。如果你喜欢的话，你可以定义一个存储过程实现的接口，意味着你能够把你的程序代码从对存储过程的依赖中完全解脱出来。
Spring数据访问异常层次是基于unchecked（运行时）exception的。在几个工程中使用了Spring之后，我越来越确信这个决定是正确的。
数据访问异常一般是不可恢复的。例如，如果我们不能链接到数据库，某个业务对象很有可能就不能完成要解决的问题了。一个可能的异常是optimistic locking violation，但是不是所有的程序使用optimistic locking。强制编写捕捉其无法有效处理的致命的异常通常是不好的。让它们传播到上层的handler，比如servlet或者EJB 容器通常更加合适。所有的Spring对象访问异常都是DataAccessException的子类，因而如果我们确实选择了捕捉所有的Spring数据访问异常，我们可以很容易做到这点。
注意如果我们确实需要从unchecked数据访问异常中恢复，我们仍然可以这么做。我们可以编写代码仅仅处理可恢复的情况。例如，如果我们认为只有optimistic locking violation是可恢复的，我们可以在Spring的DAO中如下这么写：
代码:
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I’m interested in this
}
如果Spring的数据访问异常是checked的，我们需要编写如下的代码。注意我们还是可以选择这么写：
代码:
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I’m interested in this
}
catch (DataAccessException ex) {
// Fatal; just rethrow it
}
第一个例子的潜在缺陷是——编译器不能强制处理可能的可恢复的异常——这对于第二个也是如此。因为我们被强制捕捉base exception（DataAccessException），编译器不会强制对子类（OptimisticLockingFailureException）的检查。因而编译器可能强制我们编写处理不可恢复问题的代码，但是对于强制我们处理可恢复的问题并未有任何帮助。
Spring对于数据访问异常的unchecked使用和许多——可能是大多数——成功的持久化框架是一致的。（确实，它部分是受到JDO的影响。）JDBC是少数几个使用checked exception的数据访问API之一。例如TopLink和JDO大量使用unchecked exception。Gavin King现在相信Hibernate也应该选择使用unchecked exception。
Spring的JDBC能够用以下办法帮助你：
你决不需要在使用JDBC时再编写finally block。
总的来说你需要编写的代码更少了
你再也不需要挖掘你的RDBMS的文档以找出它为错误的列名称返回的某个罕见的错误代码。你的程序不再依赖于RDBMS特有的错误处理代码。
无论使用的是什么持久化技术，你都会发现容易实现DAO模式，让业务代码无需依赖于任何特定的数据访问API。
在实践中，我们发现所有这些都确实有助于生产力的提高和更少的bug。我过去常常厌恶编写JDBC代码；现在我发现我能够集中精力于我要执行的SQL，而不是烦杂的JDBC资源管理。
如果需要的话Spring的JDBC抽象可以独立使用——不强迫你把它们用作Spring的一部分。
O/R mapping 集成
当然你经常需要使用O/R mapping，而不是使用关系数据访问。你总体的应用程序框架也必须支持它。因而提供了对Hibernate 2.x和JDO的集成支持。它的数据访问架构使得它能和任何底层的数据访问技术集成。Spring和Hibernate集成得尤其好。
为什么你要使用Hibernate加Spring，而不是直接使用Hibernate？
Session 管理 Spring提供有效率的，简单的以并且是安全的处理Hibernate Session。使用Hibernate的相关代码为了效率和恰当的事务处理一般需要使用相同的Hibernate “Session”对象。Spring让它容易透明地创建和绑定Session到当前的线程，要么使用声明式，AOP的method interceptor方法，要么在Java代码层面使用显式的，“template”包装类。因而Spring解决了在Hibernate论坛上经常出现的用法问题。
资源管理 Spring的应用程序context能够处理Hiberante SessionFactories的位置和配置，JDBC数据源和其他相关资源。这使得这些值易于管理和改变。
集成的事务管理 Spring让你能够把你的Hibernate代码包装起来，要么使用声明式，AOP风格的method interceptor，要么在Java代码层面显式使用“template”包装类。在两种做法中，事务语义都为你处理了，并且在异常时也做好了恰当的事务处理（回滚，等）。如下面讨论的，你还获得了能够使用和替换不同transaction manager，而不会让你相关Hibernate代码受到影响的能力。额外的，JDBC相关的代码能够完全事务性的和Hibernate代码集成。这对于处理没有在Hibernate实现的功能很有用。
如上描述的异常包装 Spring能够包装Hibernate异常，把它们从私有的，checked异常转换为一套抽象的运行时异常。这使得你能够仅仅在恰当的层面处理大部分不可恢复的持久化异常，而不影响样板catch/throw，和异常声明。你仍然能够在任何你需要的地方捕捉和处理异常。记住JDBC异常（包括DB特有的方言）也被转换到相同的层次中，意味着你能在一致的编程模型中对JDBC执行相同的操作。
为了避免和厂商绑定 Hibernate是强大的，灵活的，开放源代码并且免费，但是它仍然使用私有的API。给出了一些选择，使用标准或者抽象API实现主要的程序功能通常是你想要的，当你需要因为功能，性能，或者其他考虑要转换到使用其他实现时。
让测试变简单 Spring的Inversion of Control方法使得改变Hibernate的session factories，数据源，transaction manager的实现和位置很容易，如果需要的话还能改变mapper object的实现。这使得更加容易分离和测试持久化相关的代码。
事务管理
抽象出一个数据访问的API是不够的；我们还需要考虑事务管理。JTA是显而易见的选择，但是它是一个直接用起来很笨重的API，因而许多J2EE开发者感到EJB CMT是对于事务管理唯一合理的选择。
Spring提供了它自己对事务管理的抽象。Spring提供了这些：
通过类似于JdbcTemplate的回调模板编程管理事务，比起直接使用JTA要容易多了
类似于EJB CMT的声明式事务管理，但是不需要EJB容器
Spring的事务抽象式唯一的，它不绑定到JTA或者任何其他事务管理技术。Spring使用事务策略的概念把程序代码和底层的事务架构（例如JDBC）解藕。
为什么你要关心这些？JTA不是所有事务管理的最好答案吗？如果你正在编写仅仅使用一个数据库的程序，你不需要JTA的复杂度。你不关心XA事务或者两阶段提交。你甚至不需要提供这些东西的高端应用服务器。但是另一方面，你不会希望在需要和多个数据源打交道的时候重写你的代码。
假定你决定通过直接使用JDBC或者Hibernate的事务以避免JTA带来的额外负担。一旦你需要处理多个数据源，你必须剥开所有的事务管理代码并且使用JTA事务来替代。这不是非常有吸引力的并且导致大部分J2EE程序员，包括我自己，推荐只使用全局JTA事务。然而使用Spring事务抽象，你只需要重新配置Spring让它使用JTA，而不是JDBC或者Hibernate的事务策略，就一切OK了。这是一个配置上的改变，而不是代码的改动。因而，Spring使得你能够自由缩放应用。
AOP
最近在应用AOP来解决企业关注点方面大家有了很大的兴趣，例如事务管理，这些都是EJB所要解决的。
Spring的AOP支持的首要目标是要给POJOs提供J2EE服务。这类似于JBoss 4的目标，Spring AOP由它能够在应用服务器之间移植的优势，因而没有绑死在厂商身上的风险。它既可以在web或者EJB容器中使用，也能够在WebLogic，Tomcat，JBoss，Resin，Jetty，Orion和许多其他应用服务器和web容器上使用。
Spring AOP支持method interception。所支持关键的AOP概念包括：
Interception：自定义行为能够在对接口和类的调用之前和之后插入。这类似于AspectJ术语中类似的“around advice”。
Introduction：指定advice会导致对象实现额外的接口。这混乱了继承。
静态和动态的pointcuts：在interception发生的程序执行处指定points。静态pointcuts concern函数签名；动态pointcuts也可以在point被求值的地方考虑函数的参数。Pointcuts独立interceptors单独定义，使得标准interceptor可以应用于不同应用程序和代码上下文。
Spring既支持有状态（一个advised对象一个实例）也支持无状态的interceptors（所有advice使用一个实例）。
Spring不支持field interception。这是一个经过深思熟虑的设计决定。我总是感觉field interception违反了封装。我比较倾向于把AOP作为补全物，而不是与OOP冲突的东西。如果在5年或者10年后，我们在AOP学习曲线上走得更远了并且觉得应该在程序设计的桌面上给AOP一个位置，我不会惊讶的。（然而在那个时候基于语言的解决方案例如AspectJ可能比它们今天看来更加具有吸引力。）
Spring使用动态代理实现AOP（其中存在一个接口）或者在运行时使用CGLIB生成字节码（这使得能够代理类）。两种方法都能够在任何应用服务器中使用。
Spring是第一个实现AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。这些是定义在不同AOP框架中能够互操作interceptors的尝试。
在TheServerSide和其他地方有一个正在进行但是不是那么引人注目的争论，就是这种interception是不是“true AOP”。我倒不怎么在意它叫什么；仅仅需要知道它是否在实践中有用就好了。我也乐于称它为“declarative middleware”（声明式中间件）。把Spring AOP认做简单，轻量级的无状态beans的替代物，这样就不需要monolithic EJB容器了，而这些仅仅是让你能够构建有你需要的服务的容器。我不推荐advising任何一个POJO，对local SLSBs的类比有助于你理解推荐的粒度。（然而，与EJB不同的是，在恰当但是少见的情况下，你可以自由地把Spring的AOP应用到粒度更好的对象上。）
因为Spring在实例上advises 对象，而不是在class loader层面上，使用有不同advice的同一个类的多个实例是可能的，或者与advised实例一道使用unadvised 实例。
可能Spring AOP最常见的应用是声明式事务管理。这是基于前面描述的TansactionTemplate抽象上的，并且可以给任何POJO提供声明式事务管理。取决于事务策略，底层的机制可以是JTA，JDBC，Hibernate或者任何其他提供事务管理的API。
Spring的声明式事务管理类似于EJB CMT，在以下方面有些不同：
事务管理能够应用于任何POJO。我们推荐业务对象实现接口，但是这只是一个好的编程习惯的问题，而不是由框架强制的。
通过使用Spring的事务API能够在事务性POJO中实现编程回调。我们为此提供静态的方法，使用ThreadLoacal变量，因而你不需要传播诸如EJBContext这样的context对象来确保回滚。
你可以声明式地定义“回滚规则”。EJB不会在未捕捉程序异常的时候自动回滚（仅仅在unchecked exceptions和其他Throwables的时候），应用程序开发者经常需要在任何异常发生时回滚。Spring事务管理让你能够声明式地指定什么异常什么子类能够导致自动回滚。缺省的行为和EJB是一致的，但是你能够在checked和unchecked异常时自动回滚。这个在最少化自编程回调代码方面有很大好处，而回调依赖于Spring的事务API（因为EJB的编程回调时在EJBContext中完成的）。
事务管理不绑定于JTA。如前面解释过的，Spring的事务管理能够在不同事务策略中使用。
当然还可以使用Spring AOP实现程序特有的aspects。取决于你对AOP概念的接受程度，决定你是否选择这么做，而不是Spring的能力，但是它确实非常有用。我们所见过的成功例子包括：
自定义的security interception，当安全检查的复杂度超出了J2EE安全架构的能力的时候
在开发中使用的调试和profiling aspects
发送email通知管理员用户不寻常的举动的Interceptors
程序自定的aspects能够成为消除需要许多函数的样板代码的有利武器。
Spring AOP透明地与Sp
你决不需要在使用JDBC时再编写finally block。
总的来说你需要编写的代码更少了
你再也不需要挖掘你的RDBMS的文档以找出它为错误的列名称返回的某个罕见的错误代码。你的程序不再依赖于RDBMS特有的错误处理代码。
无论使用的是什么持久化技术，你都会发现容易实现DAO模式，让业务代码无需依赖于任何特定的数据访问API。
在实践中，我们发现所有这些都确实有助于生产力的提高和更少的bug。我过去常常厌恶编写JDBC代码；现在我发现我能够集中精力于我要执行的SQL，而不是烦杂的JDBC资源管理。
如果需要的话Spring的JDBC抽象可以独立使用——不强迫你把它们用作Spring的一部分。
O/R mapping 集成
当然你经常需要使用O/R mapping，而不是使用关系数据访问。你总体的应用程序框架也必须支持它。因而提供了对Hibernate 2.x和JDO的集成支持。它的数据访问架构使得它能和任何底层的数据访问技术集成。Spring和Hibernate集成得尤其好。
为什么你要使用Hibernate加Spring，而不是直接使用Hibernate？
Session 管理 Spring提供有效率的，简单的以并且是安全的处理Hibernate Session。使用Hibernate的相关代码为了效率和恰当的事务处理一般需要使用相同的Hibernate “Session”对象。Spring让它容易透明地创建和绑定Session到当前的线程，要么使用声明式，AOP的method interceptor方法，要么在Java代码层面使用显式的，“template”包装类。因而Spring解决了在Hibernate论坛上经常出现的用法问题。
资源管理 Spring的应用程序context能够处理Hiberante SessionFactories的位置和配置，JDBC数据源和其他相关资源。这使得这些值易于管理和改变。
集成的事务管理 Spring让你能够把你的Hibernate代码包装起来，要么使用声明式，AOP风格的method interceptor，要么在Java代码层面显式使用“template”包装类。在两种做法中，事务语义都为你处理了，并且在异常时也做好了恰当的事务处理（回滚，等）。如下面讨论的，你还获得了能够使用和替换不同transaction manager，而不会让你相关Hibernate代码受到影响的能力。额外的，JDBC相关的代码能够完全事务性的和Hibernate代码集成。这对于处理没有在Hibernate实现的功能很有用。
如上描述的异常包装 Spring能够包装Hibernate异常，把它们从私有的，checked异常转换为一套抽象的运行时异常。这使得你能够仅仅在恰当的层面处理大部分不可恢复的持久化异常，而不影响样板catch/throw，和异常声明。你仍然能够在任何你需要的地方捕捉和处理异常。记住JDBC异常（包括DB特有的方言）也被转换到相同的层次中，意味着你能在一致的编程模型中对JDBC执行相同的操作。
为了避免和厂商绑定 Hibernate是强大的，灵活的，开放源代码并且免费，但是它仍然使用私有的API。给出了一些选择，使用标准或者抽象API实现主要的程序功能通常是你想要的，当你需要因为功能，性能，或者其他考虑要转换到使用其他实现时。
让测试变简单 Spring的Inversion of Control方法使得改变Hibernate的session factories，数据源，transaction manager的实现和位置很容易，如果需要的话还能改变mapper object的实现。这使得更加容易分离和测试持久化相关的代码。
事务管理
抽象出一个数据访问的API是不够的；我们还需要考虑事务管理。JTA是显而易见的选择，但是它是一个直接用起来很笨重的API，因而许多J2EE开发者感到EJB CMT是对于事务管理唯一合理的选择。
Spring提供了它自己对事务管理的抽象。Spring提供了这些：
通过类似于JdbcTemplate的回调模板编程管理事务，比起直接使用JTA要容易多了
类似于EJB CMT的声明式事务管理，但是不需要EJB容器
Spring的事务抽象式唯一的，它不绑定到JTA或者任何其他事务管理技术。Spring使用事务策略的概念把程序代码和底层的事务架构（例如JDBC）解藕。
为什么你要关心这些？JTA不是所有事务管理的最好答案吗？如果你正在编写仅仅使用一个数据库的程序，你不需要JTA的复杂度。你不关心XA事务或者两阶段提交。你甚至不需要提供这些东西的高端应用服务器。但是另一方面，你不会希望在需要和多个数据源打交道的时候重写你的代码。
假定你决定通过直接使用JDBC或者Hibernate的事务以避免JTA带来的额外负担。一旦你需要处理多个数据源，你必须剥开所有的事务管理代码并且使用JTA事务来替代。这不是非常有吸引力的并且导致大部分J2EE程序员，包括我自己，推荐只使用全局JTA事务。然而使用Spring事务抽象，你只需要重新配置Spring让它使用JTA，而不是JDBC或者Hibernate的事务策略，就一切OK了。这是一个配置上的改变，而不是代码的改动。因而，Spring使得你能够自由缩放应用。
AOP
最近在应用AOP来解决企业关注点方面大家有了很大的兴趣，例如事务管理，这些都是EJB所要解决的。
Spring的AOP支持的首要目标是要给POJOs提供J2EE服务。这类似于JBoss 4的目标，Spring AOP由它能够在应用服务器之间移植的优势，因而没有绑死在厂商身上的风险。它既可以在web或者EJB容器中使用，也能够在WebLogic，Tomcat，JBoss，Resin，Jetty，Orion和许多其他应用服务器和web容器上使用。
Spring AOP支持method interception。所支持关键的AOP概念包括：
Interception：自定义行为能够在对接口和类的调用之前和之后插入。这类似于AspectJ术语中类似的“around advice”。
Introduction：指定advice会导致对象实现额外的接口。这混乱了继承。
静态和动态的pointcuts：在interception发生的程序执行处指定points。静态pointcuts concern函数签名；动态pointcuts也可以在point被求值的地方考虑函数的参数。Pointcuts独立interceptors单独定义，使得标准interceptor可以应用于不同应用程序和代码上下文。
Spring既支持有状态（一个advised对象一个实例）也支持无状态的interceptors（所有advice使用一个实例）。
Spring不支持field interception。这是一个经过深思熟虑的设计决定。我总是感觉field interception违反了封装。我比较倾向于把AOP作为补全物，而不是与OOP冲突的东西。如果在5年或者10年后，我们在AOP学习曲线上走得更远了并且觉得应该在程序设计的桌面上给AOP一个位置，我不会惊讶的。（然而在那个时候基于语言的解决方案例如AspectJ可能比它们今天看来更加具有吸引力。）
Spring使用动态代理实现AOP（其中存在一个接口）或者在运行时使用CGLIB生成字节码（这使得能够代理类）。两种方法都能够在任何应用服务器中使用。
Spring是第一个实现AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。这些是定义在不同AOP框架中能够互操作interceptors的尝试。
在TheServerSide和其他地方有一个正在进行但是不是那么引人注目的争论，就是这种interception是不是“true AOP”。我倒不怎么在意它叫什么；仅仅需要知道它是否在实践中有用就好了。我也乐于称它为“declarative middleware”（声明式中间件）。把Spring AOP认做简单，轻量级的无状态beans的替代物，这样就不需要monolithic EJB容器了，而这些仅仅是让你能够构建有你需要的服务的容器。我不推荐advising任何一个POJO，对local SLSBs的类比有助于你理解推荐的粒度。（然而，与EJB不同的是，在恰当但是少见的情况下，你可以自由地把Spring的AOP应用到粒度更好的对象上。）
因为Spring在实例上advises 对象，而不是在class loader层面上，使用有不同advice的同一个类的多个实例是可能的，或者与advised实例一道使用unadvised 实例。
可能Spring AOP最常见的应用是声明式事务管理。这是基于前面描述的TansactionTemplate抽象上的，并且可以给任何POJO提供声明式事务管理。取决于事务策略，底层的机制可以是JTA，JDBC，Hibernate或者任何其他提供事务管理的API。
Spring的声明式事务管理类似于EJB CMT，在以下方面有些不同：
事务管理能够应用于任何POJO。我们推荐业务对象实现接口，但是这只是一个好的编程习惯的问题，而不是由框架强制的。
通过使用Spring的事务API能够在事务性POJO中实现编程回调。我们为此提供静态的方法，使用ThreadLoacal变量，因而你不需要传播诸如EJBContext这样的context对象来确保回滚。
你可以声明式地定义“回滚规则”。EJB不会在未捕捉程序异常的时候自动回滚（仅仅在unchecked exceptions和其他Throwables的时候），应用程序开发者经常需要在任何异常发生时回滚。Spring事务管理让你能够声明式地指定什么异常什么子类能够导致自动回滚。缺省的行为和EJB是一致的，但是你能够在checked和unchecked异常时自动回滚。这个在最少化自编程回调代码方面有很大好处，而回调依赖于Spring的事务API（因为EJB的编程回调时在EJBContext中完成的）。
事务管理不绑定于JTA。如前面解释过的，Spring的事务管理能够在不同事务策略中使用。
当然还可以使用Spring AOP实现程序特有的aspects。取决于你对AOP概念的接受程度，决定你是否选择这么做，而不是Spring的能力，但是它确实非常有用。我们所见过的成功例子包括：
自定义的security interception，当安全检查的复杂度超出了J2EE安全架构的能力的时候
在开发中使用的调试和profiling aspects
发送email通知管理员用户不寻常的举动的Interceptors
程序自定的aspects能够成为消除需要许多函数的样板代码的有利武器。
Spring AOP透明地与Sp
Session 管理 Spring提供有效率的，简单的以并且是安全的处理Hibernate Session。使用Hibernate的相关代码为了效率和恰当的事务处理一般需要使用相同的Hibernate “Session”对象。Spring让它容易透明地创建和绑定Session到当前的线程，要么使用声明式，AOP的method interceptor方法，要么在Java代码层面使用显式的，“template”包装类。因而Spring解决了在Hibernate论坛上经常出现的用法问题。
资源管理 Spring的应用程序context能够处理Hiberante SessionFactories的位置和配置，JDBC数据源和其他相关资源。这使得这些值易于管理和改变。
集成的事务管理 Spring让你能够把你的Hibernate代码包装起来，要么使用声明式，AOP风格的method interceptor，要么在Java代码层面显式使用“template”包装类。在两种做法中，事务语义都为你处理了，并且在异常时也做好了恰当的事务处理（回滚，等）。如下面讨论的，你还获得了能够使用和替换不同transaction manager，而不会让你相关Hibernate代码受到影响的能力。额外的，JDBC相关的代码能够完全事务性的和Hibernate代码集成。这对于处理没有在Hibernate实现的功能很有用。
如上描述的异常包装 Spring能够包装Hibernate异常，把它们从私有的，checked异常转换为一套抽象的运行时异常。这使得你能够仅仅在恰当的层面处理大部分不可恢复的持久化异常，而不影响样板catch/throw，和异常声明。你仍然能够在任何你需要的地方捕捉和处理异常。记住JDBC异常（包括DB特有的方言）也被转换到相同的层次中，意味着你能在一致的编程模型中对JDBC执行相同的操作。
为了避免和厂商绑定 Hibernate是强大的，灵活的，开放源代码并且免费，但是它仍然使用私有的API。给出了一些选择，使用标准或者抽象API实现主要的程序功能通常是你想要的，当你需要因为功能，性能，或者其他考虑要转换到使用其他实现时。
让测试变简单 Spring的Inversion of Control方法使得改变Hibernate的session factories，数据源，transaction manager的实现和位置很容易，如果需要的话还能改变mapper object的实现。这使得更加容易分离和测试持久化相关的代码。
事务管理
抽象出一个数据访问的API是不够的；我们还需要考虑事务管理。JTA是显而易见的选择，但是它是一个直接用起来很笨重的API，因而许多J2EE开发者感到EJB CMT是对于事务管理唯一合理的选择。
Spring提供了它自己对事务管理的抽象。Spring提供了这些：
通过类似于JdbcTemplate的回调模板编程管理事务，比起直接使用JTA要容易多了
类似于EJB CMT的声明式事务管理，但是不需要EJB容器
Spring的事务抽象式唯一的，它不绑定到JTA或者任何其他事务管理技术。Spring使用事务策略的概念把程序代码和底层的事务架构（例如JDBC）解藕。
为什么你要关心这些？JTA不是所有事务管理的最好答案吗？如果你正在编写仅仅使用一个数据库的程序，你不需要JTA的复杂度。你不关心XA事务或者两阶段提交。你甚至不需要提供这些东西的高端应用服务器。但是另一方面，你不会希望在需要和多个数据源打交道的时候重写你的代码。
假定你决定通过直接使用JDBC或者Hibernate的事务以避免JTA带来的额外负担。一旦你需要处理多个数据源，你必须剥开所有的事务管理代码并且使用JTA事务来替代。这不是非常有吸引力的并且导致大部分J2EE程序员，包括我自己，推荐只使用全局JTA事务。然而使用Spring事务抽象，你只需要重新配置Spring让它使用JTA，而不是JDBC或者Hibernate的事务策略，就一切OK了。这是一个配置上的改变，而不是代码的改动。因而，Spring使得你能够自由缩放应用。
AOP
最近在应用AOP来解决企业关注点方面大家有了很大的兴趣，例如事务管理，这些都是EJB所要解决的。
Spring的AOP支持的首要目标是要给POJOs提供J2EE服务。这类似于JBoss 4的目标，Spring AOP由它能够在应用服务器之间移植的优势，因而没有绑死在厂商身上的风险。它既可以在web或者EJB容器中使用，也能够在WebLogic，Tomcat，JBoss，Resin，Jetty，Orion和许多其他应用服务器和web容器上使用。
Spring AOP支持method interception。所支持关键的AOP概念包括：
Interception：自定义行为能够在对接口和类的调用之前和之后插入。这类似于AspectJ术语中类似的“around advice”。
Introduction：指定advice会导致对象实现额外的接口。这混乱了继承。
静态和动态的pointcuts：在interception发生的程序执行处指定points。静态pointcuts concern函数签名；动态pointcuts也可以在point被求值的地方考虑函数的参数。Pointcuts独立interceptors单独定义，使得标准interceptor可以应用于不同应用程序和代码上下文。
Spring既支持有状态（一个advised对象一个实例）也支持无状态的interceptors（所有advice使用一个实例）。
Spring不支持field interception。这是一个经过深思熟虑的设计决定。我总是感觉field interception违反了封装。我比较倾向于把AOP作为补全物，而不是与OOP冲突的东西。如果在5年或者10年后，我们在AOP学习曲线上走得更远了并且觉得应该在程序设计的桌面上给AOP一个位置，我不会惊讶的。（然而在那个时候基于语言的解决方案例如AspectJ可能比它们今天看来更加具有吸引力。）
Spring使用动态代理实现AOP（其中存在一个接口）或者在运行时使用CGLIB生成字节码（这使得能够代理类）。两种方法都能够在任何应用服务器中使用。
Spring是第一个实现AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。这些是定义在不同AOP框架中能够互操作interceptors的尝试。
在TheServerSide和其他地方有一个正在进行但是不是那么引人注目的争论，就是这种interception是不是“true AOP”。我倒不怎么在意它叫什么；仅仅需要知道它是否在实践中有用就好了。我也乐于称它为“declarative middleware”（声明式中间件）。把Spring AOP认做简单，轻量级的无状态beans的替代物，这样就不需要monolithic EJB容器了，而这些仅仅是让你能够构建有你需要的服务的容器。我不推荐advising任何一个POJO，对local SLSBs的类比有助于你理解推荐的粒度。（然而，与EJB不同的是，在恰当但是少见的情况下，你可以自由地把Spring的AOP应用到粒度更好的对象上。）
因为Spring在实例上advises 对象，而不是在class loader层面上，使用有不同advice的同一个类的多个实例是可能的，或者与advised实例一道使用unadvised 实例。
可能Spring AOP最常见的应用是声明式事务管理。这是基于前面描述的TansactionTemplate抽象上的，并且可以给任何POJO提供声明式事务管理。取决于事务策略，底层的机制可以是JTA，JDBC，Hibernate或者任何其他提供事务管理的API。
Spring的声明式事务管理类似于EJB CMT，在以下方面有些不同：
事务管理能够应用于任何POJO。我们推荐业务对象实现接口，但是这只是一个好的编程习惯的问题，而不是由框架强制的。
通过使用Spring的事务API能够在事务性POJO中实现编程回调。我们为此提供静态的方法，使用ThreadLoacal变量，因而你不需要传播诸如EJBContext这样的context对象来确保回滚。
你可以声明式地定义“回滚规则”。EJB不会在未捕捉程序异常的时候自动回滚（仅仅在unchecked exceptions和其他Throwables的时候），应用程序开发者经常需要在任何异常发生时回滚。Spring事务管理让你能够声明式地指定什么异常什么子类能够导致自动回滚。缺省的行为和EJB是一致的，但是你能够在checked和unchecked异常时自动回滚。这个在最少化自编程回调代码方面有很大好处，而回调依赖于Spring的事务API（因为EJB的编程回调时在EJBContext中完成的）。
事务管理不绑定于JTA。如前面解释过的，Spring的事务管理能够在不同事务策略中使用。
当然还可以使用Spring AOP实现程序特有的aspects。取决于你对AOP概念的接受程度，决定你是否选择这么做，而不是Spring的能力，但是它确实非常有用。我们所见过的成功例子包括：
自定义的security interception，当安全检查的复杂度超出了J2EE安全架构的能力的时候
在开发中使用的调试和profiling aspects
发送email通知管理员用户不寻常的举动的Interceptors
程序自定的aspects能够成为消除需要许多函数的样板代码的有利武器。
Spring AOP透明地与Sp
Singleton就是单元素设计模式,该设计模式确保了在一个运用程序中,无论合饰地,这个类就只有一个实例可用.
适用范围.这种设计模式经常用于数据源库连接池对象等方面.因为无论你是从程序中的任何部分需要访问数据库,都是从该连接池中取出一个连接,用完后,再将连接放会连接池中.因此仅只需要一个连接池实例,该实例从第一次访问初始化,到运用程序关闭,他的生命周期才结束.
这种设计模式最大的特点是构造器设为私有,再申明一个类型为自己本身的静态私有变量myself,然后编写一个获取该类实例的静态公有方法(一般使用方法名为"getInstance()",你用其他名字也可以,但是这是一个约定俗成的规范),在这个方法中,判断,如果myself未被初始化,说明是第一次访问该对象,则调用私有构造器对myself进行初始化,然后返回myself,如果myslef已经被初始化,那直接返回myself.
下面我就以编写一个数据库连接池类来具体说明一下这种设计模式.
假设你已经在你的web容器中配制好了一个名为"jdbc/xxx"的数据源
package xxx;
import java.sql.SQLException;
import java.sql.Connection;
import javax.sql.DataSource;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Properties;
public class ConnectionPool {
private static String JDNI_NAME = "java:comp/env/jdbc/xxx";
private DataSource ds;
//申明一个类型为自己本身的变量
private static ConnectionPool mySelf;
/**
* 定义一个私有的构造器
* @param ds DataSource
*/
private ConnectionPool(DataSource ds){
this.ds = ds;
}
/**
* 获取类实例的方法
* @return ConnectionPool
*/
public static ConnectionPool getInstance() {
try {
//如果myself未被初始化过
if (mySelf == null) {
Context initCtx = new InitialContext();
if (initCtx == null) {
throw new NamingException("error.context.init");
}
DataSource ds = (DataSource) initCtx.lookup(JDNI_NAME);
//调用私有构造器对其进行实例化
mySelf = new ConnectionPool(ds);
}
return mySelf;
} catch (NamingException ne) {
ne.printStackTrace();
throw new RuntimeException("error.connectionpool.getinstance");
}
}
/**
* 获取连接方法
* @param autoCommit boolean
* @return Connection
* @throws SQLException
*/
public Connection getConnection(boolean autoCommit) throws SQLException {
Connection con = ds.getConnection();
con.setAutoCommit(autoCommit);
return con;
}
}
EJB,是企业JAVA BEAN的缩写,这里想跟大家谈谈一些实质的问题
================
为什么要使用EJB?
================
EJB最大的诱人之处是她把应用程序和服务器分开了,我们再也不用和那些服务器上的复杂的资源打交道了,什么数据库,什么进程,线程,什么安全权限,什么套接字,都见鬼去吧,我们只需要专著于我们的商业逻辑的实现了.
==========
EJB的实质?
==========
EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理…
=============
EJB服务器产品
=============
各个WEB服务器开发商基本上都在他们WEB服务器中新捆绑了EJB容器,或者叫EJB服务器.其中最简单也是最根本的是J2EE开发环境带的J2EE的EJB容器,它很好的和J2EE的HTTP服务器和Servlet引擎一起构筑了一个很好的运行环境,由于配置简单,功能强大,因此成为我的最爱.另外象BEA的Weblogical是值得推荐的一个产品,它的WEB服务器功能相当强大,是当今很多网站构筑的理想WEB服务器,它也已经加入了EJB的行列,在EJB方面有着不俗的表现.Inprise的IAS更是一个功能强大的WEB服务器,同样,也嵌入了EJB容器,加之与本公司的JBuilder的无接缝结合,更使它人气攀升.
还有象IBM的WebSphere也不错,不过Apache是否已经搭载了EJB容器,我不太清楚.
另外,推荐一个EJBoss,是一个完全免费的EJB服务器,而且是原代码公开的.
========================
EJB容器如何包装你的BEAN.
========================
这年头没有天上掉馅饼的好事情,EJB也不例外,你想让EJB容器替你管理你编写的EJB的吃喝拉萨睡,凭什么?!凭XML描述子,你通过一个XML文件告诉EJB容器BEAN的相关配置信息,比如我的EJB的HOME接口和REMOTE接口是哪一个类,比如我的EJB的别名(实际上是JNDI名称)叫什么,比如我的EJB是否是实体类型的EJB还是对话类型的EJB,比如告诉容器替我管理我的实体EJB中哪些自段,……总之,你得跟咱们的EJB大总管—-EJB容器把所有都交代清楚.这样,剩下的,就看EJB容器的了!!!
你是不是总共写过3个文件,BEAN定义,HOME接口定义,ROMOTE接口定义,
当你DEPLOY他们时,容器会
(1).首先根据HOME和REMOTE接口生成他们的实现代码,我们不妨叫做HOME_IMPL和REMOTE_IMPL,
(2).然后,利用RMIC产生HOME_IMPL和REMOTE_IMPL的STUB和SKELETON文件,2X2一共生成4个文件.
(STUB和SKELETON请参见RMI的相关概念)
如此这般,最后,在服务器上,一共有
BEAN
HOME_IMPL
REMOTE_IMPL
HOME_STUB
HOME_SKELETON
REMOTE_STUB
REMOTE_SKELETON
7文件,才能让EJB工作起来.
(3).生成实体EJB对应的数据库的库表
(4).注册你的EJB到JNDI服务
===============================================================
为什么除了写BEAN,还得写接口文件,而且干嘛要HOME和REMOTE两个接口.
===============================================================
我搅着吧,这两个接口完全是可以合并成一个接口的,其实他们的作用都只是一个接口,为了让那人家SUN干吗还拆成两个呢?我想,正如SUN所说的,为了将一些容器相关操作和客户商业方法分开,什么意思?说开了吧,HOME用来规范容器相关的操作方法,REMOTE负责专心致志的定制商业方法,而我们的BEAN才是最终的逻辑实现者.
还是不明白?没关系,我在说的细些,
举例说明:
把我想象成一个BEAN,HOME接口就是我们家人的命令,REMOTE接口就是我们单位的领导的命令,我们家人的命令决定了我如何吃喝拉萨睡,领导的命令决定了我如何做一些真正的工作,请注意这里我使用了"决定"这个字眼,
我并没有说我们家人,而是说了我们家人的命令,这个命令的含义就是接口,不是类,而我这个BEAN却是个类!还有,BEAN类不实现REMOTE和HOME接口,记住!记住!
=========
EJB的分类
=========
EJB分为实体(Entity)EJB和对话(Session)EJB,
>>>>>>实体EJB:>>>>>>对话EJB<<<<<<<
对话EJB根本根本不和数据库打交道,为什么,因为他根本不用序列化!他只负责来完成一些逻辑操作,比如算个帐什么的.
为了和实体EJB较劲,他也一口气生了两个儿子,
a.有状态(sessionful)对话EJB
他就跟servlet中的session对象似的,可以保存用户的session相关信息,而且他仅仅被一个用户的一次session所使用,不和别人共享,我管他叫对话,不过这"对话"翻出来这是够难听的,还不如就叫他session呢!
b.无状态(sessionless)对话EJB
这个东东是最简单的EJB,他是可以被多个用户共享,注意!我所说的共享是指实例的共享!
======================================
一个BEAN管理持续化的实体EJB(BMP)小例子
======================================
说了半天了,大家珍贵的脑资源恐怕被我消耗的差不多了,好,让我们来剖析一个BEAN管理持续化的实体EJB(BMP)吧.
———————–看看REMOTE接口——————————
public interface Account extends EJBObject {//必须从EJBObject继承
//这些都是商业方法,而且这里写了的,必须在BEAN中都实现
public void deposit(double amt) throws RemoteException;
public double withdraw(double amt) throws AccountException, RemoteException;
public double getBalance() throws RemoteException;
public String getOwnerName() throws RemoteException;
public void setOwnerName(String name)throws RemoteException;
}
————————-看看HOME接口———————————
public interface AccountHome extends EJBHome {
//这声明了create函数,由于是BMP,所以必须在BEAN中实现一个叫ejbCreate的对应函数
Account create(String accountID, String ownerName) throws CreateException, RemoteException;
//按主键查询
//由于是BMP,所以必须在BEAN中实现一个叫ejbFindByPrimaryKey的对应函数
public Account findByPrimaryKey(AccountPK key) throws FinderException, RemoteException;
//按其中的Name字段查询
//由于是BMP,所以必须在BEAN中实现一个叫ejbFindByOwnerName的对应函数
public Account findByOwnerName(String name) throws FinderException, RemoteException;
}
—————————看看BEAN———————————–
public class AccountBean implements EntityBean {
//三个PUBLIC字段,他们将来对应库表的三个字段
public String accountID
public String ownerName;
public double balance;
//—-HOME中声明的create方法的影射实现
//由于是BMP,所以必须自己来负责实例创建时实例到数据库的影射
public AccountPK ejbCreate(String accountID, String ownerName) throws CreateException, RemoteException {
PreparedStatement pstmt = null;
Connection conn = null;
try {
this.ownerName = ownerName;
this.balance = 0;
conn = getConnection();
pstmt = conn.prepareStatement("insert into accounts (id, ownerName, balance) values (?, ?, ?)");
pstmt.setString(1, accountID);
pstmt.setString(2, ownerName);
pstmt.setDouble(3, balance);
//看这里,看这里!插进去了…
pstmt.executeUpdate();
return new AccountPK(accountID);
}catch (Exception e) {
throw new CreateException(e.toString());
}finally {
try {
pstmt.close();
conn.close();
}catch (Exception e) { }
}
}
//—-HOME中声明的findByOwnerName方法的影射实现
//由于是BMP,所以必须自己来完成按照Name字段查找的工作
public AccountPK ejbFindByOwnerName(String name) throws FinderException, RemoteException {
PreparedStatement pstmt = null;
Connection conn = null;
try {
conn = getConnection();
pstmt = conn.prepareStatement("select id from accounts where ownerName = ?");
pstmt.setString(1, name);
//看看看!找上了,根据名称…
ResultSet rs = pstmt.executeQuery();
rs.next();
String id = rs.getString("id");
pstmt.close();
conn.close();
return new AccountPK(id);
}catch (Exception e) {
throw new FinderException(e.toString());
}finally {
try {
pstmt.close();
conn.close();
}catch (Exception e) { }
}
}
//—-REMOTE中声明的一个方法的实现
//这是一个商业方法,来完成帐户的存款查询
public double getBalance() {
System.out.println("[AccountEJB-getBalance]getBalance() called.");
return balance;
}
…….其他的方法,由于篇幅问题就不一一列出了,请大家参阅原代码!
J2EE 在今日已经逐渐的成为企业中标准的应用程序平台，同时也
有许多的程序设计师，甚至网页设计人员，利用 JSP/Servlet 的便
利性，在 J2EE Server 上开发相关的应用，或是与公司内部的资源
相连接。
最近也有许多人慢慢的投入 J2EE 中的其它技术，其中 EJB 就是
一个很值得投资的技术。
这篇文件并不是要教您如何撰写 EJB ，但是希望让对 EJB 有兴
趣的使用者，能够大致了解 EJB 能让您作哪些事情。
EJB 依照特性的不同，目前区分为三种，分别是 Session Bean ，
Entity Bean ，以及 Message Driven Bean 。其中 Session Bean 与
Entity Bean 算是 EJB 的始祖，这两种 EJB 在 EJB 规格 1.x 的时候
就已经存在了，而 Message Driven Bean 则出现在 EJB 2.0 的规格中
。目前也有少数几家厂商的 J2EE Server 支持 EJB 2.0 的规格。
Session Bean
Session Bean 主要的目的是让程序开发者将逻辑层抽离，特别是复
杂的逻辑可以放在 Session Bean 中。Session Bean 还可以再细分为
Stateful Session Bean 与 Stateless Session Bean ，这两种的 Session Bean
都可以将系统逻辑放在 method之中执行，不同的是 Stateful Session
Bean 可以记录呼叫者的状态，因此通常来说，一个使用者会有一
个相对应的 Stateful Session Bean 的实体 (Instance 注一) ，换言之，
当使用者呼叫某个 Stateful Session Bean 的两个 methods 的时候，
EJB Container(注一) 会清楚的知道某个 EJB 的实体属于某一个使用
者的。因此一般的设计上，不会让两个使用者同时使用某个 Stateful
Session Bean (这并不是表示两个使用者不能使用同一个 Stateful Session
Bean)。
Stateless Session Bean 虽然也是逻辑组件，但是他却不负责记录使
用者状态，也就是说当使用者呼叫 Stateless Session Bean 的时候，
EJB Container 并不会找寻特定的 Stateless Session Bean 的实体
来执行这个 method ，换言之，很可能数个使用者在执行某个 Stateless
Session Bean 的 methods 时，会是同一个 Bean 的 Instance 在执行。
从内存方面来看， Stateful Session Bean 与 Stateless Session
Bean 比较， Stateful Session Bean 会消耗 J2EE Server 较多的内存，
然而 Stateful Session Bean 的优势却在于他可以维持使用者的状态。
Entity Bean
Entity Bean 主要是资料组件， Entity Bean 主要的目的，在于提供资
料，也就是说程序设计师可以将 Entity Bean 当程序资料，至于 Entity
Bean 实际上怎么存取实际上的数据库，那个则是另外一件事情。
Entity Bean 实际上是针对 RDBMS 而设计，也就是说当其它的程序使
用Entity Bean 的时候， Entity Bean 的资料主要是从 RDBMS 而来，当
然，如果程序设计师熟悉 Entity Bean 的运作，那么也可以很轻易的把
RDBMS 用其它的数据库取代，像是 LDAP 。
Entity Bean 主要区分为 Bean-Managed Persistence 以及 Container-
Managed Persistence (简称 BMP 及 CMP) ，这两种 Entity Bean 的型
态不同，但是目的相同，都在于提供资料！这两种 Entity Bean 主要的
差别在于维护资料的角色， BMP 是由 Bean 自行维护资料的一致性，
而CMP 则是由 EJB Container 来维护。一个 Entity Bean 往往代表一张
RDBMS 的表格，这个表格内的一笔一笔的资料，则是透过另外一个
叫做 Primary Key(注三) 的 Class 来加以区分。
Bean-Managed Persistence
当我们说 BMP 是由 Bean 自行维护资料的一致时，有些人会觉得太过
于抽象，简单一点来说，原来的资料均由数据库而来，而当资料从资
料库中取出之后，在 BMP 中需要自行宣告字段来存放这些资料，同
时也要自行撰写相关的程序代码，包括相关的 JDBC 语法等等。
Container-Managed Persistence
CMP 是比较高阶的 Entity Bean ，比较高阶的意思是说，撰写 CMP 的
程序设计师并不需要撰写大多数的 JDBC 语法，只需要透过一些定义
，即可产生 CMP ，实际上的 EJB 的程序代码则是 EJB Container 依据相
关的 Deployment Description (注四) 在部署（注五） EJB 的时候产生。
BMP 与 CMP 的型态不同，适用的场合也不同，主要的差异在于如果
我们想要自行控制所有的动作，那么应该使用 BMP ， BMP 允许程序
设计师完全的控制 BMP 的资料存取行为，而 CMP 很适合快速开发，
但是由于要支持 CMP 的 J2EE Server 需要较高的技术，因此每一家对于
CMP 的支持程度也不大相同。
此外，数据库中有一个很重要的关系是 OR Mapping ，也就是常听到的
一对一，一对多，多对多这种关系，在 EJB 1.x 的规格中，这种一对多
的对应关系只有两种方式可以做出，一种是透过 Session Bean 来存取
多个 Entity Bean ，另外一种则是透过 BMP 来控制另外数个 BMP 或是
CMP ，但是在 EJB 2.0 的规格中，已经可以透过纯粹的 CMP 配合
EJB-QL(注六) 语法来做出这种对应关系，这也是 EJB 2.0 的一大特色。
Message Driven Bean
Message Driven Bean 与 Session Bean 或是 Entity Bean 均不相同，
一般 Session Bean 或是 Entity Bean 都可以让使用者主动触发（可以
在需要的时候，呼叫他们的 method 来触发他们），但是 Message Driven
Bean 主要的目的在于反应 Message Queue 中的事件。
也就是当 Message Queue 中有讯息传入时， Message Driven Bean 可
以主动被触发，做出相对应的反应。因此如果说 Session Bean 与 Entity
Bean 是同步模式的 EJB (使用者呼叫某个 Method ，就只能等 EJB 响应
之后才能进行下一步)，那么 Message Driven Bean 就可以当成是专门处
理异步资料格式的 EJB ，也就是说程序设计师将某个讯息丢入 Message
Queue 之后，就继续执行下去，另外一方面， Message Driven Bean 会
受到通知，知道有某个讯息需要处理，这时候他会自行运作。
因此 Message Driven Bean 并不是直接给使用者呼叫的，而是透过 Message
Queue 来触发。
如果您对 EJB 有兴趣，可以参考 Sun 的教育训练课程 SL-351 。
注一：
Bean Instance 表示在内存中实际上产生的对象，一个 Bean Class
可以产生多个 Bean Instance 。Bean Instance 才是真正执行 EJB
method 的对象，可想而知的是， Instance 的数量越多，耗去的内存
越多。
注二：
EJB Container 是负责执行 EJB 的地方，所有 EJB 的产生，或是消灭
，或是执行等等，均透过 EJB Container 来处理。当使用者呼叫某个
EJB 的时候，实际上也是透过 EJB Container 来执行。
注三：
在 RDBMS 中，一张 Table 可能会有相关的 Primary Key 的字段，而
Entity Bean 中也有相对应的 Class 来表示这个 Primary Key ，譬如
如果数据库中，某个 VARCHAR 字段是它的 Primary Key ，那么
Entity Bean 中则可以用 String 来表示这个 VARCHAR 字段。
注四：
Deployment Description 是一种 XML 格式的文件(简称 DD)，这个文件
用来描述 EJB 的种类，型态，以及相关的资料。 EJB 的运作中，也
以 DD 内的描述为主。
注五：
部署是一个动作，一个写好的 EJB 并不能单独执行，他必须被"置放"
到EJB Container 之后才能够运作，这个置放的动作，我们叫做部署。
部署的动作相当复杂，但是对使用者来说很可能是按个按钮即可以完
成。
注六：
EJB-QL 是一种查询 EJB Instance 的特殊语法，语法格式与 ANSI SQL
很像，很容易上手。这个语法会被放置在 DD 之中，而 EJB Container
可以依照从 DD 取得的 EJB-QL 语法，自行产生与其它 CMP 的关联。
[Tomjava原创]
很多网友问我学习Java有没有什么捷径,我说“无他，唯手熟尔”。但是我却很愿意将自己学习的一些经验写出来，以便后来者少走弯路,帮助别人是最大的快乐嘛！
要想学好Java，首先要知道Java的大致分类。我们知道，自从Sun推出Java以来，就力图使之无所不包，所以Java发展到现在，按应用来分主要分为三大块：J2SE,J2ME和J2EE,这也就是Sun ONE(Open Net Environment)体系。J2SE就是Java2的标准版，主要用于桌面应用软件的编程；J2ME主要应用于嵌入是系统开发，如手机和PDA的编程；J2EE是Java2的企业版，主要用于分布式的网络程序的开发，如电子商务网站和ERP系统。J2SE开发桌面应用软件比起VC,VB,DEPHI这些传统开发语言来说，优势好象并不明显。J2ME对于初学者来说，好象又有点深奥，而且一般开发者很难有开发环境。所以现在应用最广泛又最好学的就是J2EE了。J2EE又包括许多组件，如Jsp,Servlet,JavaBean,EJB,JDBC,JavaMail等。要学习起来可不是一两天的事。
那么又该如何学习J2EE呢？当然Java语法得先看一看的，I/O包，Util包，Lang包你都熟悉了吗？然后再从JSP学起。如果你学过HTML，那么事情要好办的多，如果没有，那你快去补一补HTML基础吧。其实JSP中的Java语法也不多，它更象一个脚本语言，有点象ASP。然后你就该学一学Servlet了。Servlet就是服务器端小程序，他负责生成发送给客户端的HTML文件。JSP在执行时，也是先转换成Servlet再运行的。虽说JSP理论上可以完全取代Servlet，这也是SUN推出JSP的本意，可是Servlet用来控制流程跳转还是挺方便的，也令程序更清晰。接下来你应该学习一下Javabean了，可能你早就看不管JSP在HTML中嵌Java代码的混乱方式了，这种方式跟ASP又有什么区别呢？还好，SUN提供了Javabean可以把你的JSP中的Java代码封装起来，便于调用也便于重用。接着就是EJB了，EJB就是Enterprise JavaBean,看名字好象它是Javabean，可是它和Javabean还是有区别的。它是一个体系结构，你可以搭建更安全、更稳定的企业应用。它的大量代码已由中间件（也就是我们常听到的Weblogic,Websphere这些J2EE服务器）完成了，所以我们要做的程序代码量很少，大部分工作都在设计和配置中间件上。至于JDBC，就不用我多说了，你如果用java编过存取数据库的程序，就应该很熟悉。还有，如果你要用Java编发送电子邮件的程序，你就得看看Javamail了。
好了，对Java和J2EE有了一些基本概念之后，你就应该编一些程序了，千万不要纸上谈兵哦。最好找一些有实例且带光盘的书来看，这样看到好的程序就可以直接Ctrl+C再Ctrl+V，也不用劳您老大架再亲自把它 再输一遍吧，再说直接复制还不用怕出错，何乐而不为呢！还有就是要经常上一些好的Java编程文章，有好的文章要Cut下来，有问题尽管问，只要问题不是太傻，一般高手都会回答你的。下面介绍几个好的Java方面的编程网站：
CSDN论坛 http://www.csdn.net/ 中国最有名的技术论坛，《程序员》杂志就是他们出版的，你可以在上面提出问题，马上就有人回答你，如果你觉得好，你可以给那人加分；
Java研究组织http://www.javaresearch.org/ 上面有很多原创文章，高手还是挺多的；
Java开发者 http://www.chinajavaworld.com/ 那里Java资料比较全；
java.com.cn http://www.java.com.cn/ 看这域名就知道有多牛，注册用户快接近一万了，同时在线人数也在一千左右，人气很旺的；
IBM的开发者网络http://www-900.ibm.com/developerWorks/cn/java/index.shtml IBM永远的蓝色巨人；
那么我书也看了，程序也做了，别人问我的问题我都能解决了，是不是就成为高手了呢？当然没那么简单，这只是万里长征走完了第一步。不信？那你出去接一个项目，你知道怎么下手吗，你知道怎么设计吗，你知道怎么组织人员进行开发吗？你现在脑子里除了一些散乱的代码之外，可能再没有别的东西了吧！你现在最缺的是实际的工作经验，而不是书本上那些凭空想出来的程序。所以你快去找一份Java的编程工作来做吧（如果是在校学生可以去做兼职啊），在实践中提高自己，那才是最快的。不过你得祈祷在公司里碰到一个高手，而且他还愿意不厌其烦地教你，这样好象有点难哦！
还有一个办法就是读开放源码的程序了。我们知道开放源码大都出自高手，他们设计合理，考虑周到，再加上有广大的程序员参与，代码的价值自然是字字珠叽，铿锵有力（对不起，偶最近《金装四大才子》看多了）。学Java必读的两个开源程序就是Jive和Pet Store.。Jive是国外一个非常著名的BBS程序，完全开放源码。论坛的设计采用了很多先进的技术，如Cache、用户认证、Filter、XML等，而且论坛完全屏蔽了对数据库的访问，可以很轻易的在不同数据库中移植。论坛还有方便的安装和管理程序，这是我们平时编程时容易忽略的一部份（中国程序员一般只注重编程的技术含量，却完全不考虑用户的感受，这就是我们与国外软件的差距所在）。Jive的资料在很多网站上都有，大家可以找来研究一下。相信你读完代码后，会有脱胎换骨的感觉。遗憾的是Jive从2.5以后就不再无条件的开放源代码，同时有licence限制。不过幸好还有中国一流的Java程序员关注它，外国人不开源了，中国人就不能开源吗？这里向大家推荐一个汉化的Jive版本—J道。Jive(J道版)是由中国Java界大名鼎鼎的banq在Jive 2.1版本基础上改编而成, 全中文，增加了一些实用功能，如贴图，用户头像和用户资料查询等，而且有一个开发团队在不断升级。你可以访问banq的网站http://www.jdon.com/ 去下载，或到同济技术论坛的服务器上ftp://nro.shtdu.edu.cn去下，安装上有什么问题，可以到论坛上去提问。Pet Store.（宠物店）是SUN公司为了演示其J2EE编程规范而推出的开放源码的程序，应该很具有权威性，想学J2EE和EJB的朋友不要错过了。
你一定会高兴地说，哈哈，原来成为Java高手就这么简单啊!记得Tomjava也曾碰到过一个项目经理，号称Java很简单，只要三个月就可以学会。其实说这种话的人就如当年小日本号称“三个月拿下中国”一样大言不惭。不是Tomjava泼你冷水，你现在只是学到了Java的骨架，却还没有学到Java的精髓。接下来你得研究设计模式了。设计模式是高级程序员真正掌握面向对象核心思想的必修课。设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧，让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。关于设计模式的资料，还是向大家推荐banq的网站http://www.jdon.com/ ，他把GOF的23种模式以通俗易懂的方式诠释出来，纯Java描述，真是经典中的经典。有时间再研究一下MVC结构（把Model-View-Control分离开的设计思想）吧，现在很流行的Structs就是它的一种实现方式，不过Structs用起来实在是很繁，我们只要学习其精髓即可，我们完全可以设计自己的MVC结构。然后你再研究一下软件Refactoring(重整)和极限XP编程，相信你又会上一个台阶。
做完这些，你不如整理一下你的Java代码，把那些经典的程序和常见的应用整理出来，再精心打造一番，提高其重用性和可扩展性。你再找几个志同道合的朋友成立一个工作室吧，你可以去承接一些项目做了，一开始可能有些困难，可是你有技术积累，又考虑周全，接下项目来可以迅速作完，相信大家以后都会来找你的，所以Money就哗啦啦的来了。。。。。。
当然你也可以参加一些开源项目，一方面可以提高自己，另一方面也是为中国软件事业做贡献嘛！开发者在互联网上用CVS合作开发，用QQ,MSN,E-mail讨论联系，天南海北的程序员分散在各地却同时开发同一个软件，是不是很有意思呢？
下面介绍两个好的开源项目网站：
湖北省软件公共开发平台http://gro.clinux.org/
共创联盟http://cosoft.org.cn/
哇，好高兴哦，我终于成为高手了！非也，非也。古人云：“识时务者为俊杰”。你知道计算机界现在的发展形势吗？你知道微软的.NET蓝图和SUN ONE计划之间的明争暗斗吗?你知道计算机技术将向何处发展吗?其实从各大计算机厂商最近的动作,都可以看出来“Web服务将是下一代互联网应用的制高点”，而微软的.NET蓝图和SUN ONE计划的斗争焦点，也就是Web服务。Web服务就是一个崭新的分布式计算模型，它是一系列标准的综合（XML,SOAP,UDDI,WSDL和WSFL等）。它使得不同语言编写的软件能够轻易的集成起来，使网络资源和Web站点变成一种服务而不是混乱的垃圾场。不远的将来，我们就可以在家里点击一下鼠标，就可以完成出门旅游的全部准备工作，包括定飞机票，定旅游线路，定好房间等。请注意，这所有的一切都是Web站点间自动完成的，再也不用象现在一样，表面上是电子商务，实际上很多环节都是人工操作。也许你会觉得这是天方夜谈，不过就近的说，你也很有可能承接一个项目，要集成两个企业的ERP系统。很有可能上游企业的系统是用Dephi编的，而下游企业的系统是用Java编的。你说你是Java高手，大家都看者你怎么做呢。所以啊，你还得学习新技术，如Web服务，而且你Dephi也要懂一点吧（Dephi6现在已经提供Web服务的控件了）。 你编的Java系统，可能要和.NET集成，所以你.NET要懂一点吧？到最后，你可能发现你已经成为Java高手了，但很多时间却在搞别的技术。太极张三丰里说，最厉害的招式就是没有招式，可能就是这个道理吧！
因为刚刚兴起，所以网上Web服务的资料不是很多，我还是给大家推荐几个网站吧：
中国UDDI技术联盟http://www.uddi-china.org/
CSDN的柴晓路专栏http://www.csdn.net/develop/author/ColumnAuthor/fennivel/ （注：柴晓路也是互联网上一个有名的人物，他发表过很多关于Web服务的文章，还出了一书，应该称的上是中国Web服务技术的先行者）
IBM的开发者网络的XML&Web Service专栏:
http://www-900.ibm.com/developerWorks/cn/xml/index.shtml?csdn IBM可是Web服务的力推者
呜…你费劲千心万苦，总算成为Java高手了，怎叫人不由喜极而泣呢！是啊，真不容易，真不简单，真叫人感动啊！那么打个电话告诉我吧，什么？我的电话号码是多少？昏到，你打电话问不就知道了吗，真是的……
author: tomjava
作者：robbin
网址：http://hibernate.fankai.com/
Java Learning Path （一）、工具篇
一、 JDK (Java Development Kit)
JDK是整个Java的核心，包括了Java运行环境（Java Runtime Envirnment），一堆Java工具和Java基础的类库(rt.jar)。不论什么Java应用服务器实质都是内置了某个版本的JDK。因此掌握JDK是学好Java的第一步。最主流的JDK是Sun公司发布的JDK，除了Sun之外，还有很多公司和组织都开发了自己的JDK，例如IBM公司开发的JDK，BEA公司的Jrocket，还有GNU组织开发的JDK等等。其中IBM的JDK包含的JVM（Java Virtual Machine）运行效率要比Sun JDK包含的JVM高出许多。而专门运行在x86平台的Jrocket在服务端运行效率也要比Sun JDK好很多。但不管怎么说，我们还是需要先把Sun JDK掌握好。
1、 JDK的下载和安装
JDK又叫做J2SE（Java2 SDK Standard Edition），可以从Sun的Java网站上下载到，http://java.sun.com/j2se/downloads.html ，JDK当前最新的版本是J2SDK1.4.2，建议下载该版本的JDK，下载页面在这里：http://java.sun.com/j2se/1.4.2/download.html。
下载好的JDK是一个可执行安装程序，默认安装完毕后会在C:\Program Files\Java\目录下安装一套JRE（供浏览器来使用），在C:\j2sdk1.4.2下安装一套JDK（也包括一套JRE）。然后我们需要在环境变量PATH的最前面增加java的路径C:\j2sdk1.4.2\bin。这样JDK就安装好了。
2、 JDK的命令工具
JDK的最重要命令行工具：
java： 启动JVM执行class
javac： Java编译器
jar： Java打包工具
javadoc： Java文档生成器
这些命令行必须要非常非常熟悉，对于每个参数都要很精通才行。对于这些命令的学习，JDK Documentation上有详细的文档。
二、 JDK Documentation
Documentation在JDK的下载页面也有下载连接，建议同时下载Documentation。Documentation是最最重要的编程手册，涵盖了整个Java所有方面的内容的描述。可以这样说，学习Java编程，大部分时间都是花在看这个Documentation上面的。我是随身携带的，写Java代码的时候，随时查看，须臾不离手。
三、 应用服务器(App Server)
App Server是运行Java企业组件的平台，构成了应用软件的主要运行环境。当前主流的App Server是BEA公司的Weblogic Server和IBM公司的Websphere以及免费的Jboss，选择其中一个进行学习就可以了，个人推荐Weblogic，因为它的体系结构更加干净，开发和部署更加方便，是Java企业软件开发人员首选的开发平台。下面简要介绍几种常用的App Server：
1、 Tomcat
Tomcat严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，数据库连接池，用户事务处理等等。Tomcat被非常广泛的应用在中小规模的Java Web应用中，因此本文做一点下载、安装和配置Tomcat的介绍：
Tomcat是Apache组织下Jakarta项目下的一个子项目，它的主网站是：http://jakarta.apache.org/tomcat/ ，Tomcat最新版本是Tomcat4.1.27，软件下载的连接是：http://www.apache.org/dist/jakarta/tomcat-4/binaries/ 。
下载Tomcat既可以直接下载zip包，也可以下载exe安装包（个人建议zip更干净些），不管哪种情况，下载完毕安装好以后（zip直接解压缩就可以了）。需要设置两个环境变量：
JAVA_HOME=C:\j2sdk1.4.2
CATALINA_HOME=D:\tomcat4 (你的Tomcat安装目录)
这样就安装好了，启动Tomcat运行CATALINA_HOME\bin\startup.bat，关闭Tomcat运行shutdown.bat脚本。Tomcat启动以后，默认使用8080端口，因此可以用浏览器访问http://localhost:8080来测试Tomcat是否正常启动。
Tomcat提供了两个Web界面的管理工具，URL分别是：
http://localhost:8080/admin/index.jsp
http://localhost:8080/manager/html
在启用这两个管理工具之前，先需要手工配置一下管理员用户和口令。用一个文本工具打开CATALINA_HOME\conf\tomcat-users.xml这个文件，加入如下几行：
<role rolename="manager"/>
<role rolename="admin"/>
<user username="robbin" password="12345678" roles="admin,manager,tomcat"/>
这样用户“robbin”就具备了超级管理员权限。重新启动Tomcat以后，你就可以使用该用户来登陆如上的两个管理工具，通过Web方式进行Tomcat的配置和管理了。
2、 BEA Weblogic
Weblogic可以到BEA的网站上免费注册之后下载到最新的Weblogic8.1企业版，License可以免费使用1年时间，其实这已经完全足够了。Weblogic的下载连接：http://commerce.bea.com/index.jsp，…/edocs.bea.com/ 。
3、 IBM Webshpere
Websphere同样可以下载到免费的试用版本，到IBM的developerWorks网站可以看到Websphere试用产品的下载和相关的Websphere的资料，developerWorks中文网站的连接是：http://www-900.ibm.com/developerWorks/cn/wsdd/ ，Websphere的下载连接：http://www7b.software.ibm.com/wsdd/…WASsupport.html 。
4、 Jboss
Jboss是免费开源的App Server，可以免费的从Jboss网站下载：http://www.jboss.org/index.html，然…n.com/idea.html
四、 Java应用的运行环境
Java的应用可以简单分为以下几个方面：
1、 Java的桌面应用
桌面应用一般仅仅需要JRE的支持就足够了。
2、 Java Web应用
Java的Web应用至少需要安装JDK和一个web容器（例如Tomcat），以及一个多用户数据库，Web应用至少分为三层：
Browser层：浏览器显示用户页面
Web层：运行Servlet/JSP
DB层：后端数据库，向Java程序提供数据访问服务
3、 Java企业级应用
企业级应用比较复杂，可以扩展到n层，最简单情况会分为4层：
Browser层：浏览器显示用户页面
Client层：Java客户端图形程序（或者嵌入式设备的程序）直接和Web层或者EJB层交互
Web层：运行Servlet/JSP
EJB层：运行EJB，完成业务逻辑运算
DB层：后端数据库，向Java程序提供数据访问服务
4、 Java嵌入式应用
Java嵌入式应用是一个方兴未艾的领域，从事嵌入式开发，需要从Sun下载J2ME开发包，J2ME包含了嵌入式设备专用虚拟机KVM，和普通的JDK中包含的JVM有所不同。另外还需要到特定的嵌入式厂商那里下载模拟器。
Java Learning Path（二）、书籍篇
学习一门新的知识，不可能指望只看一本，或者两本书就能够完全掌握。需要有一个循序渐进的阅读过程。我推荐Oreilly出版的Java系列书籍。
在这里我只想补充一点看法，很多人学习Java是从《Thinking in Java》这本书入手的，但是我认为这本书是不适合初学者的。我认为正确的使用这本书的方法应该是作为辅助的读物。《Thinking in Java》并不是在完整的介绍Java的整个体系，而是一种跳跃式的写作方法，是一种类似tips的方法来对Java很多知识点进行了深入的分析和解释。
对于初学者来说，最好是找一本Java入门的书籍，但是比较完整的循序的介绍Java的语法，面向对象的特性，核心类库等等，在看这本书的同时，可以同步来看《Thinking in Java》，来加深对Java的理解和原理的运用，同时又可以完整的了解Java的整个体系。
对于Java的入门书籍，蔡学镛推荐的是Oreilly的《Exploring Java, 2nd Edition》 或者《Java in a Nutshell,2nd Edition（针对C++背景）》，我并没有看过这两本书。其实我觉得电子工业出版社的《Java 2编程详解》或者《Java 2从入门到精通》就很不错。
在所有的Java书籍当中，其实最最有用的，并不是O’reilly的 Java Serials，真正最最有用处是JDK的Documentation！几乎你想获得的所有的知识在Documentation里面全部都有，其中最主要的部分当然是Java基础类库的API文档，是按照package来组织的，对于每一个class都有详细的解释，它的继承关系，是否实现了某个接口，通常用在哪些场合，还可以查到它所有的public的属性和方法，每个属性的解释，意义，每个方法的用途，调用的参数，参数的意义，返回值的类型，以及方法可能抛出的异常等等。可以这样来说，所有关于Java编程方面的书籍其实都不过是在用比较通俗易懂的语言，和良好的组织方式来介绍Documentation里面的某个package里面包含的一些类的用法而已。所以万变不离其宗，如果你有足够的能力来直接通过Documentation来学习Java的类库，那么基本上就不需要看其他的书籍了。除此之外，Documentation也是编程必备的手册，我的桌面上有三个Documentation的快捷方式，分别是J2SDK1.4.1的Documentation，Servlet2.3的Documentation和J2SDKEE1.3.1的Documentation。有了这个三个Documentation，什么其他的书籍都不需要了。
对于Java Web 编程来说，最核心的是要熟悉和掌握HTTP协议，这个就和Java无关了，在熟悉HTTP协议之后，就需要熟悉Java的实现HTTP协议的类库，也就是Servlet API，所以最重要的东西就是Servlet API。当然对于初学者而言，直接通过Servlet API来学习Web编程有很大的难度，我推荐O’reilly的《Java Server Pages 》这本书来学习Web 编程。
EJB的书籍当中，《Enterprise JavaBeans, 2nd Edition》是一本很不错的书， EJB的学习门槛是比较高，入门很难，但是这本书完全降低了学习的难度，特别重要的一点是，EJB的学习需要结合一种App Server的具体实现，所以在学习EJB的同时，必须同步的学习某种App Server，而这本书相关的出了三本书，分别是Weblogic6.1，Websphere4.0和JBoss3.0上面部署书中例子的实做。真是既有理论，又有实践。在学习EJB的同时，可以边看边做，EJB的学习会变得很轻松。
但是这本书也有一个问题，就是版本比较旧，主要讲EJB1.1规范和部分EJB2.0的规范。而Ed Roman写的《Mastering EJB 2.0》这本书完全是根据EJB2.0规范写的，深入浅出，覆盖了EJB编程的各个方面，并且还有很多编程经验tips，也是学习EJB非常推荐的书籍之一。
如果是结合Weblogic来学习J2EE的话，《J2EE应用与BEA Weblogic Server》绝对是首选读物，虽然是讲述的Weblogic6.0，仍然值得购买，这本书是BEA官方推荐的教材，作者也是BEA公司的工程师。现在中文版已经随处可见了。这本书结合Weblogic介绍了J2EE各个方面的技术在Weblogic平台上的开发和部署，实践指导意义非常强。
在掌握了Java平台基础知识和J2EE方面的知识以后，更进一步的是学习如何运用OO的方法进行软件的设计，那么就一定要学习“设计模式”。Sun公司出版了一本《J2EE核心模式》，是每个开发Java企业平台软件的架构师必备的书籍。这本书全面的介绍了J2EE体系架构的各种设计模式，是设计师的必读书籍。
Java Learning Path（三）过程篇
每个人的学习方法是不同的，一个人的方法不见得适合另一个人，我只能是谈自己的学习方法。因为我学习Java是完全自学的，从来没有问过别人，所以学习的过程基本上完全是自己摸索出来的。我也不知道这种方法是否是比较好的方法，只能给大家提供一点参考了。
学习Java的第一步是安装好JDK，写一个Hello World， 其实JDK的学习没有那么简单，关于JDK有两个问题是很容易一直困扰Java程序员的地方：一个是CLASSPATH的问题，其实从原理上来说，是要搞清楚JRE的ClassLoader是如何加载Class的；另一个问题是package和import问题，如何来寻找类的路径问题。把这两个问题摸索清楚了，就扫除了学习Java和使用JDK的最大障碍。推荐看一下王森的《Java深度历险》，对这两个问题进行了深入的探讨。
第二步是学习Java的语法。Java的语法是类C++的，基本上主流的编程语言不是类C，就是类C++的，没有什么新东西，所以语法的学习，大概就是半天的时间足够了。唯一需要注意的是有几个不容易搞清楚的关键字的用法，public，protected，private，static，什么时候用，为什么要用，怎么用，这可能需要有人来指点一下，我当初是完全自己琢磨出来的，花了很久的时间。不过后来我看到《Thinking in Java》这本书上面是讲了这些概念的。
第三步是学习Java的面向对象的编程语言的特性的地方。比如继承，构造器，抽象类，接口，方法的多态，重载，覆盖，Java的异常处理机制。对于一个没有面向对象语言背景的人来说，我觉得这个过程需要花很长很长时间，因为学习Java之前没有C++的经验，只有C的经验，我是大概花了一个月左右吧，才彻底把这些概念都搞清楚，把书上面的例子反复的揣摩，修改，尝试，把那几章内容反复的看过来，看过去，看了不下5遍，才彻底领悟了。不过我想如果有C++经验的话，应该一两天时间足够了。那么在这个过程中，可以多看看《Thinking in Java》这本书，对面向对象的讲解非常透彻。可惜的是我学习的时候，并没有看到这本书，所以自己花了大量的时间，通过自己的尝试和揣摩来学会的。
第四步就是开始熟悉Java的类库。Java的基础类库其实就是JDK安装目录下面jre\lib\rt.jar这个包。学习基础类库就是学习rt.jar。基础类库里面的类非常非常多。据说有3000多个，我没有统计过。但是真正对于我们来说最核心的只有4个，分别是
java.lang.*;
java.io.*;
java.util.*;
java.sql.*;
这四个包的学习，每个包的学习都可以写成一本厚厚的教材，而O’reilly也确实是这样做的。我觉得如果时间比较紧，是不可能通过读四本书来学习。我觉得比较好的学习方法是这样的：
首先要通读整个package的框架，了解整个package的class，interface，exception的构成，最好是能够找到介绍整个包框架的文章。这些专门介绍包的书籍的前几章应该就是这些总体的框架内容介绍。
对包整体框架的把握并不是要熟悉每个类的用法，记住它有哪些属性，方法。想记也记不住的。而是要知道包有哪些方面的类构成的，这些类的用途是什么，最核心的几个类分别是完成什么功能的。我在给人培训的时候一般是一次课讲一个包，所以不可能详细的介绍每个类的用法，但是我反复强调，我给你们讲这些包的不是要告诉你们类的方法是怎么调用的，也不要求你们记住类的方法调用，而是要你们了解，Java给我们提供了哪些类，每个类是用在什么场合，当我遇到问题的时候，我知道哪个类，或者哪几个类的组合可以解决我的问题，That’all！，当我们具体写程序的时候，只要你知道该用哪个类来完成你的工作就足够了。编码的时候，具体的方法调用，是边写代码，边查Documentation，所有的东西都在Documentation里面，不要求你一定记住，实际你也记不住3000多个类的总共将近10万个方法调用。所以对每个包的总体框架的把握就变得极为重要。
第五步，通过上面的学习，如果学的比较扎实的话，就打好了Java的基础了，剩下要做的工作是扫清Documentation里面除了上面4个包之外的其他一些比较有用处的类。相信进展到这一步，Java的自学能力已经被培养出来了，可以到了直接学习Documentation的水平了。除了要做GUI编程之外，JDK里面其他会有用处的包是这些：
java.text.*;
java.net.*;
javax.naming.*;
这些包里面真正用的比较多的类其实很少，只有几个，所以不需要花很多时间。
第六步，Java Web 编程
Web编程的核心是HTTP协议，HTTP协议和Java无关，如果不熟悉HTTP协议的话，虽然也可以学好Servlet/JSP编程，但是达不到举一反三，一通百通的境界。所以HTTP协议的学习是必备的。如果熟悉了HTTP协议的话，又有了Java编程的良好的基础，学习Servlet/JSP简直易如反掌，我学习Servlet/JSP就用了不到一周的时间，然后就开始用JSP来做项目了。
在Servlet/JSP的学习中，重头仍然是Servlet Documentation。Servlet API最常用的类很少，花比较少的时间就可以掌握了。把这些类都看一遍，多写几个例子试试。Servlet/JSP编程本质就是在反复调用这些类来通过HTTP协议在Web Server和Brower之间交谈。另外对JSP，还需要熟悉几个常用JSP的标记，具体的写法记不住的话，临时查就是了。
此外Java Web编程学习的重点要放在Web Application的设计模式上，如何进行业务逻辑的分析，并且进行合理的设计，按照MVC设计模式的要求，运用Servlet和JSP分别完成不同的逻辑层，掌握如何在Servlet和JSP之间进行流程的控制和数据的共享，以及Web Application应该如何配置和部署。
第七步，J2EE编程
以上的学习过程如果是比较顺利的话，进行到这一步，难度又陡然提高。因为上面的知识内容都是只涉及一个方面，而像EJB，JMS，JTA等核心的J2EE规范往往是几种Java技术的综合运用的结晶，所以掌握起来难度比较大。
首先一定要学习好JNDI，JNDI是App Server定位服务器资源（EJB组件，Datasouce，JMS）查找方法，如果对JNDI不熟悉的话，EJB，JMS这些东西几乎学不下去。JNDI其实就是javax.naming.*这个包，运用起来很简单。难点在于服务器资源文件的配置。对于服务器资源文件的配置，就需要看看专门的文档规范了，比如web.xml的写法，ejb-jar.xml的写法等等。针对每种不同的App Server，还有自己的服务资源配置文件，也是需要熟悉的。
然后可以学习JTA，主要是要理解JTA对于事务的控制的方法，以及该在什么场合使用JTA。这里可以简单的举个例子，我们知道一般情况可以对于一个数据库连接进行事务控制(conn.setAutoCommit(false),….,conn.commit())，做为一个原子操作，但是假设我的业务需求是要把对两个不同数据库的操作做为一个原子操作，你能做的到吗？这时候只能用JTA了。假设操作过程是先往A数据库插一条记录，然后删除B数据库另一个记录，我们自己写代码是控制不了把整个操作做为一个原子操作的。用JTA的话，由App Server来完成控制。
在学习EJB之前要学习对象序列化和RMI，RMI是EJB的基础。接着学习JMS和EJB，对于EJB来说，最关键是要理解EJB是如何通过RMI来实现对远端对象的调用的，以及在什么情况下要用到EJB。
在学习完EJB，JMS这些东西之后，你可能会意识到要急不可待学习两个领域的知识，一个是UML，另一个是Design Pattern。Java企业软件的设计非常重视框架(Framework)的设计，一个好的软件框架是软件开发成功的必要条件。在这个时候，应该开始把学习的重点放在设计模式和框架的学习上，通过学习和实际的编程经验来掌握EJB的设计模式和J2EE的核心模式。
J2EE规范里面，除了EJB，JMS，JTA，Servlet/JSP，JDBC之外还有很多很多的企业技术，这里不一一进行介绍了。
另外还有一个最新领域Web Services。Web Services也完全没有任何新东西，它像是一种黏合剂，可以把不同的服务统一起来提供一个统一的调用接口，作为使用者来说，我只要获得服务提供者给我的WSDL（对服务的描述），就够了，我完全不知道服务器提供者提供的服务究竟是EJB组件，还是.Net组件，还是什么CORBA组件，还是其他的什么实现，我也不需要知道。Web Services最伟大的地方就在于通过统一的服务提供方式和调用方式，实现了整个Internet服务的共享，是一个非常令人激动的技术领域。Web Services好像目前还没有什么很好的书籍，但是可以通过在网络上面查资料的方式来学习。
Java Learning Path（四） 方法篇
Java作为一门编程语言，最好的学习方法就是写代码。当你学习一个类以后，你就可以自己写个简单的例子程序来运行一下，看看有什么结果，然后再多调用几个类的方法，看看运行结果，这样非常直观的把类给学会了，而且记忆非常深刻。然后不应该满足把代码调通，你应该想想看如果我不这样写，换个方式，再试试行不行。记得哪个高人说过学习编程就是个破坏的过程，把书上的例子，自己学习Documentation编写的例子在运行通过以后，不断的尝试着用不同的方法实现，不断的尝试破坏代码的结构，看看它会有什么结果。通过这样的方式，你会很彻底的很精通的掌握Java。
举个例子，我们都编过Hello World
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
很多初学者不是很理解为什么main方法一定要这样来定义public static void main(String[] args)，能不能不这样写？包括我刚学习Java的时候也有这样的疑问。想知道答案吗？很简单，你把main改个名字运行一下，看看报什么错误，然后根据出错信息进行分析；把main的public取掉，在试试看，报什么错误；static去掉还能不能运行；不知道main方法是否一定要传一个String[]数组的，把String[]改掉，改成int[]，或者String试试看；不知道是否必须写args参数名称的，也可以把args改成别的名字，看看运行结果如何。
我当初学习Java的时候就是这样做的，把Hello World程序反复改了七八次，不断运行，分析运行结果，最后就彻底明白为什么了main方法是这样定义的了。
此外，我对于staic，public，private，Exception，try{ }catch {}finally{}等等等等一开始都不是很懂，都是把参考书上面的例子运行成功，然后就开始破坏它，不断的根据自己心里面的疑问来重新改写程序，看看能不能运行，运行出来是个什么样子，是否可以得到预期的结果。这样虽然比较费时间，不过一个例子程序这样反复破坏几次之后。我就对这个相关的知识彻底学通了。有时候甚至故意写一些错误的代码来运行，看看能否得到预期的运行错误。这样对于编程的掌握是及其深刻的。
其中特别值得一提的是JDK有一个非常棒的调试功能，-verbose
java –verbose
javac –verbose 以及其它很多JDK工具都有这个选项
-verbose 可以显示在命令执行的过程中，JVM都依次加载哪里Class，通过这些宝贵的调试信息，可以帮助我们分析出JVM在执行的过程中都干了些什么。
另外，自己在学习过程中，写的很多的这种破坏例程，应该有意识的分门别类的保存下来，在工作中积累的典型例程也应该定期整理，日积月累，自己就有了一个代码库了。遇到类似的问题，到代码库里面 Copy & Paste ，Search & Replace，就好了，极大提高了开发速度。最理想的情况是把一些通用的例程自己再抽象一层，形成一个通用的类库，封装好。那么可复用性就更强了。
所以我觉得其实不是特别需要例程的，自己写的破坏例程就是最好的例子，如果你实在对自己写的代码不放心的话，我强烈推荐你看看JDK基础类库的Java源代码。在JDK安装目录下面会有一个src.zip，解开来就可以完整的看到整个JDK基础类库，也就是rt.jar的Java源代码，你可以参考一下Sun是怎么写Java程序的，规范是什么样子的。我自己在学习Java的类库的时候，当有些地方理解的不是很清楚的时候，或者想更加清晰的理解运作的细节的时候，往往会打开相应的类的源代码，通过看源代码，所有的问题都会一扫而空。
Java Learning Path（五）资源篇
1、 http://java.sun.com/ (英文)
Sun的Java网站，是一个应该经常去看的地方。不用多说。
2、http://www-900.ibm.com/developerWorks/cn/
IBM的developerWorks网站，英语好的直接去英文主站点看。这里不但是一个极好的面向对象的分析设计网站，也是Web Services，Java，Linux极好的网站。强烈推荐！！！
3、http://www.javaworld.com/ (英文)
关于Java很多新技术的讨论和新闻。想多了解Java的方方面面的应用，这里比较好。
4、http://dev2dev.bea.com.cn/index.jsp
BEA的开发者园地，BEA作为最重要的App Server厂商，有很多独到的技术，在Weblogic上做开发的朋友不容错过。
5、http://www.huihoo.com/
灰狐动力网站，一个专业的中间件网站，虽然不是专业的Java网站，但是在J2EE企业应用技术方面有深厚的造诣。
6、http://www.theserverside.com/home/ (英文)
TheServerSide是一个著名的专门面向Java Server端应用的网站。
7、http://www.javaresearch.org/
Java研究组织，有很多优秀的Java方面的文章和教程，特别是在JDO方面的文章比较丰富。
8、http://www.cnjsp.org/
JSP技术网站，有相当多的Java方面的文章和资源。
9、http://www.jdon.com/
Jdon论坛，是一个个人性质的中文J2EE专业技术论坛，在众多的Java的中文论坛中，Jdon一个是技术含量非常高，帖子质量非常好的论坛。
10、http://sourceforge.net/
SourgeForge是一个开放源代码软件的大本营，其中也有非常非常丰富的Java的开放源代码的著名的软件。