Spring相关的外文文献和翻译(毕设论文必备)

附录1 外文原文

Introducing the Spring Framework

The Spring Framework: a popular open source application framework that

addresses many of the issues outlined in this book. This chapter will introduce the

basic ideas of Spring and dis-cuss the central “bean factory” lightweight

Inversion-of-Control (IoC) container in detail.

Spring makes it particularly easy to implement lightweight, yet extensible, J2EE

archi-tectures. It provides an out-of-the-box implementation of the fundamental

architectural building blocks we recommend. Spring provides a consistent way of

structuring your applications, and provides numerous middle tier features that can

make J2EE development significantly easier and more flexible than in traditional

approaches.

The basic motivations for Spring are:

To address areas not well served by other frameworks. There are numerous good

solutions to specific areas of J2EE infrastructure: web frameworks, persistence

solutions, remoting tools, and so on. However, integrating these tools into a

comprehensive architecture can involve significant effort, and can become a burden.

Spring aims to provide an end-to-end solution, integrating spe-cialized frameworks

into a coherent overall infrastructure. Spring also addresses some areas that other

frameworks don’t. For example, few frameworks address generic transaction

management, data access object implementation, and gluing all those things together

into an application, while still allowing for best-of-breed choice in each area. Hence

we term Spring an application framework, rather than a web framework, IoC or AOP

framework, or even middle tier framework.

To allow for easy adoption. A framework should be cleanly layered, allowing the

use of indi-vidual features without imposing a whole world view on the application.

Many Spring features, such as the JDBC abstraction layer or Hibernate integration,

can be used in a library style or as part of the Spring end-to-end solution.

word精品文档,可编辑,欢迎下载

To deliver ease of use. As we’ve noted, J2EE out of the box is relatively hard to

use to solve many common problems. A good infrastructure framework should make

simple tasks simple to achieve, without forcing tradeoffs for future complex

requirements (like distributed transactions) on the application developer. It should

allow developers to leverage J2EE services such as JTA where appropriate, but to

avoid dependence on them in cases when they are unnecessarily complex.

To make it easier to apply best practices. Spring aims to reduce the cost of

adhering to best practices such as programming to interfaces, rather than classes,

almost to zero. However, it leaves the choice of architectural style to the developer.

Non-invasiveness. Application objects should have minimal dependence on the

framework. If leveraging a specific Spring feature, an object should depend only on

that particular feature, whether by implementing a callback interface or using the

framework as a class library. IoC and AOP are the key enabling technologies for

avoiding framework dependence.

Consistent configuration. A good infrastructure framework should keep

application configuration flexible and consistent, avoiding the need for custom

singletons and factories. A single style should be applicable to all configuration needs,

from the middle tier to web controllers.

Ease of testing. Testing either whole applications or individual application

classes in unit tests should be as easy as possible. Replacing resources or application

objects with mock objects should be straightforward.

To allow for extensibility. Because Spring is itself based on interfaces, rather

than classes, it is easy to extend or customize it. Many Spring components use

strategy interfaces, allowing easy customization.

A Layered Application Framework

Chapter 6 introduced the Spring Framework as a lightweight container,

competing with IoC containers such as PicoContainer. While the Spring lightweight

container for JavaBeans is a core concept, this is just the foundation for a solution for

word精品文档,可编辑,欢迎下载

all middleware layers.

Basic Building Blocks

pring is a full-featured application framework that can be leveraged at many

levels. It consists of multi-ple sub-frameworks that are fairly independent but still

integrate closely into a one-stop shop, if desired. The key areas are:

Bean factory. The Spring lightweight IoC container, capable of configuring and

wiring up Java-Beans and most plain Java objects, removing the need for custom

singletons and ad hoc configura-tion. Various out-of-the-box implementations include

an XML-based bean factory. The lightweight IoC container and its Dependency

Injection capabilities will be the main focus of this chapter.

Application context. A Spring application context extends the bean factory

concept by adding support for message sources and resource loading, and providing

hooks into existing environ-ments. Various out-of-the-box implementations include

standalone application contexts and an XML-based web application context.

AOP framework. The Spring AOP framework provides AOP support for method

interception on any class managed by a Spring lightweight container. It supports easy

proxying of beans in a bean factory, seamlessly weaving in interceptors and other

advice at runtime. Chapter 8 dis-cusses the Spring AOP framework in detail. The

main use of the Spring AOP framework is to provide declarative enterprise services

for POJOs.

Auto-proxying. Spring provides a higher level of abstraction over the AOP

framework and low-level services, which offers similar ease-of-use to .NET within a

