看了很多关于IOC和控制反转，依赖注入的文章和博客，但是还是不理解IOC,依赖注入核心是什么，好处主要体现在哪？

[Miracle_lucy]

求哪位大侠，用通俗易懂的语言解释一下

[本拉灯]

IOC多与AOP关联在一起 多数是为了记录日志 好比一个程序调用某个方法出异常了或取到的数据不对。 那需要当时传入的参数是啥，参数的值是啥，出现的异常是啥，返回的结果是啥，一一记录下来 当然你可以在每个方法里自己用代码实现，但随着方法数量的增加，你后面会觉的这么一个一个写太累了，有没有一个简单的方法，只要写一个类就能取到所有执行方法的参数是啥，参数的值是啥，出现的异常是啥，返回的结果并一一记录呢。IOC与AOP就起到了做用。只要实现一个就能得到你所有所写的方法里面执行的记录。

[以专业开发人员为伍]

我不知道你看的是哪些文章。最近这些年的相关网络上的博客，几乎全都是一些意淫的文章，所以会让你感觉混沌。 AOP在2005年比较成熟了，而且有相当多的工具。以后并没有什么发展。因此如果你看到的都是最近这些年的中文博客，而且是结合.net的，我估计你看到了一堆挖坟的人胡扯了一些理论。 简单说，AOP可以看作是跟微软在windows编程领域从（最迟）1993年就一直主张的“事件驱动”控制模式一致的东西，只不过AOP想把它弄到“极致”（因此AOP失去了“恰当”的分寸、反而走向了“反动”）。 AOP是要直接插入人家已经编译好的dll或者exe中，直接给人家每一个对象的属性、方法，都生生插入事件。它们说只要生硬地插入事件，就能“横切”任意系统软件，就能随意监听任何对象属性的改动、随意挂接任何活动的处理，随意改变任何程序的流程。 我曾经做过这方面的事情，费了劲做到了在运行时通过mono的库注入了这些东西之后，我彻底后悔了。因为我们编写的c#程序再也无法调试了，因为所有的定位信息全都很乱了。可是由于借助于AOP的插入，你的代码实际上非常难以调试，你这时候特别需要一个准确调试工具。可是AOP却彻底让你的调试器根本就垮掉了。 后来我认识到，要想进行灵活的事件编程，我们就老老实实地去在源代码里边好好去声明事件（包括实现INofiypropetyChanged、DependencyPropety等等所蕴含的事件通知）就行了，用不着非要再编译完之后再去画蛇添足地编织什么AOP代码（实际上就是破坏代码）。 我对这种东西持否定态度，对应用它的团队和产品持“等着看笑话”态度。

[以专业开发人员为伍]

我为什么先说AOP而不说IOC呢？ 因为我看到一些csdn上的人说的IOC的文章，都是借着IOC的名词，卖AOP的狗皮膏药的！ ioc是Martin Fowler提出的“面向对象5原则”之一。在Kent Beck提出了XP之后受其影响，Fowler将其原来空谈UML的思路，逐步转向敏捷开发（并且主要使用了XP方法来论证敏捷开发的可行性的）思路，于是它将UML里边繁琐的OOP概念进行提炼（就好像Beck提炼软件工程概念成为XP四条基本原则一样）而成为了OO五条原则。 这里的ico只是一个基本原则，并没有讲过多具体的规定。它只是说你进行OOP程序设计时要学会使用类似事件的通知的方式，让事件定义和触发机制的都在服务端预先定义好。此时“客户依赖于服务，而服务不依赖于客户”，因此形成了“倒置”。（而传统的GOF四人帮所写的所谓《设计模式》中的各种模式则往往是客户和服务端相互耦合纠结才能进行通知，所以《设计模式》中有至少一半的模式都非常臃肿和多余） 而我在一些csdn上的人所说的ICO文章里，看到的是挖坟的AOP介绍，它们借着IOC的概念来鼓吹AOP。这就把原本简单的东西给弄得彻底诡异了。

[threenewbee]

