Spring中的IOC和AOP

最新推荐文章于 2024-02-19 17:34:45 发布

DawidZhu

最新推荐文章于 2024-02-19 17:34:45 发布

阅读量524

点赞数

文章标签： spring java 前端

本文链接：https://blog.csdn.net/zdwzzu2006/article/details/128724117

版权

Spring框架通过IOC（控制反转）和AOP（面向方面编程）实现了组件的解耦合。IOC通过依赖注入实现，包括构造器注入、setter注入和接口注入。AOP则用于处理横切关注点，如声明式事务管理，提供代码复用和模块化。Spring包含DAO、ORM、AOP、JEE、WEB和CORE等六大模块，支持多种ORM框架集成、Web开发和J2EE规范。

摘要由CSDN通过智能技术生成

IOC(控制反转)和AOP(面向方面编程)作为Spring框架的两个核心，很好地实现了解耦合。所以，简单来说，Spring是一个轻量级的控制反转（IoC）和面向切面（AOP）的容器框架。

spring的基本框架主要包含六大模块：DAO、ORM、AOP、JEE、WEB、CORE

Spring DAO：Spring提供了对JDBC的操作支持：JdbcTemplate模板工具类。

Spring ORM：Spring可以与ORM框架整合。例如Spring整合Hibernate框架，其中Spring还提供HibernateDaoSupport工具类，简化了Hibernate的操作。

Spring WEB：Spring提供了对Struts、Springmvc的支持，支持WEB开发。与此同时Spring自身也提供了基于MVC的解决方案。

Spring AOP：Spring提供面向切面的编程，可以给某一层提供事务管理，例如在Service层添加事物控制。

Spring JEE：J2EE开发规范的支持，例如EJB 。

Spring Core：提供IOC容器对象的创建和处理依赖对象关系。

二、IOC

要了解控制反转，需要先了解软件设计的一个重要思想：依赖倒置原则。

　　什么是依赖倒置原则？假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。但这种设计维护性很低。

　换一种思路：我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘，底盘依赖车身，车身依赖汽车。

　控制反转就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入。这几种概念的关系大概如下

所以我们需要进行控制反转（IoC），即上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义：

这里我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。

　　这里我们采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递，核心思路都是一样的，都是为了实现控制反转。

　　那什么是控制反转容器（IoC Container）呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。

　因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml，也可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。

三、AOP

1.1 什么是AOP

（1）面向切面编程（AOP）完善spring的依赖注入（DI），面向切面编程在spring中主要表现为两个方面 1.面向切面编程提供声明式事务管理 2.spring支持用户自定义的切面。

（2）面向切面编程（aop）是对面向对象编程（oop）的补充，面向对象编程将程序分解成各个层次的对象，面向切面编程将程序运行过程分解成各个切面。
（3）AOP从程序运行角度考虑程序的结构，提取业务处理过程的切面，oop是静态的抽象，aop是动态的抽象，是对应用执行过程中的步骤进行抽象，，从而获得步骤之间的逻辑划分。

1.2 为什么需要 AOP

想象下面的场景，开发中在多个模块间有某段重复的代码，我们通常是怎么处理的？显然，没有人会靠“复制粘贴”吧。在传统的面向过程编程中，我们也会将这段代码，抽象成一个方法，然后在需要的地方分别调用这个方法，这样当这段代码需要修改时，我们只需要改变这个方法就可以了。然而需求总是变化的，有一天，新增了一个需求，需要再多出做修改，我们需要再抽象出一个方法，然后再在需要的地方分别调用这个方法，又或者我们不需要这个方法了，我们还是得删除掉每一处调用该方法的地方。实际上涉及到多个地方具有相同的修改的问题我们都可以通过 AOP 来解决。

1.3 AOP 实现分类

AOP 要达到的效果是，保证开发者不修改源代码的前提下，去为系统中的业务组件添加某种通用功能。AOP 的本质是由 AOP 框架修改业务组件的多个方法的源代码，看到这其实应该明白了，AOP 其实就是前面一篇文章讲的代理模式的典型应用。
按照 AOP 框架修改源代码的时机，可以将其分为两类：

静态 AOP 实现， AOP 框架在编译阶段对程序源代码进行修改，生成了静态的 AOP 代理类（生成的 *.class 文件已经被改掉了，需要使用特定的编译器），比如 AspectJ。
动态 AOP 实现， AOP 框架在运行阶段对动态生成代理对象（在内存中以 JDK 动态代理，或 CGlib 动态地生成 AOP 代理类），如 SpringAOP。