J2EE context. In particular, the provision of declarative enterprise services can be

driven by source-level metadata.

Transaction management. Spring provides a generic transaction management

infrastructure, with pluggable transaction strategies (such as JTA and JDBC) and

various means for demarcat-ing transactions in applications. Chapter 9 discusses its

rationale and the power and flexibility that it offers.

DAO abstraction. Spring defines a set of generic data access exceptions that can

word精品文档,可编辑,欢迎下载

be used for cre-ating generic DAO interfaces that throw meaningful exceptions

independent of the underlying persistence mechanism. Chapter 10 illustrates the

Spring support for DAOs in more detail, examining JDBC, JDO, and Hibernate as

implementation strategies.

JDBC support. Spring offers two levels of JDBC abstraction that significantly

ease the effort of writing JDBC-based DAOs: the

package (a template/

callback approach) and the package (modeling

RDBMS operations as reusable objects). Using the Spring JDBC packages can deliver

much greater pro-ductivity and eliminate the potential for common errors such as

leaked connections, compared with direct use of JDBC. The Spring JDBC abstraction

integrates with the transaction and DAO abstractions.

Integration with O/R mapping tools. Spring provides support classes for O/R

Mapping tools like Hibernate, JDO, and iBATIS Database Layer to simplify resource

setup, acquisition, and release, and to integrate with the overall transaction and DAO

abstractions. These integration packages allow applications to dispense with custom

ThreadLocal sessions and native transac-tion handling, regardless of the underlying

O/R mapping approach they work with.

Web MVC framework. Spring provides a clean implementation of web MVC,

consistent with the JavaBean configuration approach. The Spring web framework

enables web controllers to be configured within an IoC container, eliminating the need

to write any custom code to access business layer services. It provides a generic

DispatcherServlet and out-of-the-box controller classes for command and form

handling. Request-to-controller mapping, view resolution, locale resolution and other

important services are all pluggable, making the framework highly extensi-ble. The

web framework is designed to work not only with JSP, but with any view technology,

such as Velocity—without the need for additional bridges. Chapter 13 discusses web

tier design and the Spring web MVC framework in detail.

Remoting support. Spring provides a thin abstraction layer for accessing remote

word精品文档,可编辑,欢迎下载

services without hard-coded lookups, and for exposing Spring-managed application

beans as remote services. Out-of-the-box support is included for RMI, Caucho’s

Hessian and Burlap web service protocols, and WSDL Web Services via JAX-RPC.

Chapter 11 discusses lightweight remoting.

While Spring addresses areas as diverse as transaction management and web

MVC, it uses a consistent approach everywhere. Once you have learned the basic

configuration style, you will be able to apply it in many areas. Resources, middle tier

objects, and web components are all set up using the same bean configuration

mechanism. You can combine your entire configuration in one single bean definition

file or split it by application modules or layers; the choice is up to you as the

application developer. There is no need for diverse configuration files in a variety of

formats, spread out across the application.

Spring on J2EE

Although many parts of Spring can be used in any kind of Java environment, it is

primarily a J2EE application framework. For example, there are convenience classes

for linking JNDI resources into a bean factory, such as JDBC DataSources and EJBs,

and integration with JTA for distributed transaction management. In most cases,

application objects do not need to work with J2EE APIs directly, improving

reusability and meaning that there is no need to write verbose, hard-to-test, JNDI

lookups.

Thus Spring allows application code to seamlessly integrate into a J2EE

environment without being unnecessarily tied to it. You can build upon J2EE services

where it makes sense for your application, and choose lighter-weight solutions if there

are no complex requirements. For example, you need to use JTA as transaction

strategy only if you face distributed transaction requirements. For a single database,

there are alternative strategies that do not depend on a J2EE container. Switching

between those transac-tion strategies is merely a matter of configuration; Spring’s

consistent abstraction avoids any need to change application code.

Spring offers support for accessing EJBs. This is an important feature (and

word精品文档,可编辑,欢迎下载

relevant even in a book on “J2EE without EJB”) because the use of dynamic proxies

as codeless client-side business delegates means that Spring can make using a local

stateless session EJB an implementation-level, rather than a fundamen-tal

architectural, choice. Thus if you want to use EJB, you can within a consistent

architecture; however, you do not need to make EJB the cornerstone of your

architecture. This Spring feature can make devel-oping EJB applications significantly

faster, because there is no need to write custom code in service loca-tors or business

delegates. Testing EJB client code is also much easier, because it only depends on the

EJB’s Business Methods interface (which is not EJB-specific), not on JNDI or the

EJB API.

