Ioc容器应用浅析

前言

    Ioc(Inversion of Control)中文译名控制反转, 一个很流行的词汇, 虽然dotNet社群谈论的仍然比较少, 但随着dotNet平台下的一些Ioc组件的成熟, 这个概念也慢慢深入人心了, 本文并不抓住概念大谈特谈, 而是从一个简单的示例以平实的语言和大多开发者所遇到的问题来简单分析下Ioc容器能为我们带来什么及如何更好使用.

    Ioc(控制反转)是一个目标, 他要求我们设计好的类不由我们自己控制而由系统控制, 这样可以使系统变得更加独立, 从而强壮易于扩展维护, 实现这个目标有一些手段如DI(Dependency Injection), Service Locator等, 但这对于用户并不重要, 我们关键要的是这个目标. 而Ioc容器正是帮助我们实现这一目标的组件. 一般他们都使用了DI做为实现手段. 概念就谈到这里为止, 太多了容易让人头晕.

    dotNet下的Ioc容器也有不少了, 下面以Castle Ioc容器为例说明, 代码为了清晰起见省略了很多东西仅仅起示例作用并不代表实际如此.


面临的问题

    需求是这样的(以下情节纯属虚构, 如有雷同纯属巧合), 项目需要一个向用户发送email做为提醒的功能, 因此项目中包含一个NotifyModule的类用来做提醒功能, 而真正的email发送功能使用的是我开发的很烂的一个称为第三方组件的SimonwEmailSender完成(后来领导发现了我写的果然很烂于是决定使用MSEmailSender), SimonwEmailSender是标准服务接口IEmailSender实现. 下面的注释中标识了4中不同的email组件的调用方法.

public class NotifyModule
    {
        //1. SimonwEmailSender sender = new SimonwEmailSender();
        //2. IEmailSender sender = new SimonwEmailSender();
        //3. IEmailSender sender = EmailSenderFactory.Create();
        //4. IEmailSender sender = CommonService.Container.Resolve<IEmailSender>();

        public void SendMessage()
        {
            //create your email then send
            sender.Send(new Email());
        }
    }

下面是支持NotifyModule的其他类代码

public class Email
    {
        private string receiver;
        private string message;
        //
    }

    public interface IEmailSender
    {
        void Send(Email mail);
    }

    public class SimonwEmailSender : IEmailSender
    {
        public void Send(Email mail)
        {
            //implement IEmailSender.Send
        }
    }

    public class EmailSenderFactory
    {
        public static IEmailSender Create()
        {
            //1. return new SimonwEmailSender();
            //2. return Activator.CreateInstance(), use Reflection create IEmailSender from config file or assembly
        }
    }

    public class CommonService
    {        
        public static readonly IWindsorContainer Container;

        static CommonService()
        {
            //1. Container.AddComponent("", typeof(IEmailSender), typeof(SimonwEmailSender));
            //2. Container = new WindsorContainer(new XmlInterprete
        }
    }

获取组件的方式

下面分别来分析下NotifyModule中的4中不同的获取组件的方式.

第一种, SimonwEmailSender sender = new SimonwEmailSender();

    这样个方式非常直观, 但造成了项目对外部组件的依赖, 更为严重的是项目中或许会有人使用仅仅属于SimonwEmailSender的方法而并非只是IEmailSender定义的标准服务, 当项目需要更换组件的时候不对代码大动干戈是不可能了. 因此每当你写下这样一行代码你就要仔细考虑清楚未来是否会变更, 如果预计到会改变一定不要这样写, 会给未来的扩展和维护带来无穷的后患.

第二种, IEmailSender sender = new SimonwEmailSender();

    既然这是一个变动很大的组件, 为了限定用户程序员可能不规范的使用, 采用标准服务接口IEmailSender 来声明对象, 这样用户就没法去调用只属于SimonwEmailSender自己特有的方法了, 更换组件的时候省心不少. 但更改代码仍然无法避免, 实例化的时候使用了具体的组件类. 相信这也是不少初学OO的朋友所遇到的问题, 接口不是消除了依赖了么? 但依赖变化的时候还要改代码, 依然没什么优势嘛. 于是引出了下一种方式.

