Spring - 四种关键策略

一、关于Spring

1、Spring是一个开源框架，是为了解决企业级应用开发的复杂性而创建的

2、Spring不仅仅局限于服务器端开发，任何Java应用都能在简单性、可测试性和松耦合等方面从Spring中获益

3、Spring最根本的使命：简化Java开发。

二、Spring简化Java开发的四种策略

1、基于POJO的轻量级和最小侵入性编程

很多框架通过强迫应用继承它们的类或实现它们的接口从而导致应用与框架绑死（例如早期的EJB与早期版本的Struts、WebWork、Tapestry以及无数其他的Java规范和框架）。Spring竭力避免因自身的API而弄乱你的应用代码，Spring不会强迫你实现Spring规范的接口或继承Spring规范的类，相反，在基于Spring构建的应用中，它的类通常没有任何痕迹表明你使用了Spring。最坏的场景是，一个类或许会使用Spring注解，但它依旧是POJO（JavaBean的广泛定义）。Spring的非侵入编程模型意味着这个类在Spring应用和非Spring应用中可以发挥同样的作用。

2、通过依赖注入和面向接口实现松耦合

任何一个有实际意义的应用都会由两个或者更多的类组成，这些类相互之间进行协作来完成特定的业务逻辑。 

传统的做法：每个对象负责管理与自己相互协作的对象（即它所依赖的对象）的引用，这将会导致高度耦合和难以测试的代码。

耦合具有两面性。一方面，紧密耦合的代码难以测试、难以复用、难以理解，并且典型地表现出“打地鼠”式的bug特性（修复一个bug，将会出现一个或者更多新的bug）。另一方面，一定程度的耦合又是必须的——完全没有耦合的代码什么也做不了。

依赖注入：通过DI，对象的依赖关系将由系统中负责协调各对象的第三方组件在创建对象的时候进行设定。对象无需自行创建或管理它们的依赖管理。

创建应用组件之间的协作的行为通常称为装配。Spring通过应用上下文（Application Context）装载bean的定义并把它们组装起来。Spring应用上下文全权负责对象的创建和组装。

3、基于切面和惯例进行声明式编程

DI能够让相互协作的软件保持松散耦合，而面向切面编程（aspect-oriented programming，AOP）允许你把遍布应用各处的功能分离出来形成可重用的组件。

面向切面编程往往被定义为促使软件系统实现关注点分离的一项技术。系统由许多不同的组件组成，每一个组件负责一块特定功能。除了实现自身核心的功能之外，这些组件还经常承担着额外的职责。诸如日志、事务管理和安全这样的系统服务经常融入到自身具有核心业务逻辑的组件中去，这些系统服务通常被称为横切关注点，因为它们会跨越系统的多个组件。

如果将这些关注点分散到多个组件中去，你的代码将会带来双重的复杂性：

• 实现系统关注点功能的代码会重复出现在多个组件中。这意味着如果你要改变这些关注点的逻辑，必须修改各个模块中的相关实现。即使你把这些关注点抽象为一个独立的模块，其他模块只是调用它的方法，但方法的调用还是会重复出现在各个模块中。
• 组件会因为那些与自身核心业务无关的代码而变得混乱。一个向地址簿增加地址条目的方法应该只关注如何添加地址，而不应该关注它是不是安全的或者是否需要支持事务。

AOP能够使这些服务模块化，并以声明的方式将它们应用到它们需要影响的组件中去。所造成的结果就是这些组件会具有更高的内聚性并且会更加关注自身的业务，完全不需要了解涉及系统服务所带来的复杂性。总之，AOP能够确保POJO的简单性。

4.通过切面和模板减少样板式代码

通常为了实现通用的和简单的任务，你不得不一遍遍地重复编写这样的代码。遗憾的是，它们中的很多是因为使用Java API而导致的样板式代码。样板式代码的一个常见范例是使用JDBC访问数据库查询数据。

传统的做法：首先需要创建一个数据库连接，然后再创建一个语句对象，最后才能进行查询。过程中还必须捕捉SQLException，这是一个检查型异常，即使它抛出后也做不了太多事情。最后，关闭数据库连接、语句和结果集，过程中依然要捕捉SQLException。

JDBC不是产生样板式代码的唯一场景。在许多编程场景中往往都会导致类似的样板式代码，JMS、JNDI和使用REST服务通常也涉及大量的重复代码。

Spring旨在通过模板封装来消除样板式代码。举个例子，Spring的JdbcTemplate（JDBC模板类）对样板式代码进行了封装。