Spring also provides support for implementing EJBs, in the form of convenience

superclasses for EJB implementation classes, which load a Spring lightweight

container based on an environment variable specified in the deployment

descriptor. This is a powerful and convenient way of imple-menting SLSBs or MDBs

that are facades for fine-grained POJOs: a best practice if you do choose to implement

an EJB application. Using this Spring feature does not conflict with EJB in any way—it merely simplifies following good practice.

Introducing the Spring Framework

The main aim of Spring is to make J2EE easier to use and promote good

programming practice. It does not reinvent the wheel; thus you’ll find no logging

packages in Spring, no connection pools, no distributed transaction coordinator. All

these features are provided by other open source projects—such as Jakarta Commons

Logging (which Spring uses for all its log output), Jakarta Commons DBCP (which

can be used as local DataSource), and ObjectWeb JOTM (which can be used as

transaction manager)—or by your J2EE application server. For the same reason,

Spring doesn’t provide an O/R mapping layer: There are good solutions for this

problem area, such as Hibernate and JDO.

Spring does aim to make existing technologies easier to use. For example,

although Spring is not in the business of low-level transaction coordination, it does

provide an abstraction layer over JTA or any other transaction strategy. Spring is also

word精品文档,可编辑,欢迎下载

popular as middle tier infrastructure for Hibernate, because it provides solutions to

many common issues like SessionFactory setup, ThreadLocal sessions, and exception

handling. With the Spring HibernateTemplate class, implementation methods of

Hibernate DAOs can be reduced to one-liners while properly participating in

transactions.

The Spring Framework does not aim to replace J2EE middle tier services as a

whole. It is an application framework that makes accessing low-level J2EE container

ser-vices easier. Furthermore, it offers lightweight alternatives for certain J2EE

services in some scenarios, such as a JDBC-based transaction strategy instead of JTA

when just working with a single database. Essentially, Spring enables you to write

appli-cations that scale down as well as up.

Spring for Web Applications

A typical usage of Spring in a J2EE environment is to serve as backbone for the

logical middle tier of a J2EE web application. Spring provides a web application

context concept, a powerful lightweight IoC container that seamlessly adapts to a web

environment: It can be accessed from any kind of web tier, whether Struts, WebWork,

Tapestry, JSF, Spring web MVC, or a custom solution.

The following code shows a typical example of such a web application context.

In a typical Spring web app, an file will reside in the

WEB-INF directory, containing bean defini-tions according to the “spring-beans”

DTD. In such a bean definition XML file, business objects and resources are defined,

for example, a “myDataSource” bean, a “myInventoryManager” bean, and a

“myProductManager” bean. Spring takes care of their configuration, their wiring up,

and their lifecycle.

ManagerDataSource”>

.

Driver

word精品文档,可编辑,欢迎下载

jdbc:mysql:myds

DefaultInventoryManager”>

DefaultProductManager”>

true

By default, all such beans have “singleton” scope: one instance per context.

The “myInventoryManager” bean will automatically be wired up with the defined

DataSource, while “myProductManager” will in turn receive a reference to the

“myInventoryManager” bean. Those objects (traditionally called “beans” in

Spring terminology) need to expose only the corresponding bean properties or

constructor arguments (as you’ll see later in this chapter); they do not have to perform

any custom lookups.

A root web application context will be loaded by a ContextLoaderListener that is

defined in as follows:

tLoaderListener

...

After initialization of the web app, the root web application context will be

word精品文档,可编辑,欢迎下载

available as a ServletContext attribute to the whole web application, in the usual

manner. It can be retrieved from there easily via fetching the corresponding attribute,

or via a convenience method in .

licationContextUtils. This means that the application context

will be available in any web resource with access to the ServletContext, like a Servlet,

Filter, JSP, or Struts Action, as follows:

WebApplicationContext wac = WebApplicationContextUtils.

getWebApplicationContext(servletContext);

The Spring web MVC framework allows web controllers to be defined as

JavaBeans in child application contexts, one per dispatcher servlet. Such controllers

can express dependencies on beans in the root application context via simple bean

references. Therefore, typical Spring web MVC applications never need to perform a

manual lookup of an application context or bean factory, or do any other form of

lookup.

Neither do other client objects that are managed by an application context

themselves: They can receive collaborating objects as bean references.

The Core Bean Factory

In the previous section, we have seen a typical usage of the Spring IoC container

in a web environment: The provided convenience classes allow for seamless

integration without having to worry about low-level container details. Nevertheless, it

does help to look at the inner workings to understand how Spring manages the

