转载

IoC概要

控制反转基本上说的是功能调用者与功能实现者之间应该如何交互,即二者之间没有直接的强耦合(调用者new一个被调用者),而是都依赖同一个抽象,这个抽象规定了二者交互的接口。反转的意思是实现了依赖倒置,在程序中高层不是根据低层的接口来写调用,而是倒过来,高层根据需要定义接口,低层向上负责实现这个接口。这体现了自顶向下的设计思路和自底向上的实现方法,使软件代码具有自然的可读性,以及关注点的分离。

IoC容器是实现IoC的框架,具体包括了接口与实现的关系配置功能和获取实现对象的功能,其中获取实现对象的功能大体对应了设计模式中的工厂模式,下面简要分析对比一下原生态new调用,工厂模式调用,和IoC容器调用:

为了对比方便,在分析原生态调用之前先假设一个前提,那就是功能被某个具体的类实现了。直接调用有最好的性能,但可维护性和可测试性很差,比如想要修改一个功能的实现,有2种实现方法A和B,A是一个巨大的改变,也就是适合于新写一个类来实现,B是一个较小的改变,可以直接修改类的内部结构。假如用A方案,而系统又有多处引用,甚至还需要注意构造函数及其参数的变化,那么意味着多个修改量,这违背了TRY原则,对开发是一个负担。假如使用了B方案,那就要注意内部实现的改变是否会影响外部环境,是否有使修改不封闭的地方。而可测试性就不必多说了,因为是直接new的,所以无法Moq,导致无法完美的做单元测试。

当直接用工厂模式时,需要先做抽象,即把功能代码分成抽象和实现两部分,功能调用者调用工厂提供的方法获得具体的实现对象,这确保了系统是面向接口编程的,帮助编程者写出高内聚低耦合的逻辑。同时也引发了一些问题,比如可能有较多的工厂类需要维护,功能调用者与工厂类之间又有耦合,假如用抽象工厂模式来解耦,又需要增加配置文件的内容。

使用IoC容器可以非常方便的定义符合某个接口的实现对象的获取策略,能够对对象的生命周期做配置和管理,而无需编写和维护工厂代码,拥有最佳的可维护性和可测试性。

原文  http://www.cnblogs.com/bighuiwolf/p/5135065.html
正文到此结束
Loading...