IoC 研究与心得

   IoC:Inversion of Control,中文译为控制反转。其本质上是使用反射，让项目通过后引用的方式执行动作。

   下面我来举一个简单的例子来说明传统的开发方式和IoC开发方式的不同：

    例子：   有一个项目，A网站，实现一个用户登录的功能。以.net来实现，java的则类似。

 

   传统的做法，如果要考虑到分离，则一般是如下的做法：

                     创建一个类库项目，定义IUser.cs的interface，声明bool Login(string username,string password);

                     创建一个实现方法的类库项目，定义User.cs的class，并且继承IUser，实现Login方法。

                     在网站项目中，引用IUser和User所在的dll。然后直接调用User类所定义的Login方法来实现登录。

 

                     以上是实现登录的方法之一，还可以不用IUser这一层，直接在User.cs中实现Login方法，或者直接把Login作为static方法来声明并且实现。又或者直接省掉接口和实现功能，直接在项目中完成所有登录功能的编码。如下图所示：

    传统的方法中，项目与接口和实现功能的模块有直接的关联。如果是少了接口这一层，也是和实现功能这一层有直接关联。

 

    IoC方式下的开发，则实现方法如下：

         创建一个类库项目，定义IUser.cs的interface，声明bool Login(string username,string password);

         创建一个实现方法的类库项目，定义User.cs的class，并且继承IUser，实现Login方法。

        在网站项目中，引用IUser所在的dll。然后通过IoC容器，得到IUser的对象。使用IUser的方法来实现登录功能。

   如下图所示：

此时，项目和实现功能的模块没有任何直接联系，他们都是通过接口来做间接联系的。

 

    一般来说，项目和外部的直接联系越少，则越轻便。比如，一个项目是由至少两个人同时合作开发的话，传统方式则很容易出现“堵车”现象，如果负责开发项目部分的人员不想等，那么他可能直接在项目中完成所有功能的编码（这不，一个人完成得拉，其他人玩泥沙去）。显然，实现功能越绑死在项目，则将来一旦环境出现了某些变化，则必须将项目打开来修改，重新编译和重新发布整个网站，比如换了一种数据库。不过，庆幸的事是这种情况也很少发生（如果一旦发生，程序员有活干）。这里主要是从多人合作的角度出发，传统开发方式则更容易把项目和实现功能绑定一体，可能会迫使合作变成了按照项目的功能划分区域给不同的程序员去实现。

 

   IoC的好处在于项目和实现功能彻底的分离，这就带来了一个好处，负责项目部分的人员则能够快速的写出所需的接口方法（甚至直接在详细设计说明书中“唰唰”几下出来所有需要的接口方法），他也不用去实现，直接把所需要的接口放在接口项目中，另外一个人则把接口项目引用过来，直接按照接口方法的注释去实现功能业务。此时，要求项目人员写出接口方法的时候，必须要大量说明该方法实现的功能，参数的意义，以及返回值的格式要求等等。说明越详细越不用口头沟通。与此同时，还可以由项目人员本身或者其他人来虚构一个实现项目出来，这个项目则不用去真正实现任何业务，其用途是让项目能够运行起来。将来只需等实现功能的人员完成了所有接口方法的功能后发布，项目则自动的能够跑出正确的结果。

  

   在IIS中，如果web.config或者bin目录中，如果他们有任何的变动，则网站自动重启。IoC可以做到把功能实现的dll放到其他文件夹中，比如App_Data中，功能实现模块重新发布也不会引起原来网站的重启。