container. Therefore, we will now look at the Spring bean container in more detail,

starting at the lowest building block: the bean factory. Later, we’ll continue with

resource setup and details on the application context concept.

One of the main incentives for a lightweight container is to dispense with the

multitude of custom facto-ries and singletons often found in J2EE applications. The

Spring bean factory provides one consistent way to set up any number of application

objects, whether coarse-grained components or fine-grained busi-ness objects.

Applying reflection and Dependency Injection, the bean factory can host components

that do not need to be aware of Spring at all. Hence we call Spring a non-invasive

word精品文档,可编辑,欢迎下载

application framework.

Fundamental Interfaces

The fundamental lightweight container interface is

Factory. This is a simple interface, which is

easy to implement directly in the unlikely case that none of the implementations

provided with Spring suffices. The BeanFactory interface offers two getBean()

methods for looking up bean instances by String name, with the option to check for a

required type (and throw an exception if there is a type mismatch).

public interface BeanFactory {

Object getBean(String name) throws BeansException;

Object getBean(String name, Class requiredType) throws BeansException;

boolean containsBean(String name);

boolean isSingleton(String name) throws NoSuchBeanDefinitionException;

String[] getAliases(String name) throws NoSuchBeanDefinitionException;

}

The isSingleton() method allows calling code to check whether the specified

name represents a sin-gleton or prototype bean definition. In the case of a singleton

bean, all calls to the getBean() method will return the same object instance. In the

case of a prototype bean, each call to getBean() returns an inde-pendent object

instance, configured identically.

The getAliases() method will return alias names defined for the given bean name,

if any. This mecha-nism is used to provide more descriptive alternative names for

beans than are permitted in certain bean factory storage representations, such as XML

id attributes.

The methods in most BeanFactory implementations are aware of a hierarchy that

the implementation may be part of. If a bean is not found in the current factory, the

parent factory will be asked, up until the root factory. From the point of view of a

caller, all factories in such a hierarchy will appear to be merged into one. Bean

definitions in ancestor contexts are visible to descendant contexts, but not the reverse.

word精品文档,可编辑,欢迎下载

All exceptions thrown by the BeanFactory interface and sub-interfaces extend

framework. xception, and are unchecked. This reflects the fact

that low-level configuration prob-lems are not usually recoverable: Hence, application

developers can choose to write code to recover from such failures if they wish to, but

should not be forced to write code in the majority of cases where config-uration

failure is fatal.

Most implementations of the BeanFactory interface do not merely provide a

registry of objects by name; they provide rich support for configuring those objects

using IoC. For example, they manage dependen-cies between managed objects, as

well as simple properties. In the next section, we’ll look at how such configuration

can be expressed in a simple and intuitive XML structure.

The sub-interface leBeanFactory

supports listing beans in a factory. It provides methods to retrieve the number of beans

defined, the names of all beans, and the names of beans that are instances of a given

type:

public interface ListableBeanFactory extends BeanFactory {

int getBeanDefinitionCount();

String[] getBeanDefinitionNames();

String[] getBeanDefinitionNames(Class type);

boolean containsBeanDefinition(String name);

Map getBeansOfType(Class type, boolean includePrototypes,

boolean includeFactoryBeans) throws BeansException

}

The ability to obtain such information about the objects managed by a

ListableBeanFactory can be used to implement objects that work with a set of other

objects known only at runtime.

In contrast to the BeanFactory interface, the methods in ListableBeanFactory

apply to the current factory instance and do not take account of a hierarchy that the

factory may be part of. The ctoryUtils

class provides analogous methods that traverse an entire factory hierarchy.

word精品文档,可编辑,欢迎下载

There are various ways to leverage a Spring bean factory, ranging from simple

bean configuration to J2EE resource integration and AOP proxy generation. The bean

factory is the central, consistent way of setting up any kind of application objects in

Spring, whether DAOs, business objects, or web controllers. Note that application

objects seldom need to work with the BeanFactory interface directly, but are usu-ally

configured and wired by a factory without the need for any Spring-specific code.

For standalone usage, the Spring distribution provides a tiny file

that can be embed-ded in any kind of application. Its only third-party dependency

beyond J2SE 1.3 (plus JAXP for XML parsing) is the Jakarta Commons Logging API.

The bean factory is the core of Spring and the foundation for many other services

that the framework offers. Nevertheless, the bean factory can easily be used

stan-dalone if no other Spring services are required.

附录2 中文译文

Spring框架介绍

Spring框架：这是一个流行的开源应用框架，它可以解决很多问题。这里主要介绍Spring的基本概念，并详细介绍其中以“bean工厂”为核心的轻量级 word精品文档,可编辑,欢迎下载