很简单。要想体会到它的好处取决于你需要这样一个场景。 你的开发团队有2个以上的人，并且你们有合作关系，而不是个人开发一块，你负责为另一个开发者提供代码，而不是直接编写为最终用户使用的程序。 那么无论IOC还是AOP，它的好处出来了。你希望你写出通用的程序，所谓通用就是你写一个可以给你的同事直接使用的代码。但是因为要适应各种需求，其中某些需要变化的代码需要留给他来写。那么你需要留出“占位符”，或者说“注入点”，也可以说“可扩展点”。你允许别人把他们的代码插入其中。

[以专业开发人员为伍]

如果你不是看的那种介绍AOP各种糟粕的“IOC文章”，那么恭喜你。 简单来说IOC就是说明了“时事比人强”的现实的依赖倒置需求。如果你稍微进入正规的“产品”研发团队，你会遇到那种“以前的组件需要组合到现在的新组件”里的情况。聪明的设计者会在设计组件时预留“事件通知”接口功能，这个事件通知的定义丝毫不需要依赖于被通知对象的类型定义。 比如说你用现成的TextBox控件来完成各种录入，这个控件会通知你的程序“TextChanged”事件。这里你会发现TextBox控件丝毫也不依赖于你调用它的对象的类型。 这是我们现在说的事件机制。 而以前那些愚笨的生搬硬套90年代设计模式的java程序员，则可能以为类似TextBox这样的类型外部必须定义什么 MyListener 之类的自定义“监听者”类型/接口，然后TextBox 类型必须依赖于这个类型/接口而设计，它触发事件是又是去调用 MyListener 的某个方法。于是乎，你看到设计模式用了比150中国老太太的裹脚布还要更臭更长的一大堆相当复杂的代码，不过是模拟了事件机制的两三行代码。 IOC并没有说明这些具体问题，它毕竟是15年前提出的简单原则。它涵盖了我们现在说的.net中的事件（实际上在vb1.0 for dos和vb 1.0 for windows中，事件就只就是现在的这种“sender，EventArgs”接口定义方式） ，也涵盖了设计模式中一大堆又臭又长的模式。它讲出了，许多“高级的设计”都是依赖倒置设计的结果，都是为了开发工具组件（或者叫做中间件）以便复用到新产品中。

[本拉灯]

http://blog.csdn.net/wph_1129/article/details/6118228 这编文章楼主应能看的明白

[Miracle_lucy]

引用 10 楼 sp1234 的回复:

嗯sorry，更正一下，面向对象5原则应该是 Robert Martin 的书中的，我把作者名字弄混了。 那本书你也可以借来看看。这本书获得了图灵《震撼大奖》，不过说实在的，今天看来它似乎缺乏一些深度。但是这本书上毕竟有许多小代码的例子，可以让你对敏捷和OO都能同时入门的许多小例子，还是不错的。

非常感谢!都是货真价实的干活 可能在我目前理解的基础上，是无法吃透你说的这些的 我会留着反复拜读的。

[Miracle_lucy]

引用 5 楼 caozhy 的回复:

很简单。要想体会到它的好处取决于你需要这样一个场景。 你的开发团队有2个以上的人，并且你们有合作关系，而不是个人开发一块，你负责为另一个开发者提供代码，而不是直接编写为最终用户使用的程序。 那么无论IOC还是AOP，它的好处出来了。你希望你写出通用的程序，所谓通用就是你写一个可以给你的同事直接使用的代码。但是因为要适应各种需求，其中某些需要变化的代码需要留给他来写。那么你需要留出“占位符”，或者说“注入点”，也可以说“可扩展点”。你允许别人把他们的代码插入其中。

谢谢！目前对于这些概念理解的也还不够，合适的环境也没有。不过对AOP理解又加深了，不断进步中

[threenewbee]

引用 13 楼 abc8023 的回复:

