学习Spring笔记

spring 可以看作项目中所有对象的管家

Spring框架是一个轻量级开源的JavaEE框架，为了解决企业应用开发的复杂性而出现

是一个轻量级的 Java 开发框架，它是为了解决企业应用开发的复杂性而创建的。Spring 的核心是控制反转（IoC）和面向切面编程（AOP）。简单来说，Spring 是一个分层的 Java EE 一站式轻量级开源框架。

Spring 的主要作用就是为代码 解耦，降低代码间的耦合度。

Spring 根据代码的功能特点，将降低耦合度的方式分为了以下两类。

• IoC：使得主业务在相互调用过程中，不用再自己维护关系了，即不用再自己创建要使用的对象了，而是由 Spring 容器统一管理，实现自动 注入。
• AOP：使得系统级服务得到了最大复用，且不用再手工将系统级服务混杂到主业务逻辑中了，而是由 Spring 容器统一完成 织入。

Spring 的特点：非侵入式、容器、控制反转(IoC)、面向切面编程(AOP)

非侵入式

所谓非侵入式是指，Spring 框架的 API 不会在业务逻辑上出现，即业务逻辑是 POJO。由于业务逻辑中没有 Spring 的 API，所以业务逻辑可以从 Spring 框架快速的移植到其他框架， 即与环境无关。

容器

Spring 作为一个容器，可以管理对象的生命周期、对象与对象之间的依赖关系。可以通过配置文件，来定义对象，以及设置与其他对象的依赖关系。

控制反转（IoC）（通过 反射 或者 工厂方法 目的：解耦，降低耦合度）

我是这么理解的：把创建对象和对象之间相互调用的过程交给spring管理

目的：降低耦合度

控制反转（Inversion of Control），即创建被调用者的实例不是由调用者完成，而是由 Spring 容器完成，并注入调用者。一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。即，不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。

面向切面编程（AOP） Java程序要 高内聚低耦合

我是这么理解的：不修改源代码，增加功能

面向切面编程（Aspect Orient Programming），是一种编程思想，是面向对象编程 OOP 的补充。允许通过分离应用的业务逻辑与系统级服务（例如日志和事务管理）进行开发。开发者只要专注实现业务逻辑，并不需要负责其它的系统级关注点，例如日志或事务支持。

Spring 核心 IoC

通过 反射 或者 工厂方法实现 目的：解耦，降低耦合度

借助于“第三方”实现具有依赖关系的对象之间的解耦

控制反转的核心功能在于通过将程序代码获取对象调用权，来实现对象的装配和管理。控制反转就是对对象控制权的转移，从程序代码本身反转到了外部容器。

当前比较流行的实现方式有两种： 依赖注入和依赖查找，依赖注入方式应用更为广泛。

• 依赖查找（DL）：Dependency Lookup，容器提供回调接口和上下文环境给组件，程序代码则需要提供具体的查找方式。
• 依赖注入（DI）：Dependency Injection，指程序运行过程中，若需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部容器，由外部容器创建后传递给程序。

依赖注入是目前最优秀的解耦方式。依赖注入让 Spring 的 Bean 之间以配置文件的方式组织在一起，而不是以硬编码的方式耦合在一起的。

Spring通过DI（依赖注入）实现IOC（控制反转），常用的注入方式主要有三种：

• 构造方法注入
• setter注入
• 基于注解的注入

Spring 核心 AOP

通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。

利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。

主要功能

日志记录，性能统计，安全控制，事务处理，异常处理等等。

主要意图

将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改变这些行为的时候不影响业务逻辑的代码。

AOP/OOP

区分

AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。

而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。

上面的陈述可能过于理论化，举个简单的例子，对于“雇员”这样一个业务实体进行封装，自然是OOP/OOD的任务，我们可以为其建立一个“Employee”类，并将“雇员”相关的属性和行为封装其中。而用AOP设计思想对“雇员”进行封装将无从谈起。

同样，对于“权限检查”这一动作片断进行划分，则是AOP的目标领域。而通过OOD/OOP对一个动作进行封装，则有点不伦不类。

换而言之，OOD/OOP面向名词领域，AOP面向动词领域。

关系

很多人在初次接触 AOP 的时候可能会说，AOP 能做到的，一个定义良好的 OOP 的接口也一样能够做到，我想这个观点是值得商榷的。AOP和定义良好的 OOP 的接口可以说都是用来解决并且实现需求中的横切问题的方法。但是对于 OOP 中的接口来说，它仍然需要我们在相应的模块中去调用该接口中相关的方法，这是 OOP 所无法避免的，并且一旦接口不得不进行修改的时候，所有事情会变得一团糟；AOP 则不会这样，你只需要修改相应的 Aspect，再重新编织（weave）即可。 当然，AOP 也绝对不会代替 OOP。核心的需求仍然会由 OOP 来加以实现，而 AOP 将会和 OOP 整合起来，以此之长，补彼之短。