控制反转（IoC）容器。

Spring让开发者更轻松的实现轻量级、可扩展的J2EE架构。对于我们推荐的架构模块，让Spring提供了即时可用的实现。此外，Spring还提供了同意的应用架构方式，以及大量的中间层功能模块，能大大简化了J2EE的开发，并且比传统的开发方式更加灵活。

第一章：Spring项目的出发点

1.1解决被其它框架忽略的部分

在J2EE的各个具体领域都有很多出色的解决方案----web框架、持久化方案、远程调用工具，凡此种种。然而，将这些工具整合成一个全面的架构却困难重重，甚至成为一种负担。Spring的目标就是提供一种贯穿始终的解决方案，将各种专用框架整合成一个连贯的整体架构。Spring还涉及到其它框架没有触及到的地方。例如，很少有框架提供普遍适用的事务管理或是数据库存储对象实现；即便各个领域都有很好的选择，也没有一个框架能够帮忙把所有这些东西整合到一个应用中去。因此，我们说Spring是一个应用框架，而不是web框架、IoC框架、AOP框架或者中间层框架什么的。

1.2易于选择

一个框架应该有清楚的层次划分，允许用户使用其中的单项功能，而不是把自己的整个世界观强加给用户。Spring中的许多特性---例如JDBC抽象层或者Hibernation集成----都可以作为一个库单独使用，当然也可以作为Spring整体方案的一个部分。

1.3易于使用

正如前面说过的，仅仅J2EE本身并不易用---很多常见的问题光靠J2EE都很难解决。一个好的基础框架首先应该让容易的任务容易完成，而不需要让应用开发人员现在就为将来的复杂需求（例如分布式事务）买单。框架应该帮助开发人员合理使用J2EE的服务（例如JTA），同时又避免造成对服务的依赖，从而减少不必要的复杂性。

1.4 鼓励最佳实现

Spring力求把遵循最佳实践--例如“针对接口编程”--的成本降低到最小。 word精品文档,可编辑,欢迎下载

另一方面，Spring又力求不强加任何架构风格，而是把选择的权利留给开发者。

1.5 非入侵性

一个好的基础设施框架应保持应用组态灵活和一致，避免自定义单身和工厂的需要。一个单一的风格应该是适用于所有配置的需要，从中间层的网络控制器。

1.6 统一配置

测试整个应用程序或单个应用程序类的单元测试应该尽可能的容易。模仿对象替换资源或应用程序的对象应该是简单的。

1.7 可扩展

由于Spring本身是基于接口的，而不是类，它是很容易扩展或定制。许多Spring组件使某种形式的Strategy模式，因此可以方便定制。

第二章：一个分层的应用框架

前面我们从轻量级容器（lightwight container）的角度介绍了Spring框架，并将其与别的IoC容器（例如PicoContainer) 作了比较。虽然为JavaBean设计的轻量级容器是Spring的核心概念，但这也只是所有中间层解决方案的基础而已。

2.1 基础构建模块

Spring是一个完整的应用框架，它可以在很懂应用层发挥作用。Spring由多个子框架组成，而且这些框架都是相对独立的。不过，只要你愿意，你就可以将它们无缝集成起来，成为一个全面的应用框架，下面讲解Spring框架的关键概念。

2.1.1 bean工厂

Spring轻量级IoC容器能够配置、装备JavaBean和大多数Java对象，使得开发者不必定制Singleton和自己的配置机制。Spring提供了多个“即拿即用”的bean工厂实现。其中包括一个基于XML的bean工厂。轻量级IoC容器和依赖注入（Dependency Injcction）将是本章节关注的内容。

2.1.2应用上下文

Spring应用程序上下文添加消息来源和资源加载支持扩展bean工厂的概念，并提供钩到现有的环境中。不同的盒子的实现包括独立的应用程序上下文和 word精品文档,可编辑,欢迎下载

基于Web的应用程序上下文的XML。

2.1.3 AOP框架

Spring的AOP框架提供的任何类的Spring轻量级容器管理方法拦截AOP支持。可以对轻量级容器管理的任何对象进行方法拦截。在bean工厂中，可以轻松的为JavaBean提供代理，从而在运行天衣无缝地将拦截器和其他的adcice整合进来。我们将在后面详细讨论Spring的AOP框架。Spring AOP的主要用途就是为了POJO提供声明性的企业级服务。

2.1.4 自动代理

