.NET 使用unity实现依赖注入

原文地址:http://www.cnblogs.com/wujy/p/3317795.html

一:理论部分

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

Unity是微软企业库一部分,是一个轻量级、可扩展的依赖注入容器,支持构造函数、属性和方法调用注入;

针对依赖注入以前我也写过一篇结合三层的文章:spring.net 结合简单三层实例

二:实例简介

1:本实例将通过一个简单的三层演示使用Unity实现依赖注入,并把相应的具体实例写入在配置文件里,达到后期可能方便修改;首先看一下实例分层的情况:

IAopDAL-数据接口层(类库) [AopDAL AopOracelDAL]-分别实现数据接口的数据层(类库)

IAopBLL-逻辑接口层(类库) AopBLL-实现逻辑接口层(类库)

AopUnity-主程序层(控制台程序)

Command-公共助手层(类库)

2:其中Command我们简单编写一个实现Unity助手的类;首先要引用几个Unity的DLL文件;

3:AopDAL、AopOracelDAL是两个实现不同功能的类库,在这我们就比喻成一个插入MSSQL数据库,另外一个就是插入Oracel数据库;

其中AopBLL我们没有直接引用具体的AopDAL数据层,而是引用其对应接口层;主程序 AopUnity同样也没有具体的BLL层,也是引用其BLL接口层;

把接口对应的具体层类写入到配置文件里,做到依赖注入,只要简单修改配置文件就可以达到修改调用;

因为AopDAL、AopOracelDAL、AopBLL我们都没有直接引用,所以在生成DLL后是不会保存在主程序的bin里面,所以我们要修改这三个生成的路径;

三:实例编码

1:IAopDAL层我们只简单创建一个IReadData类代码:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace IAopDAL
{
    public interface IReadData
    {
        string ReadDataStr(string Name);
    }
}

2:AopDAL实现接口层IAopDAL

using IAopDAL; namespace AopDAL { class ReadDataDAL:IReadData { string Name) { return string.Format("把{0}写入MSSQL数据库成功",Name); } } }
3:AopOracelDAL同样实现IAopDAL层,其功能跟AopDAL一样

namespace AopOracelDAL { 把{0}写入Oracel数据库成功 4:IAopBLL逻辑接口层的内容如下:

namespace IAopBLL { interface IReadDataBLL { 5:AopBLL层实现IAopBLL接口层,要引用IAopDAL、IAopBLL、Command;

其中IReadData bllServer = new UnityContainerHelp().GetServer<IReadData>();就是过过公共助手Command类库调用Unity来实现依赖注入,

using IAopBLL; using Command; namespace AopBLL { class ReadDataBLL:IReadDataBLL { IReadData bllServer = new UnityContainerHelp().GetServer<IReadData>(); return bllServer.ReadDataStr(Name); } } }
6:Command公类助手代码如下,简单对Unity的封装,引用几个Unity的命名空间,我们把依赖注入的对象写入在主程序的.config文件里,这边就是通过读取配置文件来查看其对应哪个类库;

using System.Text; using Microsoft.Practices.Unity; using Microsoft.Practices.Unity.Configuration; using Microsoft.Practices.Unity.InterceptionExtension; using Microsoft.Practices.Unity.InterceptionExtension.Configuration; using System.Configuration; namespace Command { class UnityContainerHelp { private IUnityContainer container; public UnityContainerHelp() { container = new UnityContainer(); UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection(unity"); container.LoadConfiguration(section,FirstClass"); } public T GetServer<T>() { return container.Resolve<T>(); } public T GetServer<T>(return container.Resolve<T>(Name); } } }
7:主程序代码:同样只是简单的引用Command、IAopBLL两层;

namespace AopUnity { class Program { static void Main(string[] args) { IReadDataBLL bllServer = new UnityContainerHelp().GetServer<IReadDataBLL>(); Console.WriteLine(bllServer.ReadDataStr(踏浪帅")); } } }
我们新建一个App.config文件(因为我主程序是控制台,若是WEB程序可以把它放在web.config里面);其中register 就是我们注入的节点,type为接口层,mapTo则是我们对应的具体实现层,这边也是我们修改配置的地方;

<configuration>
  <configSections>
    <section name=" type=Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,Microsoft.Practices.Unity.Configuration"/>
  </configSections>
  <unity xmlns=http://schemas.microsoft.com/practces/2010/unity">
    <container name=">
      <register type=IAopBLL.IReadDataBLL,IAopBLL" mapTo=AopBLL.ReadDataBLL,AopBLL">
      </register>
      <register type=IAopDAL.IReadData,IAopDALAopOracelDAL.ReadDataDAL,AopOracelDAL"/>
    </container>
  </unity>
<startup><supportedRuntime version=v4.0" sku=.NETFramework,Version=v4.0"/></startup></configuration>

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结