英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料
第一章
介绍Spring
当我们想到Java开发者社区时，我们想起了十九世纪四十年代后期淘金探矿者的群体，他们疯狂地在北美河流寻找黄金碎片。作为Java开发人员，我们的流充斥着开源项目，但像淘金者一样，找到一个有用的项目大概是费时且艰巨的。
人们对很多开源Java项目有一个普遍抱怨是，它们仅仅是为了填补最新流行语的使用技术或模式的现实空白。话虽如此，许多高质量且可用的项目满足并解决实际应用的需求，并且在这本书中，你将遇到这些项目的部分。你会更好地了解Spring。
在本书中，你将见识到许多不同开源技术的应用程序，这些应用程序都是在Spring框架下统一建立的。在使用Spring时，应用程序开发人员可以使用不同的开源工具，所以无需编写大量代码，也不需要把这应用程序与任何特定工具紧密耦合。
在本章中，正如这个标题所暗示的，我们将为你介绍的Spring框架，而不是看任何实例化和解释。如果你已经了解了Spring项目，那么你可以跳过这一章，直接进入第2章。
什么是Spring?
实际上也许将解释Spring为一项技术最难的部分就是将它分类。 通常情况下，Spring被解释为构建Java应用程序的轻量级框架，但是该语句引发了两个有趣的观点。 首先，你可以使用Spring在Java中构建任何应用程序（例如，单机，网络，JEE应用程序等），而不像许多其他框架，如Apache Struts（仅限于Web应用程序）。第二，描述的轻量级部分并不真正指类的数量和分布的大小，而是把Spring的原则定义为一个整体，即最小的影响。Spring是轻量级的，在本意义上，你一定对应用程序代码进行很少的更改，以获得Spring核心的好处，并且如果你选择使用Spring在任何时候停止，那么你会发现这样做很简单。请注意，我们要求了最后一个语句引用Spring内核，只有许多额外的Spring组件，如数据访问，需要与Spring框架更紧密的耦合。然而，这种耦合的好处是非常明显的，在本书中我们将介绍如何最大限度地减少对应用程序的影响。
反转控制或依赖性注入
Spring框架的核心在于控制反转（IoC）的原则。IoC是一种外部化组件依赖关系创建和管理的技术。考虑一个实例，其中类Foo依赖于类Bar的一个实例来执行某种数据处理。传统上，Foo使用新运算符创建Bar实例或从某种工厂类中获取一个实例。使用IOC方法，BAR（或子类）的实例在运行时由一些外部进程提供给FO。这种行为，在运行时注入依赖性，导致IOC由Martin Fowler重命名为更描述性的依赖注入（DI）。在第4章中讨论了由DI管理的依赖关系的精确性质。
注意：正如你在第4章中所看到的，在引用控制反转时使用术语依赖注入总是正确的。在Spring的上下文中，你可以互换使用这些术语，而不会有任何意义上的损失。
Spring的DI实现基于两个Java核心概念：JavaBeans和接口。 当您使用Spring作为DI提供程序时，你可以通过不同的方式（例如，外部XML文件，Spring Java配置类或代码中的Java注释）在应用程序中定义依赖项配置的灵活性。JavaBeans（也称为POJO，用于Plain Old Java Objects）为创建可通过多种方式配置的Java资源提供了一种标准机制。在第4章中，你将看到Spring如何使用JavaBean规范来构建其DI配置模型的核心。实际上，任何Spring管理的资源都被称为bean。 如果您对JavaBeans不熟悉，请参考我们在第4章开头介绍的快速入门。
接口和DI是互利的技术。我们确信，阅读本书的人都会认为，将应用程序设计和编码到接口应用程序更加灵活，但是使用接口设计的应用程序连接起来非常复杂，并且这给开发人员带来额外编码负担。通过使用DI，你可以将应用程序中基于接口的设计所需的代码量减少到很少。同样，通过使用接口，你可以充分利用DI，因为在你的bean中可以利用任何接口实现来满足它们的依赖关系。
在DI的上下文中，Spring比框架更像一个容器，它提供应用程序类的实例以及它们所需的所有依赖关系，但它却是一种不太干扰的方式进行。使用Spring的DI只需要遵循JavaBeans命名约定（正如你将在第5章中看到的，你可以绕过使用Spring的方法注入支持），没有特殊的类可以从中继承或遵循专有的命名方案。如果有的话，在使用DI的应用程序中所做的唯一更改是在JavaBeans上公开更多的属性，从而允许在运行时注入更多的依赖项。
注意：除了XML配置文件外，Spring Framework 3.0（和更加新版本）还支持基于Java的bean元数据。
依赖注入的进程
在近几年，由于Spring和其他DI框架的普及，在Java开发环境中DI已经被广泛接受。同时，开发人员确信在应用程序开发中使用DI是最佳选择，使用DI的益处也是能很好理解。
DI的广泛实践也受被Sun Microsystems（在2009年被Oracle收购）所领导的Java Community Process（JCP）的发展所影响。在2009年，“依赖注入Java”成为正式的Java规范请求（JSR-330），正如你所期待的那样，规范的领导者之一是Spring Johnson的创始人Rod Johnson。
在Java企业版第6版（称为JEE 6）中，JSR-330成为整个技术堆栈的包含规范之一。 与此同时，Enterprise JavaBeans（EJB）架构（从3.0版开始）也进行了重大改进; 为了简化各种Enterprise JavaBeans应用程序的开发采用了DI模型。
虽然我们在第4章中对DI进行了全面讨论，但使用DI的好处是值得关注得，而不是更传统的方法：
- 减少映射代码：DI最大优点之一就是它能够大幅度减少代码编写的数量，将你的应用程序的不同组件粘合在一起。通常这些非常简单的代码，创建依赖关系只需创建一个新的实例对象。然而，当你需要在JNDI存储库中查找依赖项或者无法直接调用依赖项时，映射代码可能会变得非常复杂，如远程资源的调度。在很多情况下，DI可以通过提供JNDI自动查找和自动代理远程资源来真正简化映射代码。
- 简化的应用配置：通过采纳DI，应用程序的配置过程被大大简化了。你可以使用注释或XML来配置那些可注入其他类的类。你可以使用同样的技术来向“注入器”表达依赖性需求，来注入适当的bean实例或属性。此外，DI使得将一个依赖关系替换为另一个关系的实现更简单。思考一下你有一个数据访问对象（DAO）组件，它对PostgreSQL数据库执行数据操作，并且你想升级到Oracle。使用DI时，你可以简单地重新配置对工程对象的适当依赖关系，来使用Oracle实现而不是PostgreSQL。
- 在单个存储库中管理常见依赖项的能力：使用传统方法对公共服务进行依赖性管理，例如，数据源连接，事务处理，远程服务等，你可以在依赖类中创建依赖关系的实例（或从某些工厂类中查找）。这将导致依赖关系在你的应用程序中传播类，并且更改可能会遇到问题的类。当你使用DI时，关于这些常见依赖项的各种信息都会包含在单个存储库中（使用Spring，你可以选择在XML文件或Java类中信息存储），从而使得依赖关系的管理更加简单并很少出错。
- 改进的可测性：当你为DI设计你的类时，可以很容易替换依赖关系。当你测试应用程序时特别方便。考虑执行一些复杂过程的业务对象; 对于部分来说，它使用DAO访问存储在关系数据库中的数据。 对于你的测试，你对测试DAO不感兴趣; 你仅想使用各种数据集来测试业务对象。在传统的方法，业务对象负责获取DAO它自己的实例，那么很难对其进行测试，因为你不能使用返回测试数据集的模拟来实现轻松替换DAO。相反，你需要保证你的测试数据库包含正确的数据并且你的测试使用完整的DAO实现。 使用DI，您可以创建返回测试数据集的DAO对象的模拟实现，然后可以通过这个给业务对象进行测试。这个机制可以扩展为用于测试应用程序的任何层，尤其对可以创建HttpServletRequest和HttpServletResponse的模拟可以实现的Web组件非常有用。
- 改进良好的应用设计：DI的设计意义，一般来说，针对接口进行设计。一个典型的被设计为面向注入的应用程序使所有主要组件都被定义为接口，然后这些接口的具体实现使用DI容器创建并链接。在DI和基于DI的容器（例如Spring）出现之前，这种设计是可能在java中使用的，但通过使用Spring，您可以免费获得大量的DI功能，并且你能在构建应用程序逻辑上更专注，而不是支持它的框架。
就像你从这个列表中看到的，DI为你的应用程序提供了很多好处，但它并不是没有缺点。尤其是，DI可以让不熟悉代码的人很难看到某个特定依赖项的某个实现被挂钩到某个对象中。通常，这仅有一个问题当开发人员对DI没有经验时; 在变得更有经验并且遵循良好的DI编码实践（例如，将每个应用层中的所有可注射类放入相同的包）之后，开发人员将能够容易地发现整个图像。大部分情况下，好处远远大于这个缺点，但是在规划应用程序时应该考虑这一点。
依赖注入之外
仅靠Spring的核心及其先进的DI功能就是一个有价值的工具，但Spring真正擅长的地方在于其无数的附加功能，所有这些优雅设计和构建的都是使用DI原理进行。Spring为应用程序的所有层提供了功能，从用于数据访问的辅助应用程序编程接口（API）到高级模型视图控制器（MVC）功能。Spring中这些特性的优点在于，虽然Spring经常提供自己的方法，但您可以容易地将它们与Spring中的其他工具集成在一起，从而使这些工具成为Spring家族的第一类成员。
Spring面向方面编程
面向方面编程（AOP）是Java领域中“当下的编程模型”之一。AOP提供了在单一地方实现横切逻辑（即适用于你的应用程序中很多的逻辑）的能力，并且可以自动在应用程序中应用该逻辑。目前AOP正在享受大量的时间， 然而，所有宣传背后都是一个真正有用的技术，它在任何Java开发人员的工具箱中都占有一席之地。
Spring对AOP的方法是向目标对象创建“动态代理”，并用配置的方法来“编织”对象并执行横切逻辑。
另一个流行的AOP库是Eclipse AspectJ项目（www. clip.org/asspectJ），它提供了包括对象构造、类加载和更强的横切能力等更强大的功能。
然而，对于Spring和AOP开发人员来说的好消息是从版本2.0开始，Spring提供了与AspectJ更紧密的集成。以下是一些亮点：
- 支持AspectJ格式的切入点表达式
- 支持对AspectJ注释格式的支持，同时仍使用Spring AOP进行织改进
- 支持在AspectJ中对DI实现的方面
- 支持在Spring应用环境中进行加载时间的编写
这两种类型的AOP都有自己的地方，并且在大多数情况下，Spring AOP在解决应用程序的横切要求方面是足够的。然而，对于更复杂的要求，AspectJ能被使用，并且可以在相同的Spring能力的应用中混合Spring AOP和AspectJ。
AOP有很多应用程序。在许多传统的AOP示例中一个典型的涉及执行某种类型的日志记录，但是AOP的使用已经被发现远远超出了普通的日志记录应用程序。实际上，在Spring框架本身中，AOP被用于许多目的，尤其是在事务管理中。第6章和第7章中详细介绍了Spring AOP，在这里我们展示了AOP在Spring框架和你自己的应用程序中的典型用法，以及AOP性能和传统技术比AOP更适合的领域。
Spring表达式语言（SPEL）
表达式语言（EL）是一种允许应用程序在运行时操纵Java对象的技术。然而，EL的问题在于不同的技术提供了自己的EL实现和语法。例如，Java Server Pages（JSP）和Java Server Faces（JSF）都有自己的EL，它们的语法不同。 为了解决这个问题，创建了统一表达语言（EL）。
因为Spring框架发展如此迅速，因此需要一种可以在所有Spring框架模块以及其他Spring项目之间共享标准表达式语言。因此，从3.0版开始，Spring引入了Spring表达式语言（SpEL）。 SpEL为评测表达式和在运行时访问Java对象和Spring bean提供了强大的功能。结果可以在应用程序中使用或注入到其他JavaBean中。
在这本书中，你不会找到一个致力于SpEL的章节。然而，通过整本书，我们将在适当的情况下使用SpEL进行详细解释。
在Spring中验证
验证是在各种类型应用程序中的另一个大问题。理想的情况是，包含业务数据的JavaBeans中的属性的验证规则可以以一致的方式应用，而不管数据操作请求是从前端、批作业还是远程启动的（例如，Web服务、REST Web服务、RPC）。等
受需求驱动，JCP开发了Bean验证API规范（JSR-303）。Bean验证API为定义bean验证规则提供了一种标准方法。例如，当申请将@NotNull注释应用于bean的属性时，这意味着该属性在保存到数据库中之前不应包含空值。
从3.0版开始，Spring为JSR-303提供了开盒即用的支持。要使用API，只需声明一个ValidatorFactoryBean并将Validator接口注入到任何Spring管理的bean中。 Spring将为你解决底层实现。默认情况下，Spring将首先寻找Hibernate验证器（Hibernate .org／子项目/验证器），这是一个流行的JSR-303实现。
许多前端技术（例如，JSF 2、谷歌Web工具包），包括Spring MVC，也支
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[22468]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
