Spring 中的 IoC 与 aop

IoC/DI

概念

IoC（Inverse of Control），控制反转。

DI(Dependecy Injection),依赖注入

两者是同一个概念，IoC 包含两个内容：其一是控制，其二是反转。在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决。这个第三方指的就是 Spring 的容器。IoC 另解，依赖注入（Dependency Injection），调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。讲的通俗一点就是，如果 A 要调用 B 中的方法，则 A 依赖于 B，最简单的犯法就是 A 去主动获取 B 的实例：B b = new B();然后就可以调用 b 对象了。所谓的反转，就是如果 A 要调用 B，不需要 A 去主动获取 B，由其它人将 B 送到 A 的面前。

在 Spring 中，Spring 以动态灵活的方式来管理对象，注入的两种方式：

• 设置注入：优点是直观，自然
• 构造注入：优点是可以在构造器中决定依赖关系的顺序

扩展资料：

主要形式

依赖查找：容器提供回调接口和上下文条件给组件。EJB 和 Apache Avalon 都使用这种方式。这样一来，组件就必须使用容器提供的 API 来查找资源和协作对象，仅有的控制反转只体现在那些回调方法上（也就是上面所说的 类型 1）：容器将调用这些回调方法，从而让应用代码获得相关资源。

依赖注入：组件不做定位查询，只提供普通的 Java 方法让容器去决定依赖关系。容器全权负责的组件的装配，它会把符合依赖关系的对象通过 JavaBean 属性或者构造函数传递给需要的对象。通过 JavaBean 属性注射依赖关系的做法称为设值方法注入(Setter Injection)；将依赖关系作为构造函数参数传入的做法称为构造器注入（Constructor Injection）

实现数据访问层

数据访问层有两个目标。第一是将数据库引擎从应用中抽象出来，这样就可以随时改变数据库—比方说，从微软 SQL 变成 Oracle。不过在实践上很少会这么做，也没有足够的理由未来使用实现数据访问层而进行重构现有应用的努力。

第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变，同时只会影响主应用的一小部分——数据访问层。这一目标是值得的，为了在现有系统中实现它进行必要的重构。

模块与接口重构

依赖注入背后的一个核心思想是单一功能原则（single responsibility principle）。该原则指出，每一个对象应该有一个特定的目的，而应用需要利用这一目的的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。

随时增加单元测试

把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离，以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法继续重构模块是诱惑力的，但这是错误的。

使用服务定位器而不是构造注入

实现控制反转不止一种方法。最常见的办法是使用构造注入，这需要在对象首次被创建是提供所有的软件依赖。然而，构造注入要假设整个系统都使用这一模式，这意味着整个系统必须同时进行重构。这很困难、有风险，且耗时。

aop

概念

aop（Aspect Oriented Programming）,面向切面编程

面向切面编程(也叫面向方面)：AOP 是 OOP 的延续，是 Aspect Oriented Programming 的缩写,是目前软件开发中的一个热点，也是 Spring 框架中的一个重要内容。利用 AOP 可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

扩展资料

aop 与 oop

区别

OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。

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

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

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

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

关系

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

主要功能

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

主要意图

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