[quote=引用 5 楼 caozhy 的回复:] 很简单。要想体会到它的好处取决于你需要这样一个场景。 你的开发团队有2个以上的人，并且你们有合作关系，而不是个人开发一块，你负责为另一个开发者提供代码，而不是直接编写为最终用户使用的程序。 那么无论IOC还是AOP，它的好处出来了。你希望你写出通用的程序，所谓通用就是你写一个可以给你的同事直接使用的代码。但是因为要适应各种需求，其中某些需要变化的代码需要留给他来写。那么你需要留出“占位符”，或者说“注入点”，也可以说“可扩展点”。你允许别人把他们的代码插入其中。

谢谢！目前对于这些概念理解的也还不够，合适的环境也没有。不过对AOP理解又加深了，不断进步中[/quote] 跟“概念”没关系。跟你的需求有关。我说了，你必须有这样的场景，否则你根本体会不到为什么要这么做。

[threenewbee]

如果你切实有这样的需要了，就算你没有学过什么叫IoC，，只要你会写程序，你也可以无师自通，琢磨出来怎么做。这并不复杂，只是冠以一个专有名词而已。

[风玉]

引用 6 楼 sp1234 的回复:

简单来说IOC就是说明了“时事比人强”的现实的依赖倒置需求。如果你稍微进入正规的“产品”研发团队，你会遇到那种“以前的组件需要组合到现在的新组件”里的情况。聪明的设计者会在设计组件时预留“事件通知”接口功能，这个事件通知的定义丝毫不需要依赖于被通知对象的类型定义。 比如说你用现成的TextBox控件来完成各种录入，这个控件会通知你的程序“TextChanged”事件。这里你会发现TextBox控件丝毫也不依赖于你调用它的对象的类型。

没看明白. 是不是说TextChanged事件不依赖于 具体的TextBox?

[以专业开发人员为伍]

如果你说的IOC是“面向对象5原则”你的IOC，那么你应该对照另外4个原则来看，对其意义才能明白。 单一功能原则，不过是说一个对象应该主题明确单一。这就跟关系库应该有一个“主键”其实是完全类似的意思。是最基本的意思。 开闭原则和里氏替换原则，不过是用“测试驱动”的角度来解释了对象的继承和多态的机制。 接口隔离原则，对滥用继承和接口做了批判，说明应该具体而准确地从业务出发来定义接口，而不能胡乱为了少写点代码来滥用借接口。 你看上述四个原则，没有一个能够涵盖“组件需要在组合在将来的工程里做为服务，被客户组建进行复用”时、其消息通知机制如何传递的问题。因此才出现了这个第5个原则。这里不得不进行倒置，必须解决“不是正常地A调用B，而是B反过来通知A”的设计原则问题。 但是我前面说过了，我在读那个时代的各种软件工程文章和著作时，没有发觉人家IOC是来谈论AOP的。 我只是在最近才发现csdn上做广告的某些博客，甚至百毒的个别索引页面，把IOC跟AOP扯在一起甚至等同起来。

[以专业开发人员为伍]

其实，IOC原则跟“面向对象”并没有直接的关系。你看它根本不是讲静态的OO改变，同时也不是只有OOP的对象才适合使用IOC。 实际上结构化的代码，完完全全也适合使用IOC思想，来简化软件扩展过程。 实际上IOC跟面向对象概念并没有直接关系。我猜是因为它特别重要、在高级而灵活的系统中特别常见，面向对象前四个原则其实就是把传统UML上的概念从“know-what”层次重新用“know-how”式的语言重新定义了一遍，而如果缺少“依赖倒置”原则则会让“know-how”变得缺乏辨证法的思想而容易变得僵化，所以把一个原本在面向对象系统设计中具体的工程技术方法提升为面向对象原则的高度来说。 我建议你在了解了IOC并且研究它10年8年的同时，花几天时间看一下然后就忘记那些AOP，这就够了。

[以专业开发人员为伍]

嗯sorry，更正一下，面向对象5原则应该是 Robert Martin 的书中的，我把作者名字弄混了。 那本书你也可以借来看看。这本书获得了图灵《震撼大奖》，不过说实在的，今天看来它似乎缺乏一些深度。但是这本书上毕竟有许多小代码的例子，可以让你对敏捷和OO都能同时入门的许多小例子，还是不错的。