Spring提供了一个更高的抽象层次的AOP框架和低水平的服务，同时也提供了很多基础性的服务，从而在J2EE环境中提供了类似于.NET的易用性--特别是，声明的企业提供的服务可以通过源代码级的元数据驱动的。

2.1.5 事务管理

Spring提供了一个通用的交易管理基础设施，可插拔的交易策略（例如JTA和JDBC）和不同的事务划分方式。后面会详细介绍Spring事务管理的基本原理，及其强大的威力和灵活性。

2.1.6 DAO的抽象

Spring定义一组通用的数据访问异常，在创建通用的DAO接口时可以用这些异常类型抛出有意义的异常信息，，独立于底层的存储机制。后面阐述了更多的细节讨论Spring对DAO的支持，以及针对JDBC JDO，Hibernate的不同实施策略。

2.1.7 JDBC的支持

Spring提供了两个层次的抽象，使得编写基于JDBC的DAO特别简单：包提供了基于模板、回调的JDBC用法，包则把关系数据库操作建模为可服用对象。比起直接使用JDBC，用Spring 的JDBC包可以提供更大的生产力和消除常见的错误，如泄漏等。Spring JDBC抽象层集成了事务抽象和DAO的抽象。

2.1.8 集成O/R映工具

Spring提供了多种O/R映射工具的支持，如Hibernate，JDO和ibatis数据库简化资源设置，采集，和释放，并且将O/R映射与整个事务和DAO抽象集成 word精品文档,可编辑,欢迎下载

起来。这些集成软件包允许应用程序分配自定义ThreadLocal会话和本地事务进行处理，不必考虑底层究竟采用哪种O/R映射工具。

2.1.9 web MVC框架

Spring提供了一个相当干净的Web MVC实现--同样使用了统一JavaBean配置方式。使用Spring web框架时，web控制器也可以在IoC容器中配置，从而不必为“访问业务层服务”额外编写代码。Spring还提供了通用的DispatcherServlet和“即拿急用”的控制器类。请求与控制器之间的映射方式、师徒的判断、本地化、以及其他重要服务都是可以插的，使得整个框架酷友更好的扩展性。Spring web框架设计不仅仅局限于JSP，还可以与其他的视图技术--例如Velocity--无缝的结合。

2.1.10 远程调用支持

Spring提供一种薄的抽象层用于访问远程服务，避免了在应用对象中硬编码对服务的查找。线成支持的远程调用方式包括RMI，Caucho的Hessian和Burlap Web服务的协议，和基于JAX-RPCWSDL的Web服务。

虽然Spring涉及了下至事务管理、上至web MVC的不同领域，它但它解决问题的方式却是一以贯之的。一旦你学会了基本的配置方式，你将能够应用在许多领域。资源，中间层对象，和Web组件都使用同一个bean配置机制的建立。你可以将你的整个配置在一个单一的bean定义文件或分裂，它的应用模块或层；选择是为应用程序开发人员到你。有没有需要在各种不同的格式，不同的配置文件，遍布的应用。

第三章：J2EE之上的Spring

虽然Spring的许多部分可用于任何Java环境，它主要是一个J2EE应用框架。例如，有链接到一个bean工厂的JNDI资源方便的类，如JDBC数据源和EJB和JTA，分布式事务管理一体化。在大多数情况下，应用程序对象不需要与j2ee

api直接，提高可重用性和意义，不需要写冗长，难以测试，JNDI查找。

因此，Spring允许应用程序代码的无缝集成到J2EE环境不被不必要地捆绑在一起。你可以建立在J2EE服务，让您的应用程序，如果没有复杂的要求选择重量轻的解决方案。例如，你需要使用JTA事务的策略，如果你面对分布式事务的要求。为一个单一的数据库，有不依赖于一个J2EE容器替代策略。这些交易 word精品文档,可编辑,欢迎下载

和策略之间的切换只是配置；春天的一致的抽象避免任何需要更改应用程序代码。

Spring访问EJB提供支持。这是一个重要的特征（甚至在“没有EJB的J2EE一本有关）因为动态使用代理作为客户端业务代表无代码意味着春天可以使用本地的无状态会话EJB的实现程度，而不是一个根本的建筑，选择。因此，如果你想使用EJB，您可以在一个一致的架构；然而，你不需要让你的架构的基石，EJB。今年春天功能可以使开发EJB应用程序更快，因为不需要编写自定义代码在服务中心职责范围或业务代表。测试EJB客户端代码也容易得多，因为它不仅取决于EJB的业务方法接口（这是不特定的，不是在EJB）或EJB JNDI API。

