ioc和aop的区别？
1 IoC，（Inverse of Control）控制反转，其包含两个内容：其一是控制，其二是反转。在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决。这个第三方指的就是Spring的容器。IoC另解，依赖注入（Dependency Injection），调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。
2 aop，面向切面编程(也叫面向方面)：Aspect Oriented Programming(AOP),是目前软件开发中的一个热点，也是Spring框架中的一个重要内容。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。
3 AOP是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面（方面）编程。主要的功能是：日志记录，性能统计，安全控制，事务处理，异常处理等等。
4 主要的意图是：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改 变这些行为的时候不影响业务逻辑的代码。
扩展资料：
IoC是一个很大的概念,可以用不同的方式实现。其主要形式有两种：
依赖查找：容器提供回调接口和上下文条件给组件。EJB和Apache Avalon 都使用这种方式。这样一来，组件就必须使用容器提供的API来查找资源和协作对象，仅有的控制反转只体现在那些回调方法上（也就是上面所说的 类型1）：容器将调用这些回调方法，从而让应用代码获得相关资源。
依赖注入：组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。容器全权负责的组件的装配，它会把符合依赖关系的对象通过JavaBean属性或者构造函数传递给需要的对象。通过JavaBean属性注射依赖关系的做法称为设值方法注入(Setter Injection)；将依赖关系作为构造函数参数传入的做法称为构造器注入（Constructor Injection）
实现数据访问层
数据访问层有两个目标。第一是将数据库引擎从应用中抽象出来，这样就可以随时改变数据库—比方说，从微软SQL变成Oracle。不过在实践上很少会这么做，也没有足够的理由未来使用实现数据访问层而进行重构现有应用的努力。
第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变，同时只会影响主应用的一小部分——数据访问层。这一目标是值得的，为了在现有系统中实现它进行必要的重构。
模块与接口重构
依赖注入背后的一个核心思想是单一功能原则（single responsibility principle）。该原则指出，每一个对象应该有一个特定的目的，而应用需要利用这一目的的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。
随时增加单元测试
把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离，以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法继续重构模块是诱惑力的，但这是错误的。
使用服务定位器而不是构造注入
实现控制反转不止一种方法。最常见的办法是使用构造注入，这需要在对象首次被创建是提供所有的软件依赖。然而，构造注入要假设整个系统都使用这一模式，这意味着整个系统必须同时进行重构。这很困难、有风险，且耗时。
AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。
而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。
上面的陈述可能过于理论化，举个简单的例子，对于“雇员”这样一个业务实体进行封装，自然是OOP/OOD的任务，我们可以为其建立一个“Employee”类，并将“雇员”相关的属性和行为封装其中。而用AOP设计思想对“雇员”进行封装将无从谈起。
同样，对于“权限检查”这一动作片断进行划分，则是AOP的目标领域。而通过OOD/OOP对一个动作进行封装，则有点不伦不类。
换而言之，OOD/OOP面向名词领域，AOP面向动词领域。
面向过程编程离我们已经有些遥远，面向对象编程正主宰着软件世界。当每个新的软件设计师都被要求掌握如何将需求功能转化成一个个类，并且定义它们的数据成员、行为，以及它们之间复杂的关系的时候，面向切面编程（Aspect-Oriented Programming，AOP）为我们带来了新的想法、新的思想、新的模式。
如果说面向对象编程是关注将需求功能划分为不同的并且相对独立，封装良好的类，并让它们有着属于自己的行为，依靠继承和多态等来定义彼此的关系的话；那么面向切面编程则是希望能够将通用需求功能从不相关的类当中分离出来，能够使得很多类共享一个行为，一旦发生变化，不必修改很多类，而只需要修改这个行为即可。
面向切面编程是一个令人兴奋不已的新模式。就开发软件系统而言，它的影响力必将会和有着数十年应用历史的面向对象编程一样巨大。面向切面编程和面向对象编程不但不是互相竞争的技术而且彼此还是很好的互补。
面向对象编程主要用于为同一对象层次的公用行为建模。它的弱点是将公共行为应用于多个无关对象模型之间。而这恰恰是面向切面编程适合的地方。有了 AOP，我们可以定义交叉的关系，并将这些关系应用于跨模块的、彼此不同的对象模型。AOP 同时还可以让我们层次化功能性而不是嵌入功能性，从而使得代码有更好的可读性和易于维护。它会和面向对象编程合作得很好。
1、定义不同
ioc：控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。
aop：面向切面编程，通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。
2、功能不同
ioc：Class A中用到了Class B的对象b，一般情况下，需要在A的代码中显式的new一个B的对象。
采用依赖注入技术之后，A的代码只需要定义一个私有的B对象，不需要直接new来获得这个对象，而是通过相关的容器控制程序来将B对象在外部new出来并注入到A类里的引用中。而具体获取的方法、对象被获取时的状态由配置文件（如XML）来指定。
aop：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改变这些行为的时候不影响业务逻辑的代码。
3、实现项目不同
ioc：现有的框架实际上使用以下三种基本技术的框架执行服务和部件间的绑定：
类型1 (基于接口): 可服务的对象需要实现一个专门的接口，该接口提供了一个对象，可以重用这个对象查找依赖(其它服务)。早期的容器Excalibur使用这种模式。
类型2 (基于setter): 通过JavaBean的属性(setter方法)为可服务对象指定服务。HiveMind和Spring采用这种方式。
类型3 (基于构造函数): 通过构造函数的参数为可服务对象指定服务。PicoContainer只使用这种方式。HiveMind和Spring也使用这种方式。
aop：AOP是一个概念，并没有设定具体语言的实现，它能克服那些只有单继承特性语言的缺点（如Java），AOP具体实现有以下几个项目：
AspectJ (TM)： 创建于Xerox PARC. 有近十年历史，成熟
缺点：过于复杂；破坏封装；需要专门的Java编译器。
动态AOP：使用JDK的动态代理API或字节码Bytecode处理技术。
基于动态代理API的具体项目有：
JBoss 4.0 JBoss 4.0服务器
基于字节码的项目有：
aspectwerkz ，spring
参考资料：百度百科-AOP
参考资料：百度百科-ioc
二者没有联系。ioc是控制反转，aop是面向事务。
IOC就是一个生产和管理bean的容器就行了，原来需要在调用类中new的东西，现在都是通过容器生成，同时，要是产生的是单例的bean，他还可以给管理bean的生命周期。
AOP技术它利用一种称为"横切"的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为"Aspect"，即切面。所谓"切面"，简单说就是那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块之间的耦合度，并有利于未来的可操作性和可维护性。
扩展资料：
解释Spring中的IOC。
IOC:Inversion of Control控制反转，也叫（Dependency Injection）依赖注入， dao接口的实现不再是业务逻辑层调用工厂类去获取，而是通过容器（spring）来自动的为我们的业务层设置Dao的实现类，这样整个过程就反过来，以前是我们业务层主动去获取dao，而现在是dao主动被设置到业务逻辑层中来了，这个也就是反转控制的由来。通过IOC，我们就可以在不修改任何代码的情况下，无缝地实现数据库的换库迁移。
解释Spring中的AOP。
AOP面向切面编程将程序中的交叉业务逻辑（比如安全，日志，事务），封装成一个切面，然后注入到目标业务逻辑中去。
比如：很多方法都可能会抛异常，你要记录这个异常到日志中去，可以写个拦截器，在这个类中记录日志，在spring.xml中配置一个记录这些日志的方法的拦截器，在这个方法执行后调用这个拦截器，记录日志。这样就不用每次抛异常都要手动记录日志。
IoC：（Inverse of Control）控制反转，其包含两个内容：其一是控制，其二是反转。在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决。这个第三方指的就是Spring的容器。
IoC另解，依赖注入（Dependency Injection），调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。
aop：面向切面编程(也叫面向方面)：Aspect Oriented Programming(AOP),是目前软件开发中的一个热点，也是Spring框架中的一个重要内容。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。
AOP是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面（方面）编程。主要的功能是：日志记录，性能统计，安全控制，事务处理，异常处理等等。
主要的意图是：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改 变这些行为的时候不影响业务逻辑的代码。
扩展资料：
控制反转：同义词 ioc（IOC）一般指控制反转。
控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI），还有一种方式叫“依赖查找”（Dependency Lookup）。
通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。
起源：早在2004年，Martin Fowler就提出了“哪些方面的控制被反转了？”这个问题。他总结出是依赖对象的获得被反转了，因为大多数应用程序都是由两个或是更多的类通过彼此的合作来实现企业逻辑，这使得每个对象都需要获取与其合作的对象（也就是它所依赖的对象）的引用。
如果这个获取过程要靠自身实现，那么这将导致代码高度耦合并且难以维护和调试。
技术描述：Class A中用到了Class B的对象b，一般情况下，需要在A的代码中显式的new一个B的对象。
采用依赖注入技术之后，A的代码只需要定义一个私有的B对象，不需要直接new来获得这个对象，而是通过相关的容器控制程序来将B对象在外部new出来并注入到A类里的引用中。而具体获取的方法、对象被获取时的状态由配置文件（如XML）来指定。
参考资料来源：百度百科：控制反转
aop，面向切面编程(也叫面向方面)：Aspect Oriented Programming(AOP),是目前软件开发中的一个热点，也是Spring框架中的一个重要内容。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。 AOP是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面（方面）编程。主要的功能是：日志记录，性能统计，安全控制，事务处理，异常处理等等。 主要的意图是：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改 变这些行为的时候不影响业务逻辑的代码。
