Spring外文翻译.zip

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.

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.

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

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

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 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

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

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.

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

and the Spring web MVC framework in detail.

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

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 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

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

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 ejb-jar.xml 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

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

connection pools, no distributed transaction coordinator. All these features are provided by other

output), Jakarta Commons DBCP (which can be used as local DataSource), and ObjectWeb JOTM

area, such as Hibernate and JDO.

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

Spring for Web Applications

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 applicationContext.xml 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.

</property>

DefaultInventoryManager”> <property name=”dataSource”>

<ref bean=”myDataSource”/> </property></bean>

<bean id=”myProductManager” class=”ebusiness.

DefaultProductManager”>

<property name=”inventoryManager”>

<ref bean=”myInventoryManager”/> </property>

<property name=”retrieveCurrentStock”> <value>true</value>

</property>

</bean>

</beans>

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

web.xml as follows:

<web-app>

org.springframework.web.context.ContextLoaderListener </listener-class>

</web-app>

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

org.springframework.web. context.support.WebApplicationContextUtils. 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:

getWebApplicationContext(servletContext);