一.写在前面

基于通过配置文件形成ioc容器的例子，我们采用另外一种方式去形成ioc容器，那就是unity框架。

二.unity简介

Unity 应用程序块（Unity）是一个轻量级、可扩展的依赖注入容器，支持构造函数、属性和方法调用注入。

1.控制反转 (IoC) 模式，这是一种设计模式，它描述了用于支持对象可以“查找”它们需要的其他对象的实例的插件架构的技术。

2.依赖注入 (DI) 模式，这是 Ioc 模式的一种特殊情况，是一种基于改变对象的行为而不改变类的内部的接口编程技术。开发人员编写实现接口的类代码，并基于接口或者对象类型使用容器注入依赖的对象实例到类中。用于注入对象实例的技术是接口注入、构造函数注入、属性（设置器）注入和方法调用注入。

 

三.为什么要实现DI（依赖注入）

为了灵活的在外部就拿到了实现后的接口，通过unity可以有很多方式去实现这样的要求。

下面分常见的两种方式（构造函数注入和属性注入依赖）。

说明：为什么要注入依赖？因为以前的拿到接口的地方是在调用者（类）的内部实现接口的。比如一个类A需要用的接口B，那经常我们会这样，在A的内部的某个方法下需要使用到接口B，那我们就在这个方法里面去实现这个接口，然后调用这个接口。那么这个类A与接口B的依赖关系就放在了类A的里面。这样并不算的上一种好的设计，倘若类A中调用的接口实现变动了，那我们不得不进入类A里面进行调整，为了防止这样的情况发生，依赖注入的设计方式产生了，它将接口的实现转移到了外部，有效的防止了如果后期接口的实现变了，我们只需要在外部那接口的地方换一下即可，不用操心类A里面。接下来我们看看具体例子

四.unity框架的引用

在需要引用unity框架的项目上，添加引用，选择管理NeGet程序包，搜索unity，下载安装即可。如图：

如果找不到，楼主提供下载 密码：rp2q

下载完后引用即可

五.通过unity构造ioc容器

我们改掉调用类原先内部实现接口然后调用的方式，接口的实现在外部拿到，或通过构造函数或属性注入进去即可。

1.构造函数注入接口

namespace Unity_IocDemo{    public class Operater    {        private ICooker COOKER;              public Operater(ICooker cooker)//构造函数将接口传入进来        {            COOKER = cooker;               }        public void cook() {            COOKER.Cook();        }    }}

构造自己的ioc_factory

namespace LogicLayer{    public class IOC_Factory    {        public  IUnityContainer container { get; set; }        public IOC_Factory()        {            container = new UnityContainer();//容器        }        /// 
        /// 依赖注入        /// 
        /// 
    
     需要调用接口的调用类
            /// 
            public  Toperater GetOperater
    
     ()        {            Toperater operater = container.Resolve
     
      ();//DI（依赖注入)            return operater;        }        /// 
      
        /// 注册接口容器        /// 
        /// 
      
       接口
              /// 
      
       实现Tinterface接口的具体类
              public  void register
      
       () where  Tclass:Tinterface        {            container.RegisterType
       
        ();//注册接口与具象依赖        }          }}
       
      
     
    

当我们使用Operater类时，就可以利用ioc_factory工厂拿到它的实例了。这个过程是通过unity框架自动绑定的。如下：

namespace Unity_IocDemo{    class Program    {        static void Main(string[] args)        {            IOC_Factory ioc = new IOC_Factory();//ioc容器            ioc.register
    
     ();//注册依赖关系            Operater operater1 = ioc.GetOperater
     
      ();//注入依赖关系            operater1.cook();            Console.Read();        }    }}
     
    

分析：个人感觉这样做，有什么鸟用？说实话，还没有采用配置文件形成ioc拿接口好。如果说注册依赖关系的时候还是会出现具体类的类名，那这个耦合并没有真正意义上被解除。至少program类与ICooker依赖了，且与potatohelper也耦合了。唯一的方便就是自动将接口实现后注入到了operater类中。这种方式有待后续考察

2.采用属性方式注入

那就需要在调用类中设置接口属性，并加上Dependency属性注解，这样unity框架会自动将接口注入到该属性下，调用类代码如下：

namespace Unity_IocDemo{    public class Operater    {        [Dependency]//需要被注入的属性标记        public IPerson person { get; set; }        private ICooker COOKER;        public Operater(ICooker cooker)//构造函数将接口传入进来        {            COOKER = cooker;               }        public void cook() {            COOKER.Cook();        }    }}

依赖注入代码如下：

namespace Unity_IocDemo{    class Program    {        static void Main(string[] args)        {            IOC_Factory ioc = new IOC_Factory();//ioc容器            ioc.register
    
     ();//注册依赖关系            ioc.register
     
      ();            Operater operater1 = ioc.GetOperater
      
       ();//注入依赖关系            operater1.person.eat();            operater1.cook();            Console.Read();        }    }}
      
     
    

用法是构造函数一样，只需要注册依赖关系就可以了。

运行结果如下：

个人觉得用属性注入应该是要比构造函数注入要合适，至少不会造成构造函数的参数过多过长，尽管一个调用类不可能同时使用到很多借口，一般都是一到三个接口。

六.总结

今天采用unity自动从外界将实现的接口注入到了调用类中，但是这种外界注入的过程也涉及到了具体类的类名，这也算是只用耦合了。但是相比使用配置文件形成ioc容器利用反射来拿接口的方式，又减少了在配置文件上的配置。因为如果具体类过多，配置信息无疑会边的很长。楼主也怀疑这样全部卸载配置文件里是否妥当。而采用unity自动注入，虽然解决了将具体类写入配置的麻烦，却也在注册接口与具体类依赖关系上，耦合了。总之各有各的不足，有点都是一样。在用的过程中好好体会吧。

七.关于

一个不甘于每天只编码，企图摆脱思想上的麻痹的程序员。qq:739462304.任何其他领域的事情，我都有情趣了解。

八. 项目demo