Spring contains a lot of functionality and features, which are well-organized in seven modules shown in the diagram below. This section discusses each the of modules in turn.

The Core package is the most fundamental part of the framework and provides the Dependency Injection features allowing you to manage bean container functionality. The basic concept here is the BeanFactory, which provides a factory pattern removing the need for programmatic singletons and allowing you to decouple the configuration and specification of dependencies from your actual program logic.

On top of the Core package sits the Context package, providing a way to access beans in a framework-style manner, somewhat resembling a JNDI-registry. The context package inherits its features from the beans package and adds support for text messaging using e.g. resource bundles, event-propagation, resource-loading and transparent creation of contexts by, for example, a servlet container.

The DAO package provides a JDBC-abstraction layer that removes the need to do tedious JDBC coding and parsing of database-vendor specific error codes. Also, the JDBC package provides a way to do programmatic as well as declarative transaction management, not only for classes implementing special interfaces, but for all your POJOs (plain old java objects).

The ORM package provides integration layers for popular object-relational mapping APIs, including JDO, Hibernate and iBatis. Using the ORM package you can use all those O/R-mappers in combination with all the other features Spring offers, like simple declarative transaction management mentioned before.

Springs AOP package provides an AOP Alliance compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code implementing functionality that should logically speaking be separated. Using source-level metadata functionality you can incorporate all kinds of behavioral information into your code, a little like .NET attributes.

Springs Web package provides basic web-oriented integration features, such as multipart functionality, initialization of contexts using servlet listeners and a web-oriented application context. When using Spring together with WebWork or Struts, this is the package to integrate with.

Springs Web MVC package provides a Model-View-Controller implementation for web-applications. Springs MVC implementation is not just any implementation, it provides a clean separation between domain model code and web forms and allows you to use all the other features of the Spring Framework like validation.

Springs web MVC framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale and theme resolution as well as support for upload files. The default handler is a very simple Controller interface, just offering a ModelAndView handleRequest(request,response)method. This can already be used for application controllers, but you will prefer the included implementation hierarchy, consisting of, for example AbstractController, AbstractCommandController and SimpleFormController. Application controllers will typically be subclasses of those. Note that you can choose an appropriate base class: If you dont have a form, you dont need a FormController. This is a major difference to Struts.

You can use any object as a command or form object - theres no need to implement an interface or derive from a base class. Springs data binding is highly flexible, for example, it treats type mismatches as validation errors that can be evaluated by the application, not as system errors. So you dont need to duplicate your business objects properties as Strings in your form objects, just to be able to handle invalid submissions, or to convert the Strings properly. Instead, it is often preferable to bind directly to your business objects. This is another major difference to Struts which is built around required base classes like Action and ActionForm - for every type of action.

Compared to WebWork, Spring has more differentiated object roles. It supports the notion of a Controller, an optional command or form object, and a model that gets passed to the view. The model will normally include the command or form object but also arbitrary reference data. Instead, a WebWork Action combines all those roles into one single object. WebWork does allow you to use existing business objects as part of your form, but only by making them bean properties of the respective Action class. Finally, the same Action instance that handles the request is used for evaluation and form population in the view. Thus, reference data needs to be modeled as bean properties of the Action too. These are arguably too many roles for one object.

Springs view resolution is extremely flexible. A Controller implementation can even write a view directly to the response, returning null as ModelAndView. In the normal case, a ModelAndView instance consists of a view name and a model Map, containing bean names and corresponding objects (like a command or form, containing reference data). View name resolution is highly configurable, either via bean names, via a properties file, or via your own ViewResolver implementation. The abstract model Map allows for complete abstraction of the view technology, without any hassle. Any renderer can be integrated directly, whether JSP, Velocity, or any other rendering technology. The model Map is simply transformed into an appropriate format, such as JSP request attributes or a Velocity template model.

Pluggability of other MVC implementations

There are several reasons why some projects will prefer to use other MVC implementations. Many teams expect to leverage their existing investment in skills and tools. In addition, there is a large body of knowledge and experience av

剩余内容已隐藏，支付完成后下载完整资料