Spring也提供了实现EJB的支持，在方便的超类EJB实现类的形式，其中负载基于部署描述符指定的环境变量的Spring轻量级容器。这是一个强大的和方便的方式实现SLSBs或MDBS是细粒度的POJO立面：最佳实践，如果你选择实现EJB应用。Spring的这些特性和EJB毫无冲突，因为它只是遵循了公认的最佳实践而已。

Spring的主要目的是使J2EE更容易使用和促进良好的编程实践。Spring不重新发明轮子，这样你会在spring找不到登录包，连接池，分布式事务协调器。这些特征是由其他的开源项目，如Jakarta Commons测井提供（Spring使用其所有的日志输出），Jakarta Commons DBCP（可作为局部数据源）和ObjectWeb

JOTM（可作为事务管理器）或通过你的J2EE应用服务器。出于同样的原因，Spring不提供O/R映射层：有良好的解决问题的方法，如Hibernate，JDO。

Spring的目标是使现有的技术更容易使用。例如，虽然Spring不是低级事务协调业务，它提供了在jta或者任何交易策略的一个抽象层。Spring为Hibernate提供的中间层的基础设施也很受欢迎，因为它提供了像SessionFactory的设置，许多常见问题可以解决，ThreadLocal会议，与异常处理。与Spring HibernateTemplate类，Hibernate DAO实现方法可以减少到一个衬垫，同时适当参与交易。

Spring框架的目的并不是要取代J2EE中间层服务。这是一个应用程序框架，使访问低级J2EE容器服务更容易。此外，它提供了在某些情况下，某些J2EE服务的轻量级的替代品，如代替JTA JDBC基础交易策略时，只使用一个数据库。 word精品文档,可编辑,欢迎下载

基本上，Spring将帮助你编写极具可伸缩性的应用程序。

第四章：web应用中的Spring

在J2EE环境中，Spring有一种典型的用法：为J2EE web应用提供逻辑中间层的基本骨架。Spring提供了“web应用上下文”的概念，将一个强大的轻量级IoC容器无缝结合到web环境中，各种web层程序--不管是Struts、webWork、JSF、Spring web MVC还是其他自制的方案--都可以使用IoC容器。

下面的代码显示了这样一个Web应用程序上下文的一个典型的例子。在一个典型的Spring web应用中，文件驻留在WEB-INF目录，包含bean的声明（遵循“spring-beans”DTD）。这个文件中定义了业务对象和资源对象，如“myDataSource”、“myInventoryManager”和“myProductManager”等。Spring将负责管理所有这些bean的配置、关联和生命周期。

ManagerDataSource”>

.

Driver

jdbc:mysql:myds

DefaultInventoryManager”>

DefaultProductManager”>

true

word精品文档,可编辑,欢迎下载

在默认情况下，所有的bean都是通过Singleton模式创建的：每个应用上下文中只有一个实例。当Spring开始构造上述应用上下文时，“myInventoryManager”bean将自动获得生命的DataSource对象（“myDataSource”bean）：随后，“myProductManager”也会获得“myInventoryMnager”bean的引用。这些对象（也就是Spring属于常说的“bean”）只需要暴露相应的bean属性或者后遭子参数即可，而不需要进行任何特定的查找操作。

我们在中定义一个监听器（ContextLoaderListener），用于加载根应用上下文（root applicatiob context）。这个监听器定义如下：

tLoaderListener

...

Web应用程序的初始化后，根Web应用程序上下文将作为ServletContext的属性对整个Web应用程序，以通常的方式。它可以很容易地通过取相应的属性，从那里检索，或通过便利的方法。licationcontextutils。这意味着应用程序的上下文将在任何Web资源访问ServletContext可用，如Servlet，JSP，过滤器，或Struts动作，如下：

WebApplicationContext WAC = webapplicationcontextutils。

getwebapplicationcontext（ServletContext）；

Spring Web MVC框架允许web控制器被定义为在应用程序上下文中的孩子，每一个调度servlet。这种控制器可以表达依赖于豆类中的根的应用程序上下文中通过简单的bean的引用。因此，典型的Spring Web MVC应用程序不需要执行 word精品文档,可编辑,欢迎下载

一个应用程序上下文或bean工厂手工查找，或做任何其他形式的查找。

其他客户端对象是由应用程序上下文自己管理不：他们可以接收的协作对象作为bean的引用。

第五章：核心bean工厂

在前面的章节中，我们已经看到在一个网络环境的Spring IoC容器典型用途：提供便利类允许无缝集成，而不必担心底层容器的细节。然而，它确实帮助的内部运作看明白春天经营集装箱。因此，现在我们将看看更详细的Spring bean容器，从最低的建筑块：bean工厂。后来，我们将继续在应用程序上下文的概念资源设置和细节。

