标签：

    依赖就是有联系，有地方使用到它就是有依赖它，一个系统不可能完全避免依赖。

    Robert Martin大师提出了面向对象设计原则----依赖倒置原则： 　　

• A. 上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。 　
• B. 抽象不能依赖于具体，具体依赖于抽象。

    理解：A.上层是使用者，下层是被使用者，这就导致的结果是上层依赖下层了，下层变动了，自然就会影响到上层了，导致系统不稳定，甚至是牵一发而动全身。那怎么减少依 赖呢？就是上层和下层都去依赖另一个抽象，这个抽象比较稳定，整个就来说就比较稳定了。

           B.面向对象编程时面向抽象或者面向借口编程，抽象一般比较稳定，实现抽象的具体肯定是要依赖抽象的，抽象不应该去依赖别的具体，应该依赖抽象。

      控制反转IoC是Inversion of Control的缩写，是说对象的控制权进行转移，转移到第三方，比如交给了IoC容器，它就是一个创建工厂要什么对象就给你什么对象，有了IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器来建立它们之间的关系。控制反转:   调用者不再创建被调用者的实例，由autofac框架实现（容器创建）所以称为控制反转。

     依赖注入DI是Dependency Injection缩写，它提出了“哪些东东的控制权被反转了，被转移了？”，它也给出了答案：“依赖对象的创建获得被反转”。

就是由IoC容器在运行期间，动态地将某种依赖关系注入到对象之中。

     要理解控制反转，可以看看非控制反转的一个例子。

一、一个没有使用IoC的例子

public class MPGMovieLister
   {
       public Movie[] GetMPG()
       {
           var finder = new ListMovieFinder();
           var allMovies = finder.FindAll();

           return allMovies.Where(m => m.Name.EndsWith(".MPG")).ToArray();
       }
   }

 
public class ListMovieFinder
   {
       public List<Movie> FindAll()
       {
           return new List<Movie>
                      {
                          new Movie
                              {
                                  Name = "Die Hard.wmv"
                              },
                          new Movie
                              {
                                  Name = "My Name is John.MPG"
                              }
                      };
       }
   }

上面的例子中，类MPGMovieLister的作用是列出所有的mpg类型的电影，其中调用了类ListMovieFinder类的方法FindAll()来获取所有的电影。

这段代码看起来还不错，已经符合当前的需求了。

二、当需求发生变动时，非IoC遭遇到的困境

 假如这个时候，movie的列表获取不是直接创建一个list获取，而要求从某个文本文件读取，或者是数据库获取，又或者从web service中获取，我们怎么办？

第一步，再实现一个类, 比如FileMovieFinder，来实现从文本文件中读取Movie列表，再把MPGMovieLister中的这行代码，

     var finder = new ListMovieFinder(); 
替换成

    var finder = new FileMovieFinder(); 
那么这行代码就又能够符合要求了。

如果底层--获取数据的方式不确定，或者经常更改，MPGMovieLister的代码岂不是要频繁改动? 

三、使用IoC彻底解决问题:

  MPGMovieLister的功能都是依赖着具体的类，ListMovieFinder，FileMovieFinder。当需求发生变化的时候，就会导致MPGMovieLister的代码也要做相应的改动。

跳出来看，MPGMovieLister的功能只是负责从列表中找出MPG的movie, 至于movie从什么地方来的，不是MPGMovieLister的职责，它也不需要关心。

解耦合的方法就是”依赖于抽象，而不是依赖于具体”.

(这个例子非常类似于我们的做开发时候的持久层(数据层)和业务逻辑层，其实业务逻辑层也不关心数据是如何提供的，所以业务逻辑层也应当与持久层解耦合。)

实际解决之后的代码：
public class MPGMovieLister
   {
       public Movie[] GetMPG()
      {
           var finder = MovieFinderFactory.GetFinder();
           var allMovies = finder.FindAll();
           return allMovies.Where(m => m.Name.EndsWith(".MPG")).ToArray();
       }
   }
 
public class MovieFinderFactory
{
     public static IMovieFinder GetFinder()
     {
         return new FileMovieFinder();
     }
} 

public interface IMovieFinder
{
    List<Movie> FindAll()
}

　　这里的MovieFinderFactory就已经是一个简陋的IoC容器功能了

四、总结

IoC这种解决依赖的方法是面向对象方法的使用。现实世界中，这种方法无处不在。

比如，汽车不会强依赖于某个品牌的轮胎，任何公司生产的轮胎，只要符合汽车的接口，就可以装在这个汽车上使用。

还有电脑的USB接口，只要符合USB标准的外设，就都能够接上电脑使用。

     解除依赖不仅让代码结构看起来更加合理，其带来的另一个好处是，各个部分可以单独的做单元测试，使得单元测试能够更加容易的进行。这个对于一些复杂度高的项目，对于保证项目的稳定性和可用性非常有意义。

真正的IoC容器比上面的MovieFinderFactory自然要好用和适用的多。下一篇文章将会介绍一个非常棒的IoC框架Autofac.

IoC容器Autofac(一)

标签：

原文地址：http://www.cnblogs.com/tiantianle/p/5135522.html