第三种, IEmailSender sender = EmailSenderFactory.Create();

    工厂, 在Ioc容器出现以前被广泛应用于各种项目中, 甚至有这样的说法, 没有工厂的项目就不是好项目, 虽然有点偏激但却有一定道理. 以EmailSenderFactory.Create()来推迟了组件的实例化, 这样看起来无论声明和实例化都脱离了对具体组件的依赖, 但具体的组件终究还是要实例化, 在哪里呢? 看看工厂的实现, 在EmailSenderFactory.Create()中有2中实现方案.
    方案一中直接return new SimonwEmailSender(); 这效果和上一种方式没啥本质区别了, 到头来换了组件还得修改代码. 再看方案二, 读取配置文件中的信息, 用反射来实例化组件, 彻底的把具体组件的信息从代码中剥离到了配置文件中, 更换组件时仅需要修改配置文件. 接口终于完全的发挥出了他的威力, 但这种方式造成大量不统一的工厂产生, 而组件之间常会有着各种不同的依赖关系, 使得工厂的复杂度大大增加, 实现与管理这些工厂又成了新的问题, Ioc容器就在这样的需求下出现了.

第四种, IEmailSender sender = CommonService.Container.Resolve<IEmailSender>(); 

    看起来和通过工厂获取实例差不多, 但却不是同一个东西, CommonService.Container即是我简易包装的一个Castle Ioc容器, 具体的使用下面会详细介绍, 现在你只需要知道我从容器中来获取组件的实例. Ioc容器是一个可复用的组件管理工具, 可以很方便的引入到项目中, 通过向其中简单的注册需要被管理的组件后, 他便能管理组件和他们之间的关系. 这样避免了大量的工厂出现, 更进一步的减少了代码量, 提高了项目的扩展维护性.


使用Ioc容器

    Ioc容器负责组件对象管理, 因此使用时包括两个步骤, 在容器中注册组件与从容器中取出组件. 其方法也根据具体项目的不同需求而不同.

组件注册

    组件注册就是把组件放入到容器中以便容器管理, 具体方法主要是硬编码注册和配置文件注册.参见类CommonService, Container是对容器的引用, 在构造函数中有2种注册方式.

第一种, 硬编码注册方式, Container.AddComponent("MailCom", typeof(IEmailSender), typeof(SimonwEmailSender));  

    存在的问题还是那样, 使项目对具体的组件造成了直接依赖, 因为这里直接引用了SimonwEmailSender类型, Ioc容器的优势没有完全发挥出来. 但这样也有这样的优点, 注册过程非常简便, 虽然更换组件需要修改代码但修改的地方非常集中, 因此对于一些规模小或组件繁多且不易变更的项目很有优势.

第二种, 配置文件方式, Container = new WindsorContainer(new XmlInterpreter());

    XmlInterpreter使用默认的App.Config文件中的组件配置来实例化容器, 他会自动解释xml配置文件将组件注册入容器. 当然你可以也自定义组件配置格式或指定xml配置文件. 这个方式最为灵活, 你可以方便的修改更换组件, 但配置就较麻烦了, 尤其组件很多的情况下, 而且无法在编译时发现错误, 只能在运行时发现, 调试起来比较困难.

<components>
            <component id="MailCom" 
              service="TestProject.IEmailSender, TestProject" 
                type="TestProject.SimonwEmailSender, TestProject" />
</components>

    组件配置节点中service需要指明接口类型和所在程序集, type中需要指明具体组件类型和所在程序集, id指索引的名称, 这是一个信息完整的配置节点, 容器可以完全通过这些信息实例化组件因此只需Container = new WindsorContainer(new XmlInterpreter());一句话就能完成注册工作. 这时的项目已经完全脱离了对具体组件的依赖, 你在代码中看不到任何具体组件的影子.