一个轻量级容器的主要动机之一是用定制的工厂，经常发现在J2EE应用程序的许多单身。Spring bean工厂提供了设置任何数量的应用程序对象的一个一致的方式，无论是粗粒度组件或细粒度业务对象。应用反射和依赖注入，bean工厂可以不需要知道Spring所有的组件的宿主。因此，我们称之为Spring的一种非侵入性的应用程序框架。

第六章：基础接口

在Spring中，轻量级容器最基本的接口时ctory。这是一个非常简单的接口，所以如果没有任何现成的bean工厂实现能够满足你的要求（这种情况非常罕见）。你也可以很容易地创建自己的实现。BeanFactory接口提供了两个getBean（）方法，它们都可以根据String类型的名称查找获取bean实例，两者的不同之处在于：其中一个getBean()方法允许使用者检查获得的bean是否具有所需的类型（如果类型不符，会抛出一个BeanNotOfRequireTypeExpection异常）。

public interface BeanFactory {

Object getBean(String name) throws BeansException;

Object getBean(String name, Class requiredType) throws

BeansException;

boolean containsBean(String name);

boolean isSingleton(String name) throws

NoSuchBeanDefinitionException;

word精品文档,可编辑,欢迎下载

String[] getAliases(String name) throws

NoSuchBeanDefinitionException;

}

使用者可以通过issingleton()方法检查牧歌特定名称声明的bean被定为Singleton还是Prototype。如果bean被定义为Singleton，所有对getBean()方法的调用将返回同一个对象实例的引用；如果bean被定义为Prototype，每次对getBean()的调用都将新建一个独立的对象实例。

如果某个bean配置了别名，getAliases()方法将返回它所有的别名。借助这种机制，我们可以为bean提供更具描述力的名称，而不必受特定的bean工厂存储机制的约束--例如XML文档对id属性的取值就有诸多限制。

在大多数的BeanFactory实现方法是意识到一个层次，可实施的一部分。如果一个bean是不是在目前厂发现，母厂会问，直到根厂。从一个人的角度，在这样一个层次结构的所有工厂会合并成一个。在祖先的上下文的bean定义中是可见的后代，而不是反。

BeanFactory接口的大多数实现不仅提供给了一个可以按名称查询的对象注册表，对于“用IoC配置这些对象”也提供了丰富的支持。例如，他们可以管理对象之间的依赖关系，也可以将简单属性值赋给对象。在下一节，我们将看到如何在一个简单、直观的XML结构中描述这些配置信息。

大多数的BeanFactory接口实现不只是提供一个注册的对象的名称；他们提供配置这些对象使用IOC丰富的支持。例如，他们管理的托管对象之间的关联，以及简单的性质。在下一节，我们将看看这样的配置可以在一个简单而直观的XML结构表达。

lebeanfactory子接口可以列出工厂中所有的bean。这个子接口提供了一系列方法，可以用于获得工厂中定义bean的数量、所有bean的名称、具有特定类型的所有的名称等：

public interface ListableBeanFactory extends BeanFactory {

int getBeanDefinitionCount();

String[] getBeanDefinitionNames();

String[] getBeanDefinitionNames(Class type);

word精品文档,可编辑,欢迎下载

boolean containsBeanDefinition(String name);

Map getBeansOfType(Class type, boolean includePrototypes,

boolean includeFactoryBeans) throws BeansException

}

ListableBeanFactory可以获得管理对象的相关信息，可以利用这一能力来实现这样的对象：这种对象需要与一组别的对象协作，并且只有到运行时才知道与其协作的究竟是哪些对象。

相反，BeanFactory接口，在ListableBeanFactory方法适用于目前的工厂实例和不带一个层次的帐户，工厂可能是部分。该

ctoryutils类提供了类似的方法，遍历整个工厂层次。

Spring的bean工厂有很多种方法，从简单的bean配置J2EE资源整合和AOP代理生成。bean工厂是中央的，一致的方式设置任何一种在春天，应用对象是否刀，业务对象，或网络控制器。注意，应用对象很好需要直接用到BeanFactory接口--它们通常都在工厂中配置、组装，不需要针对Spring编写任何特殊的代码。

如果只需要使用bean工厂，Spring发布了一个很小的文件，可以植入任何种类的应用中去。除了J2SE 1.3（以及用于XML解析的JAXP）之外，它唯一依赖的第三方只有Jakarta Commons Logging API。

word精品文档,可编辑,欢迎下载