求科普控制反转在.net中实现过程！

[丸子殿下]

前一阵子一家网络公司的技术跟我沟通，说他怎么怎么使用控制反转减少了耦合性，说什么不用mvc不用什么模式模式，瞬间我就搞不清楚开发模式到底是什么东西了，求大神科普！

[丸子殿下]

大神啊大神啊 你在哪里呢

[rtdb]

在敏捷软件开发里 控制反转简单理解就是面向接口编程。 敏捷软件开发认为大多数设计模式是过度设计的，是没必要的 这本书超好： 《敏捷软件开发，原则，模式和实践》

[天下如山]

控制反转

[丸子殿下]

引用 2 楼 rtdb 的回复:

在敏捷软件开发里 控制反转简单理解就是面向接口编程。 敏捷软件开发认为大多数设计模式是过度设计的，是没必要的 这本书超好： 《敏捷软件开发，原则，模式和实践》

我以前工作的公司，做.net网站的，我在那里做的工作就是用同一个后台，支持不同的前台代码，model包里写的是实体类，还有dal包和bll包，包括一个DBulity包还有一个ui的包，我不知道我用的这个后台是不是有控制反转的概念？

[丸子殿下]

引用 3 楼 sibiyellow 的回复:

控制反转

求解释啊 大神

[rtdb]

引用 4 楼 wanziidianxia 的回复:

[quote=引用 2 楼 rtdb 的回复:] 在敏捷软件开发里 控制反转简单理解就是面向接口编程。 敏捷软件开发认为大多数设计模式是过度设计的，是没必要的 这本书超好： 《敏捷软件开发，原则，模式和实践》

我以前工作的公司，做.net网站的，我在那里做的工作就是用同一个后台，支持不同的前台代码，model包里写的是实体类，还有dal包和bll包，包括一个DBulity包还有一个ui的包，我不知道我用的这个后台是不是有控制反转的概念？ [/quote] 你想的太复杂了。 你们的系统，简单说，就先分前台和后台，先根据需求定义接口（例如一个WEB SERVICE）。 然后前台调用接口完成UI需求，后台实现接口提供数据。 前台完全不关心后台的什么dal包和bll包。 后台只要能实现接口需要的功能就行，一开始根本不需要分层分包什么的。 实在需要分层分包了，还是一样，定义接口先 敏捷开发的自动测试和迭代开发，可以让你随时修改代码以适应变化， 只要用最简单的方式完成当前的需要就好， 跟本不需要预先做复杂的设计以适应未来的需求。

[以专业开发人员为伍]

其实它是很简单、很基础的想法：http://bbs.csdn.net/topics/390817672

[以专业开发人员为伍]

依赖倒置原则，它基本上可以换一个名词叫做“分层次设计原则”，就是说你的大系统应该分出层次。一旦分层了，如果过了一段时间你突然“脑袋短路”了、硬要让底层依赖于上层，这时候怎么办？ 这时候需要使用“依赖倒置”的编码模式。

[winnowc]

控制反转（也就是IoC）最简单的理解就是所谓好莱坞原则："Don't call us, we'll call you"。广义上说，回调、事件、调度器、工厂模式、策略模式等等都属于IoC的实现方式。（IoC维基百科） 不过狭义上，说IoC一般都特指IoC/DI，也就是控制反转/依赖注入。DI这个概念是Martin Fowler在2004年提出的（原文），就是把对象之间的依赖关系由IoC容器统一管理，在对象的创建过程之中或者之后，负责将其依赖一并解析创建，并注入对象。（DI维基百科） .NET上常用IoC/DI框架有Ninject、Unity、Autofac、StructureMap、Spring.Net 上面也就是简单说一下，具体的东西可以自己搜索。至于你听到的“控制反转减少了耦合性，说什么不用mvc不用什么模式模式”。前半句没错，IoC是降低了耦合，但是后半句是胡说。首先mvc是应用模式/框架，和IoC这种更基础的模式/框架就没有互相替代的可能，而是ASP.NET MVC框架支持做IoC/DI（一个官方使用Unity做mvc的DI的例子）。至于设计模式，IoC/DI框架可以说是一个万能factory，实现了部分设计模式中的“创建”类别模式的功能，然后一般都具备模块化的概念，但是其它模式不是它能直接实现的。 多说一句，设计模式看多了容易滥用。多看多写代码，在实际的代码中理解别人的理念，完善自己的方法才是正道。

[一片冰心在玉壶]

百度一下 IOC 就好了

[丸子殿下]

百度过了，还是谢谢你的回答

[丸子殿下]

引用 9 楼 github_22161131 的回复:

控制反转（也就是IoC）最简单的理解就是所谓好莱坞原则："Don't call us, we'll call you"。广义上说，回调、事件、调度器、工厂模式、策略模式等等都属于IoC的实现方式。（IoC维基百科） 不过狭义上，说IoC一般都特指IoC/DI，也就是控制反转/依赖注入。DI这个概念是Martin Fowler在2004年提出的（原文），就是把对象之间的依赖关系由IoC容器统一管理，在对象的创建过程之中或者之后，负责将其依赖一并解析创建，并注入对象。（DI维基百科） .NET上常用IoC/DI框架有Ninject、Unity、Autofac、StructureMap、Spring.Net 上面也就是简单说一下，具体的东西可以自己搜索。至于你听到的“控制反转减少了耦合性，说什么不用mvc不用什么模式模式”。前半句没错，IoC是降低了耦合，但是后半句是胡说。首先mvc是应用模式/框架，和IoC这种更基础的模式/框架就没有互相替代的可能，而是ASP.NET MVC框架支持做IoC/DI（一个官方使用Unity做mvc的DI的例子）。至于设计模式，IoC/DI框架可以说是一个万能factory，实现了部分设计模式中的“创建”类别模式的功能，然后一般都具备模块化的概念，但是其它模式不是它能直接实现的。 多说一句，设计模式看多了容易滥用。多看多写代码，在实际的代码中理解别人的理念，完善自己的方法才是正道。

万分感谢，谢谢你很用心的回答

[丸子殿下]

引用 8 楼 sp1234 的回复:

依赖倒置原则，它基本上可以换一个名词叫做“分层次设计原则”，就是说你的大系统应该分出层次。一旦分层了，如果过了一段时间你突然“脑袋短路”了、硬要让底层依赖于上层，这时候怎么办？ 这时候需要使用“依赖倒置”的编码模式。

谢谢大神的回答，受益颇多

[threenewbee]

依赖注入其实没有那么复杂，用简单的3行代码就可以展示： 原先的代码 void Main() { foo(); } void foo() { bar(); } void bar() { ... } 很明显，foo依赖bar 要让foo和bar解耦可以这样： void Main() { foo(new Action(bar)); } void foo(Action action) { action(); } void bar() { ... } 现在foo调用的是一个委托(action)，而不是真实的bar 而主程序通过将bar作为参数传给了foo，让action=bar，才让foo和bar联系了起来。 主程序在这里就是相当于依赖注入

[丸子殿下]

引用 12 楼 caozhy 的回复:

依赖注入其实没有那么复杂，用简单的3行代码就可以展示： 原先的代码 void Main() { foo(); } void foo() { bar(); } void bar() { ... } 很明显，foo依赖bar 要让foo和bar解耦可以这样： void Main() { foo(new Action(bar)); } void foo(Action action) { action(); } void bar() { ... } 现在foo调用的是一个委托(action)，而不是真实的bar 而主程序通过将bar作为参数传给了foo，让action=bar，才让foo和bar联系了起来。 主程序在这里就是相当于依赖注入

看完您的例子一下子就懂了 谢谢