Spring 坑路1 -> Spring 框架基本介绍

Spring简介

  Spring 是一个开源框架，最早由 Rod Johnson 创建，它解决的是业务逻辑层和其他各层的松耦合问题。在诞生之初，创建 Spring 的主要墓地是用来替代更加重量级的企业级 Java 技术，尤其是EJB。相对于 EJB 来说，Spring 提供了更加轻量级和简单的编程模型。

  经过几十年的发展，Spring 正在拓展其他的领域，如：移动开发、社交API 集成、NoSQL 数据库、云计算、大数据以及微服务架构。

Sring简化开发采取的四种策略：

基于POJO的轻量级和最小侵入性编程（POJO）

通过依赖注入和面向接口实现松耦合（IOC）

基于切面和惯例进行声明式编程（AOP）

通过切面和模版减少样板式代码（Template）

Spring–基于POJO的轻量级和最小侵入性编程

  很多框架通过强制要求应用继承规定的类或者实现规定的接口，从而实现相应的功能，导致应用与框架强行耦合。

  Spring 不会强迫实现 Spring 规范的接口或继承规范的类，相反，在基于 Spring 框架构建的应用中，它的类通常是没有任何痕迹标明已经使用了 Spring。最坏的情况就是使用 Spring 注解，但它依然是一个简单的 POJO 类，可以做其他任何事情。

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

  A 类要依赖 B 类，必然要使用 B 的 instance，那么：

1.通过 A 类的接口把 B 类传入{(A implements B) => A}

2.通过 A 类的构造器把 B 传入{(new A(B)) => A}

3.通过设置 A 类的属性把 B 传入{new A().setB(B) => A}

这个过程叫依赖注入（DI）

Spring–基于切面和惯例进行声明式编程

  IOC 能够让相互协作的软件组件保持松散耦合，而面向切面编程（AOP）允许把遍布系统各处的功能抽离出来形成可重用的组件。

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

实现系统关注点功能的代码将会重复出现在多个组件中

组件会因为那些与自身核心业务无关的代码而变得混乱

Spring–通过切面和模版减少样板式代码

  在编码时，通常为了实现通用和简单的任务，必须一遍遍重复编写类似的代码，这就是样板式代码。样板式代码的一个常见范例是使用 JDBC 访问数据库查询数据，常见的还有 JSM、JNDI 与使用 REST 服务也会涉及大量的重复代码。

Spring 旨在通过模版封装来消除样板式代码。

Spring 容器

  在基于 Spring 的应用中，应用对象位于Spring 容器中，Spring 容器负责创建对象，装配对象，配置对象并管理对象的生命周期，由生到死。

  容器是 Spring 框架的核心，Spring 容器使用 IOC 管理构成应用的组件，它会创建相互协作的组件之间的关联。使这些对象更简单、干净，更易于理解，更易于重用并且更易于进行单元测试。
  Spring 容器并不只有一个，Spring 自带了多个容器实现，可归为两种不同类型。

Bean 工厂（由 org.springframework.beans.factory.BeanFactory 接口定义）是最简单的容器，提供基本的 DI 支持。

BeanFactory：提供了基本依赖注入功能，在调用一个 bean 对象的时候，才会去实例化它（延迟加载形式）

应用上下文（由 org.springframework.context.ApplicationContext 接口定义）基于 BeanFactory 构建，并提供应用框架级别的服务。

ApplicationContext:构建于 BeanFactory 之上的更高级别的上下文对象，功能相比 BeanFactory 更加强大。启动容器的时候加载（启动容器的时候，就会去实例化所有的对象）

ClassPathXmlApplicationContext:从类路径中加载配置文件构建上下文
FileSystemXmlApplicationContext:从文件系统中加载配置文件构建上下文
XmlWebApplicationContext:从web系统里面加载的配置文件构建上下文

ps: Bean 工厂对于大多数应用来说往往太低级，因此应用上下文要比 Bean 工厂更受欢迎

Bean 的生命周期

  在传统的 Java 应用中，bean 的生命周期很简单，使用 Java 关键字 new、反射等方式进行 bean 实例化后，该 bean 就可以使用了。一旦该 bean 不再使用被使用，则由 Java 虚拟机进行自动垃圾回收。相比之下 Spring 容器中的 bean 的生命周期就显得相对复杂很多。

1.Spring 对 bean 进行实例;

2.Spring 将值和 bean 的引用注入到 bean 对应的属性中;

3.如果 bean 实现了 BeanNameAware 接口，Spring 将 bean 的 ID 传递给 setBeanName() 方法;

4.如果 bean 实现了 BeanFactoryAware 接口，Spring 将调用 setBeanFactory() 方法，将 BeanFactory 容器实例传入;

5.如果 bean 实现了 ApplicationContextAware 接口，Spring 将调用 setApplicationContext() 方法，将 bean 所在的应用上下文的引用传入进来;

6.如果bean实现了 BeanPostProcessor 接口，Spring 将调用它们的 post-ProcessBeforeInitialization() 方法;

7.如果 bean 实现了 InitializingBean 接口，Spring 将调用它们的 after-PropertiesSet() 方法。类似地，如果 bean 使用 init-method 声明了初始化方法，该方法也会被调用;

8，如果bean实现了 BeanPostProcessor 接口，Spring 将调用它们的 post-ProcessAfterInitialization() 方法;

9.此时，bean 已经准备就绪，可以被应用程序使用了，它们将一直驻留在应用上下文中，直到该应用上下文被销毁;

10.如果 bean 实现了 DisposableBean 接口，Spring 将调用它的 destroy() 接口方法。同样，如果 bean 使用 destory-method 声明了销毁方法，该方法也会被调用。