在我们进行 WEB 项目的开发的时候，因为 MVC 模式的流行，我们调用其他类库里的类文件这是不可避免的，在我日常的开发过程中，调用其他类库的文件就是最简单的应用类库，然后在头文件里边 using 一下，这样从开发的角度来讲确实很方便，但是从程序本身来看，又不是那么合适，如果修改了下层模块的细节，那么上层模块有时也意味着要进行相应的变动，这让程序的稳定性和维护性大打折扣，于是就有人提出了 "依赖倒置原则"。
依赖倒置原则（Dependence Inversion Principle）：上层模块不应该依赖下层模块，两者应该通过抽象依赖。
就是说调用方法的类不因该依赖被调用的类，两者可以通过接口的方式来时间依赖。而依赖倒置原则的最初的方式是工厂+反射的方式实现的，但是由于大部分人勇气反射和工厂的时候感觉很麻烦（我是这么认为的），所以在一些后期修改较少的程序中，开发者宁可不使用工厂的模式。
接下来我就要说一说我们今天所说的 IOC 了。
IOC（Inversion of Control）：即控制反转，原本应该由上层模块使用的对象变成了，第三方来装配。而人们常常把 IOC 和 依赖注入（DI）混在一起，其实严格来说这两个完全不是一回事，我们可以这么理解，IOC 是我们想要达到的目标，那么依赖注入就是达到目标的手段，同时可以实现 IOC 的手段还有依赖查找，只不过在 C# 中不是特别常见，所以我们就不细说了。
那么基本了解了 IOC 的意义，我们举个例子：假设我们去买面包，首先买，是一个动作，接下来吃又是一个动作，吃到嘴里我们感觉到甜，那么就是说一块面包，包含买和吃两个方法以及甜的一个属性。我们直接来看 IOC 相关的代码。
程序目录
上图是程序目录，并为 DAL 类库以及 IOC 控制台程序添加 Unity 框架，我用的是4.01版本。其中 DAL 中有以下几个类，分别是：
Bread.cs
Sweet.cs
Eat.cs
Buy.cs
Inertface 类库中有以上几个类对应的接口，并让上面的类分别实现他们。其中 Bread 对应的接口需要有其他几个接口的属性。
IBread.cs
以及最后的 Peaple 类，也就是我们的程序入口。
Peaple.cs
上图中的几行代码就是我们使用 Unity 框架从创建容器，到得到实体的几个过程，我们在 Bread 类中，可以看到几个特性分别是
[ InjectionConstructor ]：构造函数注入；[ Dependency ]：属性注入； [ InjectionMethod ]：方法注入。而我们之前说到的控制反转，就是通过以上三种方式完成的，先上调试图。
People.cs
Buy.cs
Bread.cs
通过以上的调试我们可以看到，我们并没有在 Bread 的构造函数中调用 Buy 的细节，只是调用了 IBuy 的接口，但是调试过程中却自动跳到了 Buy 构造函数中，其实这就是所谓的注入，也就是说当我们在容器中注册了接口和细节后，没有主动使用某些细节，但是使用到其接口的时候，就会为你自动创建该细节，这个过程就叫做注入。接下来看看结果：
结果
结果就是，即使我们没有主动调用 Sweet ，Eat ，Buy 这三个类，但是容器却自动实例化并执行了他们的构造函数。
有些人看了之后会觉得并没有什么用，因为在上图的注册中，我们还是调用了细节
People.cs
那么接下来我们换一种注册方式：通过配置文件注册。
Unity.Config.xml
当然，一个容器是可以注册多个 register 的
People.cs
这样，只需在实例化的时候写上之前设置的名称标识就可以制定实例化的具体内容了。
网友评论