IoC容器Autofac(1) -- 什么是IoC以及理解为什么要使用Ioc
**阅读目录: 一. 一个没有使用IoC的例子 二. 当需求发生变动时,非IoC遭遇到的困境 三. 使用IoC彻底解决问题 四. 总结** 一、一个没有使用IoC的例子 IoC的全称是Inversion of Control,中文叫控制反转。要理解控制反转,可以看看非控制反转的一个例子。 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代码是这个样子:
复制代码
public class MPGMovieLister
{
public Movie[] GetMPG()
{
var finder = new FileMovieFinder();
var allMovies = finder.FindAll();
return allMovies.Where(m => m.Name.EndsWith(".MPG")).ToArray();
}
}
如果底层–获取数据的方式不确定,或者经常更改,MPGMovieLister的代码岂不是要频繁改动? MPGMovieLister的功能都是依赖着具体的类,ListMovieFinder,FileMovieFinder。当需求发生变化的时候,就会导致MPGMovieLister的代码也要做相应的改动。 也就是说,MPGMovieLister直接依赖于ListMovieFinder和FileMovieFinder了。 跳出来看,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()
}
复制代码 这里MPGMovieLister就依赖于IMovieFinder接口(依赖抽象),实际运行时候的实例化由MovieFinderFactory来提供。这样,不同的Movie数据源只需要一个实现IMovieFinder 的类就可以了,不会对MPGMovieLister产生任何影响。 到这里,实际上已经完成了IoC,控制权最初取决于MPGMovieLister中是如何实例化MovieFinder 的,现在它已经交出控制权,交由外部来提供具体实例对象了。 这里的MovieFinderFactory就已经是一个简陋的IoC容器功能了。 四、总结 IoC这种解决依赖的方法是面向对象方法的使用。现实世界中,这种方法无处不在。 比如,汽车不会强依赖于某个品牌的轮胎,任何公司生产的轮胎,只要符合汽车的接口,就可以装在这个汽车上使用。 还有电脑的USB接口,只要符合USB标准的外设,就都能够接上电脑使用。 解除依赖不仅让代码结构看起来更加合理,其带来的另一个好处是,各个部分可以单独的做单元测试,使得单元测试能够更加容易的进行。这个对于一些复杂度高的项目,对于保证项目的稳定性和可用性非常有意义。 真正的IoC容器比上面的MovieFinderFactory自然要好用和适用的多。下一篇文章将会介绍一个非常棒的IoC框架Autofac. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |