注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

天涯倦客的博客

祝福你朋友永远快乐!

 
 
 

日志

 
 

设计原则:为什么需要“IOC”  

2013-05-03 13:00:47|  分类: 设计模式 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

背景知识

控制反转

反转传统的控制逻辑,常见的传统控制逻辑有:

一、客户类型负责创建依赖。反转后的结构是:由IOC负责创建。

二、客户类型调用框架。反转后的结果是:框架调用客户类型。

依赖注入

客户类型需要显式的声明其依赖,不要在客户类型中管理依赖的创建。

IOC

中文可以翻译为:控制反转容器或依赖注入容器。

参考资料

Inversion of Control Containers and the Dependency Injection pattern

InversionOfControl

设计原则:我是如何使用“依赖注入”的

.NET:在ASPX、ASHX和MVC中使用IOC容器(菜鸟必看)

DDD:管理“工作单元实例”的两种模式

为什么要使用IOC容器?

从对象的角度思考什么系统

系统是由一张对象图组合而成,这些对象通过彼此之间的协作(发送消息)来完成需求。概括如下:

系统 = 对象图 

基于类的语言如何表示系统

毫无疑问,在基于类的语言中:系统 = 类型定义 + 对象图(如何实例化)

考虑一个三层架构中的类图

如何创建这个类图的对象图?

简单的来说,我们有两种思路:

一、客户类型负责new依赖类型。这样做的结果是:

    1. 类图就是对象图,编译时绑定。
    2. 需要手工管理依赖的生命周期。
    3. 很难做单元测试。
    4. 很难升级和维护,比如:引入了一个新的子类,你要到处修改new的代码。

二、采用IOC容器new依赖类型。这样做的结果是:

    1. 类图不一定是对象图,运行时绑定。
    2. IOC容器挂自动管理的生命周期。
    3. 容易做单元测试。
    4. 容易升级和维护。

备注

有人说IOC的注册太麻烦,比new还麻烦,针对这个问题的思路是:“根据约定自动注册”,我就采用这种方式。

 

★快速评价★不错,支持一下! 
★快速评价★垃圾,还需努力!

  评论这张
 
阅读(433)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017