获取组件

    注册完成后我们关心该如何拿到这些组件并使用他们. Ioc容器同样提供了2种方式, 从容器中直接取出与通过容器的注入方式装配.

第一种, 从容器中直接获取, IEmailSender sender = CommonService.Container.Resolve<IEmailSender>();

    这就是NotifyModule中第四种方式, 通过以上的注册后你可以直接从容其中得到服务的实例. 不过你发现了么, 虽然解除了对组件的依赖, 但现在开始对容器依赖了, 即便容器是个独立可复用的组件, 这种方式一多也会让人很不爽, 起码不优雅. 容器不是能管理组件么, 利用这个特性可以大大简化代码.

第二种, 注入, 我修改了NotifyModule类, 代码如下

public class NotifyModule
{
    private IEmailSender sender;

    //Inject method 1
    public NotifyModule(IEmailSender sender)
    {
        this.sender = sender;
    }

    //Inject method 2
    public IEmailSender EmailSender
    {
        set
        {
            this.sender = value;
        }
    }

    public void SendMessage()
    {
        //create your email then send
        sender.Send(new Email());
    }
}

并在配置文件中加入以下配置注册NotifyModule到容器中

<components>
            <component id="NotifyModule" 
              service="TestProject.NotifyModule, TestProject" 
                type="TestProject.NotifyModule, TestProject" />
</components>

    所谓注入就是你不用亲自去实例化你的对象(例如上面那个从容器中获得实例的例子)而由容器去为你完成. 享受这强大功能的前提是所有组件必须纳入容器内.现在NotifyModule也纳入了容器的管理, 你只需要为你的类设置一个接收器, 然后里面就可以肆意的去使用了根本不用操心他的实例化问题. 新修改的NotifyModule类中有2种注入组件的方法也就是接收器分别标记了Inject method 1 通过构造函数注入 和 Inject method 2 通过属性注入他们不需要同时存在, 只代表了2种不同的注入方式.

    通过构造函数注入, 非常清晰, 使你一眼就能看到你的类中在使用那些组件, 我个人偏向这种方式. 但有时候构造的参数较多, 并且有的参数可选时, 使用属性注入方式更好些. 属性注入方式可以更好的保留类业务逻辑的本意, 不会在构造时加入那些不需要业务逻辑关心的参数. 总之各有各的好处, 灵活处理吧. 通过透明的注入方式最大程度的减少了项目对容器的依赖, 若要完全摆脱这样的依赖依然需要使用容器的服务接口通过反射来实例化容器, 不过我认为大多数情况下这么做没什么必要.

《两个个很形象的依赖注入的比喻》
何谓控制反转（IoC = Inversion of Control），何谓依赖注入（DI = Dependency Injection）？一直都半懂不懂，今天看到两个比喻，觉得比较形象。
IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓"控制反转"的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
正在业界为IoC争吵不休时，大师级人物Martin Fowler也站出来发话，以一篇经典文章《Inversion of Control Containers and the Dependency Injection pattern》为IoC正名，至此，IoC又获得了一个新的名字："依赖注入 （Dependency Injection）"。相对IoC 而言，"依赖注入"的确更加准确的描述了这种古老而又时兴的设计理念。从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。
一：
再看上例中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记本而言，只是将用户指定的数据发送到USB接口，而这些数据何去何从，则由当前接入的USB设备决定。在USB设备加载之前，笔记本不可能预料用户将在USB接口上接入何种设备，只有USB设备接入之后，这种设备之间的依赖关系才开始形成。
对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows操作系统）将依赖关系（笔记本依赖USB设备进行数据存取）注入到组件中（Windows文件访问组件）。这就是依赖注入模式在现实世界中的一个版本。
很多初学者常常陷入"依赖注入，何用之有？"的疑惑。想来这个例子可以帮助大家简单的理解其中的含义。依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。将USB接口和之前的串/并、PS2接口对比，想必大家就能明白其中的意味。
二：
首先想说说IoC（Inversion of Control，控制倒转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。
　　那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。