Core包是框架的最基础部分， 并提供依赖注入（Dependency Injection）特性来使你可管理Bean容器功能。 这里的基础概念是BeanFactory，它提供Factory模式来消除对程序性单例的需要， 并允许你从程序逻辑中分离出依赖关系的配置和描述。 构建于Beans包上Context包，提供了一种框架式的Bean访问方式， 有些象JNDI注册。Context包的特性得自Beans包，并添加了文本消息的发送，通过比如资源串， 事件传播，资源装载的方式和Context的透明创建，如通过Servlet容器。 DAO包提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商特有的错误代码。 该包也提供了一种方法实现编程性和声明性事务管理，不仅仅是针对实现特定接口的类， 而且对所有的POJO。 ORM包为流行的关系－对象映射APIs提供了集成层，包括JDO，Hibernate和iBatis。 通过ORM包，你可与所有Spring提供的其他特性相结合来使用这些对象/关系映射， 如前边提到的简单声明性事务管理。 Spring的AOP包提供与AOP联盟兼容的面向方面编程实现，允许你定义， 如方法拦截器和切点，来干净地给从逻辑上说应该被分离的功能实现代码解耦。 使用源码级的元数据功能，你可将各种行为信息合并到你的代码中，有点象.Net的attribute。 Spring的Web包提供了基本的面向Web的综合特性，如Multipart功能， 使用Servlet监听器的Context的初始化和面向Web的Applicatin Context。 当与WebWork或Struts一起使用Spring时，这个包使Spring可与其他框架结合。 Spring的Web MVC包提供了面向Web应用的Model-View-Controller实现。 Spring的MVC实现不仅仅是一种实现，它提供了一种domain model代码和web form的清晰分离， 这使你可使用Spring框架的所有其他特性，如校验. Spring的web框架是围绕分发器（DispatcherServlet）设计的，DispatcherServlet将请求分发到不同的处理器，框架还包括可配置的处理器映射，视图解析，本地化，主题解析，还支持文件上传。缺省的处理器是一个简单的控制器（Controller）接口，这个接口仅仅定义了ModelAndView handleRequest(request,response)方法。你可以实现这个接口生成应用的控制器，但是使用Spring提供的一系列控制器实现会更好一些，比如AbstractController，AbstractCommandController，和SimpleFormController。应用控制器一般都从它们继承。注意你需要选择正确的基类：如果你没有表单，你就不需要一个FormController。这是和Structs的一个主要区别。 你可以使用任何对象作为命令对象或表单对象：不必实现某个接口或从某个基类继承。Spring的数据绑定相当灵活，例如，它认为类型不匹配这样的错误应该是应用级的验证错误，而不是系统错误。所以你不需要为了处理无效的表单提交，或者正确地转换字符串，在你的表单对象中用字符串类型重复定义你的业务对象属性。你应该直接绑定表单到业务对象上。这是和Struts的另一个重要不同，Struts是围绕象Action和ActionForm这样的基类构建的，每一种行为都是它们的子类。 和WebWork相比，Spring将对象细分成不同的角色：它支持的概念有控制器（Controller），可选的命令对象（Command Object）或表单对象（Form Object），以及传递到视图的模型（Model）。模型不仅包含命令对象或表单对象，而且也包含任何引用数据。但是，WebWork的Action将所有的这些角色都合并在一个单独的对象里。WebWork允许你在表单中使用现有的业务对象，但是只能把它们定义成不同Action类的bean属性。更重要的是，在运算和表单赋值时，使用的是同一个处理请求的Action实例。因此，引用数据也需要被定义成Action的bean属性。这样在一个对象就承担了太多的角色。 对于视图：Spring的视图解析相当灵活。一个控制器实现甚至可以直接输出一个视图作为响应，这需要使用null返回ModelAndView。在一般的情况下，一个ModelAndView实例包含视图名字和模型映射表，模型映射表提供了bean的名字及其对象（比如命令对象或表单对象，引用数据等等）的对应关系。视图名解析的配置是非常灵活的，可以通过bean的名字，属性文件或者你自己的ViewResolver来实现。抽象的模型映射表完全抽象了表现层，没有任何限制：JSP，Velocity，或者其它的技术——任何表现层都可以直接和Spring集成。模型映射表仅仅将数据转换成合适的格式，比如JSP请求属性或者Velocity模版模型。 MVC实现的可扩展性 许多团队努力争取在技术和工具方面能使他们的投入更有价值，无论是现有的项目还是新的项目都是这样。具体地说，Struts 不仅有大量的书籍和工具，而且有许多开发者熟悉它。因此，如果你能忍受Struts的架构性缺陷，它仍然是web层一个很好的选择。WebWork和其它web框架也是这样。 如果你不想使用Spring的web MVC框架，而仅仅想使用Spring提供的其它功能，你可以很容易地将你选择的web框架和Spring结合起来。只要通过Spring的ContextLoadListener启动一个Spring的根应用上下文，并且通过它的ServletContext属性（或者Spring的各种帮助方法）在Struts或WebWork的Action中访问。注意到现在没有提到任何具体的“plugins”，因此这里也没有提及如何集成：从web层的角度看，你可以仅仅把Spring作为一个库使用，根应用上下文实例作为入口。 所有你注册的bean和Spring的服务可以在没有Spring的web MVC下被访问。Spring并没有在使用方法上和Struts或WebWork竞争，它只是提供单一web框架所没有的功能，从bean的配置到数据访问和事务处理。所以你可以使用Spring的中间层和（或者）数据访问层来增强你的应用，即使你只是使用象JDBC或Hibernate事务抽象这样的功能。 Spring MVC框架的特点 如果仅仅关注于web方面的支持，Spring有下面一些特点：清晰的角色划分：控制器，验证器，命令对象，表单对象和模型对象；分发器，处理器映射和视图解析器；等等。 直接将框架类和应用类都作为JavaBean配置，包括通过应用上下文配置中间层引用，例如，从web控制器到业务对象和验证器的引用。 可适应性，但不具有强制性：根据不同的情况，使用任何你需要的控制器子类（普通控制器，命令，表单，向导，多个行为，或者自定义的），而不是要求任何东西都要从Action/ActionForm继承。 可重用的业务代码，而不需要代码重复：你可以使用现有的业务对象作为命令对象或表单对象，而不需要在ActionForm的子类中重复它们的定义。 可定制的绑定和验证：将类型不匹配作为应用级的验证错误，这可以保存错误的值，以及本地化的日期和数字绑定等，而不是只能使用字符串表单对象，手动解析它并转换到业务对象。 可定制的处理器映射，可定制的视图解析：灵活的模型可以根据名字/值映射，处理器映射和视图解析使应用策略从简单过渡到复杂，而不是只有一种单一的方法。 可定制的本地化和主题解析，支持JSP，无论有没有使用Spring标签库，支持JSTL，支持不需要额外过渡的Velocity，等等。 简单而强大的标签库，它尽可能地避免在HTML生成时的开销，提供在标记方面的最大灵活性。 使用ORM工具进行数据访问 Spring在资源管理，DAO实现支持以及实物策略等方面提供了与Hibernate, JDO和iBATIS SQL映射的集成。 对Hibernate，Spring使用了很多IoC的方便的特性提供了一流的支持，帮助你处理很多典型的Hibernate整合的问题。所有的这些都遵守Spring通用的事务和DAO异常体系.。 当您选择使用O/R映射来创建数据访问应用程序的时候，Spring的增加部分就会向您提供重要的支持。首先你应该了解的是，一旦你使用了Spring对O/R映射的支持，你不需要亲自作所有的事情。在决定花费力气，冒着风险建造类似的内部底层结构之前，我们都建议您考虑和利用Spring的解决方案。不管你使用的是何种技术，大部分的O/R映射支持都可以以library样式被使用，因为所有的东西都是被设计成一组可重复利用的JavaBeans。在ApplicationContext和BeanFactory中使用更是提供了配置和部署简单的好处，因此，这一章里的大多数例子都是在ApplicationContext中配置。 使用Spring构建你的ORM应用的好处包括: 测试简单. Spring的IoC使得很容易替换掉不同的实现，Hibernate SessionFacotory的位置，datasource, 事务管理, 映射对象的实现。这样就很容易隔离测试持久化相关代码的各个部分。异常包装。 Spring能够包装Hibernate异常，把它们从专有的，checked exception变为一组抽象的runtime exception。这样你就可以仅仅在恰当的层处理大部分的不可恢复的异常，使你避免了很多讨厌的catch/throw以及异常声明。你还是可以在你需要的地方捕捉和处理异常。回想一下JDBC异常（包括与DB相关的方言）被转变为同样的异常体系，这就意味着你可以在一致的编程模型中处理JDBC操作。 通用的资源管理。 Spring的application context能够处理诸如Hibernate 的SessionFactory， JDBC的datasource，iBatis的SQLMaps配置对象以及其他相关资源的定位和配置。这使得这些配置的值很容易被管理和修改。Spring提供了有效，简单和安全的Hibernate Session处理。一般的使用Hibernate的代码则需要使用同一个Hibernate Session对象以确保有效和恰当地事务处理。而Spring让我们可以很容易透明地创建和绑定一个session到当前线程；你可以使用以下两种办法之一：声明式的AOP方法拦截器，或通过使用一个外部的template包装类在Java代码层次实现。这样，Spring就解决了在很多Hibernate论坛上出现的使用问题。 综合的事务管理 。 Spring允许你包装你的ORM代码，通过使用声明式的AOP方法拦截器或者在代码级别使用外部的template包装类。不管使用哪一种，事务相关的语义都会为你处理，万一有异常发生也会帮你做适当的事务操作（比如rollback）。就象我们下面要讨论的一样，你能够使用和替换各种transaction managers，却不会使你的Hibernate相关的代码受到影响。更好的是，JDBC相关的代码可以完全和Hibernate代码integrate transactionaly。这对于处理那些没有用Hibernate或iBatis实现的功能非常有用。 避免绑定特殊的技术，允许mix-and-match的实现策略。 虽然Hibernate非常强大，灵活，开源而且免费，但它还是使用了自己的特定的API。此外有人也许会争辩：iBatis更轻便而且在不需要复杂的O/R映射策略的应用中使用也很优秀。能够选择的话，使用标准或抽象的API来实现主要的应用需求，通常是更好的。尤其，当你可能会因为功能，性能或其他方面的原因而需要切换到另一个实现的时候。举例来说，Spring对Hibernate事务和异常的抽象，以及能够让你轻松交换mapper和DAO对象（实现数据访问功能）的IoC机制，这两个特性可以让你在不牺牲Hibernate性能的情况下，在你的应用程序中隔离Hibernate的相关代码。处理DAO的高层次的service代码不需要知道DAO的具体实现。这个方法可以很容易使用mix-and-match方案互不干扰地实现数据访问层（比如在一些地方用Hibernate，一些地方使用JDBC，其他地方使用iBatis），mix-and-match有利于处理遗留下来的代码以及利用各种技术（JDBC,Hibernate,iBatis）的长处.。 Spring提供了一致的事务管理抽象。这个抽象是Spring最重要的抽象之一， 它有如下的优点： 为不同的事务API提供一致的编程模型，如JTA、JDBC、Hibernate、iBATIS数据库层 和JDO 提供比大多数事务API更简单的，易于使用的编程式事务管理API 整合Spring数据访问抽象 支持Spring声明式事务管理 传统上，J2EE开发者有两个事务管理的选择: 全局事务或 局部事务。全局事务由应用服务器管理，使用JTA。局部事务是和资源相关的：例如，一个和JDBC连接关联的事务。这个选择有深刻的含义。 全局事务可以用于多个事务性的资源（需要指出的是多数应用使用单一事务性 的资源）。使用局部事务，应用服务器不需要参与事务管理，并且不能帮助确保 跨越多个资源的事务的正确性。 全局事务有一个显著的不利方面，代码需要使用JTA：一个笨重的API（部分是 因为它的异常模型）。此外，JTA的UserTransaction通常需 要从JNDI获得，这意味着我为了JTA需要同时使用JNDI和JTA。 显然全部使用全局事务限制了应用代码的重用性，因为JTA通常只在应用服务器的环境中才能使用。 使用全局事务的比较好的方法是通过EJB的CMT （容器管理的事务）： 声明式事务管理的一种形式（区别于编程式事务管理 ）。EJB的CMT不需要任何和事务相关的JNDI查找，虽然使用EJB本身 肯定需要使用JNDI。它消除大多数——不是全部——书写Java代码控制事务的需求。 显著的缺点是CMT绑定在JTA和应用服务器环境上，并且只有我们选择 使用E

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[22486]，资料为PDF文档或Word文档，PDF文档可免费转换为Word