在上一篇文章中，我简单介绍Unity的一些背景知识、为什么要使用Unity和使用Unity有什么好处。今天将继续学习Unity，主要是了解Unity的一些常见的使用方法。 本篇文章将主要介绍： Unity中的UnityContainer基本使用介绍，包括UnityContainer类的常用方法介绍，并且通过几个小例子来介绍具体的使用方法，这些例子都会以代码及配置文件两种方式来实现。 从UnityContainer（Unity容器）这个类的名称中我们就可以看出其是Unity最重要的类，UnityContainer就像Unity的一个司令部，而一个个对象就像一名名士兵，每个士兵来去都需要通过UnityContainer来管理，其掌管了所有对象的依赖关系，所有对象的创建都会通过这个Unity容器来创建，，同时也可以说是一个外交部，对于我们开发者，我们不需要关心内部是怎么实现的，我们只需要事先设置好对象之间的关系，然后在需要的时候告诉UnityContainer我需要什么，UnityContainer就会将我们需要的直接发给我们。（这些比喻可能不正确，但是是我能想到的最好的比喻了） 使用代码实现对象关联注册： 首先来看一个简单的例子：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public interface IClass { void ShowInfo(); } public class MyClass : IClass { public MyClass() { } public void ShowInfo() { Console.WriteLine("这个是我的班级"); } } 具体调用: |
|
1 2 3 4 5 |
static void Main(string[] args) { IClass classInfo = new MyClass(); classInfo.ShowInfo(); } |
这个是最常见的接口及其实现类的使用方法，定义一个接口，然后再定义一个类来实现这个接口，然后在具体使用的过程中，可以通过new关键字来实例化具体来实现接口，虽然没有语法上的问题，但是这样会造成紧耦合，如果一旦具体的实现类发生了改变，则就需要修改代码，而且如果这种类似的代码很多，则会导致整个项目的变动，甚至出现异常，所以我们需要使用IOC来解耦，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 |
public static void ContainerCode() { IUnityContainer container = new UnityContainer(); container.RegisterType<IClass, MyClass>(); //另一种注册方法，不过没有RegisterType<>()方法来的方便 //container.RegisterType(typeof(IClass), typeof(MyClass)); IClass classInfo = container.Resolve<IClass>(); //另一种通过container获取具体对象的方法 //IClass classInfo = container.Resolve(typeof(IClass)); classInfo.ShowInfo(); } |
使用Unity来管理对象与对象之间的关系可以分为以下几步： 1、创建一个UnityContainer对象。 2、通过UnityContainer对象的RegisterType方法来注册对象与对象之间的关系。 3、通过UnityContainer对象的Resolve方法来获取指定对象关联的对象。 使用配置文件来实现对象关系注册： 以上是通过代码的方式来注册对象之间的关系，但是对于一个项目来说，正式部署后，由于代码都编译成DLL，如果要修改依赖关系则修改代码并重新编译，相对来说太麻烦了，所以Unity还提供配置文件配置的方式来配置对象之间的关系，配置如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/> </configSections> <unity xmlns="http://schemas.microsoft.com/practices/2010/unity"> <alias alias="IClass" type="UnityStudyConsole.IDemo.IClass, UnityStudyConsole" /> <alias alias="MyClass" type="UnityStudyConsole.Demo.MyClass, UnityStudyConsole" /> <container> <register type="IClass" name="ConfigClass" mapTo="MyClass" /> </container> </unity> </configuration> |
具体代码调用如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public static void ContainerConfiguration() { IUnityContainer container = new UnityContainer(); //获取指定名称的配置节 UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity"); //默认方法，默认获取名称为"unity"配置节下配置信息 container.LoadConfiguration(); //获取已命名的配置节<container name="FirstClass">下的配置信息 container.LoadConfiguration("FirstClass"); //获取特定配置节下配置信息 container.LoadConfiguration(section); //获取特定配置节下已命名的配置节<container name="FirstClass">下的配置信息 container.LoadConfiguration(section, "FirstClass"); IClass classInfo = container.Resolve<IClass>("ConfigClass"); classInfo.ShowInfo(); } |
通过配置文件配置Unity信息需要有以下几个步骤： 1、在配置文件中<configSections> 配置节下unity注册。 2、在<configuration> 配置节下添加Unity配置信息。 3、在代码中读取配置信息，并将配置载入到UnityContainer中。 使用配置文件来配置对象信息虽然可以在部署的时候更改对象之间的依赖关系，但是当系统过于复杂，则就会导致配置文件的增大，所以我们需要将Unity的配置信息从App.config或web.config中分离出来，但是这样的话前面的代码中调用方法就无效了，我们现在需要修改一下现有的代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public static void ContainerConfigurationFromFile(string configFile) { //根据文件名获取指定config文件 var fileMap = new ExeConfigurationFileMap { ExeConfigFilename = configFile }; //从config文件中读取配置信息 Configuration configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None); var unitySection = (UnityConfigurationSection)configuration.GetSection("unity"); var container = new UnityContainer() .LoadConfiguration(unitySection, "FirstClass"); IClass classInfo = container.Resolve<IClass>("ConfigClass"); classInfo.ShowInfo(); } |
由于Unity配置相对来说比较复杂，一下子难以上手，而且不像企业库的其他模块可以通过配置工具进行配置，所以p&p小组为了方便通过配置文件进行Unity配置，已经在企业库5.0的安装包中内置了UnityConfiguration20.xsd，你可以在X:\Program Files\Microsoft Visual Studio X.0\Xml\Schemas\下找到，这样就可以在配置文件中进行Unity配置时出现只能提示了，如下图： 需要注意的是，如果想出现这种提示，需要在新增的unity配置节中增加一个xmlns为http://schemas.microsoft.com/practices/2010/unity。（如果没有安装过EntLib5，所以没有UnityConfiguration20.xsd，可以在下面的示例代码中找到这个xsd。） 以上就是本文的所有内容了，主要是简单介绍一下UnityContainer的基本使用方法——如何通过代码及配置文件来实现对象之间关系，如有不对欢迎指出！ 示例代码下载：点我下载 转自：http://www.cnblogs.com/kyo-yo/archive/2010/11/08/Learning-EntLib-Tenth-Decoupling-Your-System-Using-The-Unity-PART2-Learn-To-Use-Unity-One.html
View Details在前面的Part3中，我介绍Policy Injection模块中内置的Call Handler的使用方法，今天则继续介绍Call Handler——Custom Call Handler，通过建立Custom Call Handler来实现项目中的用户操作日志的记录，具体的代码可以在项目中EntLib.Helper项目下找到，如下图： 本文将从Custom Call Handler两种方式来介绍：Attribute方式和Configuration方式。 一、核心代码 建立Custom Call Handler则需要有以下几个步骤： 1、建立一个类实现接口ICallHandler。 2、根据具体需求建立对应Attribute类或为Custom Call Handler实现特性[ConfigurationElementType(typeof(CustomCallHandlerData))] 首先来介绍下具体的核心代码，由于我是要实现用户的操作日志，则需要对用户的对数据的增删改以及一些特殊的操作进行记录，如：登录， 1、首先需要建立一张表用于存放用户操作记录：
|
1 2 3 4 5 6 7 8 9 10 |
CREATE TABLE [dbo].[UserLog]( [ID] [int] IDENTITY(1,1) NOT NULL,--主键 [StudentId] [int] NOT NULL,--对应学生ID [Message] [nvarchar](256) NOT NULL,--操作消息 [LogDate] [datetime] NOT NULL,--记录时间 CONSTRAINT [PK_UserLog] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] |
2、建立一个名为UserLogCallHandler的类来实现接口ICallHandler，实现其中的方法Invoke（具体的拦截操作方法）和属性Order，具体代码如下（关键处我都写好注释了）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 |
using System; using System.Collections.Generic; using System.Collections.Specialized; using System.Data; using System.Data.Common; using System.Linq; using System.Text; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; using Microsoft.Practices.EnterpriseLibrary.Data; using Microsoft.Practices.Unity.InterceptionExtension; namespace EntLibStudy.Helper.EntLibExtension.PolicyInjectionExtension { [ConfigurationElementType(typeof(CustomCallHandlerData))] public class UserLogCallHandler : ICallHandler { /// <summary> /// 构造函数，此处不可省略，否则会导致异常 /// </summary> /// <param name="attributes">配置文件中所配置的参数</param> public UserLogCallHandler(NameValueCollection attributes) { //从配置文件中获取key，如不存在则指定默认key this.Message = String.IsNullOrEmpty(attributes["Message"]) ? "" : attributes["Message"]; this.ParameterName = String.IsNullOrEmpty(attributes["ParameterName"]) ? "" : attributes["ParameterName"]; } /// <summary> /// 构造函数，此构造函数是用于Attribute调用 /// </summary> /// <param name="message">消息</param> /// <param name="parameterName">参数名</param> public UserLogCallHandler(string message, string parameterName) { this.Message = message; this.ParameterName = parameterName; } /// <summary> /// 实现ICallHandler.Invoke方法，用于对具体拦截方法做相应的处理 /// </summary> /// <param name="input"></param> /// <param name="getNext"></param> /// <returns></returns> public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext) { //检查参数是否存在 if (input == null) throw new ArgumentNullException("input"); if (getNext == null) throw new ArgumentNullException("getNext"); //开始拦截，此处可以根据需求编写具体业务逻辑代码 //调用具体方法 var result = getNext()(input, getNext); //判断所拦截的方法返回值是否是bool类型， //如果是bool则判断返回值是否为false,false:表示调用不成功，则直接返回方法不记录日志 if (result.ReturnValue.GetType() == typeof(bool)) { if (Convert.ToBoolean(result.ReturnValue) == false) { return result; } } //如果调用方法没有出现异常则记录操作日志 if (result.Exception == null) { //获取当前登录的用户名，从cookies中获取，如果采用的session记录，则更改为从session中获取 var uid = Utils.GetCookies("sid"); //如果未登录则抛出异常 if (String.IsNullOrEmpty(uid)) throw new Exception("用户未登录！"); //操作附加消息，用于获取操作的记录相关标识 var actionMessage = ""; object para = null; //判断调用方法的主要参数名是否为空，不为空则从拦截的方法中获取参数对象 if (String.IsNullOrEmpty(this.ParameterName) == false) { para = input.Inputs[this.ParameterName]; } //判断参数对象是否为null，不为null时则获取参数标识 //此处对应着具体参数的ToString方法，我已经在具体类中override了ToString方法 if (para != null) { actionMessage = " 编号:[" + para.ToString() + "]"; } //插入操作日志 Database db = DBHelper.CreateDataBase(); StringBuilder sb = new StringBuilder(); sb.Append("insert into UserLog(StudentId,Message,LogDate) values(@StudentId,@Message,@LogDate);"); DbCommand cmd = db.GetSqlStringCommand(sb.ToString()); db.AddInParameter(cmd, "@StudentId", DbType.Int32, uid); db.AddInParameter(cmd, "@Message", DbType.String, this.Message + actionMessage); db.AddInParameter(cmd, "@LogDate", DbType.DateTime, DateTime.Now); db.ExecuteNonQuery(cmd); } //返回方法，拦截结束 return result; } public string Message { get; set; } public string ParameterName { get; set; } private int _order = 0; public int Order { get { return _order; } set { _order = value; } } } } |
这段代码主要部分就是具体的Invoke方法实现，这个方法有2个参数： input，这个参数中封装了已拦截的方法、方法的参数等有用的信息 getNext，一个委托，用于调用拦截的方法，通过这个委托我们可以很好的控制我们需要在拦截了具体方法后如何进行具体的业务逻辑操作。 通过getNext()(input, getNext); 这段代码即可完成对方法的调用，这样可以根据具体需求决定在调用方法前还是方法后进行具体操作。 由于我这边是要实现一个用户操作记录，那么我要知道一些具体的信息：是谁在什么时候对什么数据做了操作，这边我需要获取3个参数：具体的操作人、操作的数据及具体描述。 首先来看下第一个参数： ◆具体的操作人，由于这个项目采用的是cookies来记录当前的登录用户，所以我可以直接从cookies中获取当前登录的人，具体可以查看代码69-71行。 ◆操作的数据，这边我在这个Call Handler中建立了一个ParameterName属性用来指定记录所拦截的方法中存放所操作数据的参数名，具体可以查看代码74-86行。 由于指定了具体的参数名，我们则需要根据参数获取具体数据值，我们来看下增删改的方法签名： int Add(Student student); bool Update(Student student); bool Delete(int id); 可以看到，我们都可以从这3个方法获取到用户具体操作的数据标识，如Student.Id和id，这样我们只需变通一下，在具体的类中，如Student中，重写ToString方法，返回具体的ID即可，代码如下：
|
1 2 3 4 |
public override string ToString() { return this.Id.ToString(); } |
这样，我们在Call Handler中我们就可以根据参数名获取到具体操作的数据了（如果需要详细描述具体的数据的话则需要更复杂的设计了，这边就不深入了），代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
//操作附加消息，用于获取操作的记录相关标识 var actionMessage = ""; object para = null; //判断调用方法的主要参数名是否为空，不为空则从拦截的方法中获取参数对象 if (String.IsNullOrEmpty(this.ParameterName) == false) { para = input.Inputs[this.ParameterName]; } //判断参数对象是否为null，不为null时则获取参数标识 //此处对应着具体参数的ToString方法，我已经在具体类中override了ToString方法 if (para != null) { actionMessage = " 编号:[" + para.ToString() + "]"; } |
◆具体描述，这个我也是建立一个Message数据，用于存放操作的具体描述。 ◆特殊情况，当然操作日志也不可能就仅仅增删改3种情况，就比如登录，注销，这种情况则只需指定具体的消息即可，参数名无需指定，如果还有更加特殊的情况则需要根据具体需求来更改这边的设计，我这边只是给出个最基本的。 二、Attribute实现 在完成了核心代码后，我们则可以根据需求建立Attribute拦截还是Configuration拦截了。 实现Attribute拦截，需要建立一个类，实现HandlerAttribute类，实现其中的CreateHandler方法，用于调用具体的Call Handler方法，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
using System; using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.Practices.Unity; using Microsoft.Practices.Unity.InterceptionExtension; namespace EntLibStudy.Helper.EntLibExtension.PolicyInjectionExtension { [AttributeUsage(AttributeTargets.Method)] public class UserLogCallHandlerAttribute : HandlerAttribute { public UserLogCallHandlerAttribute(string message, string ParameterName) { this.Message = message; this.ParameterName = ParameterName; } public string Message { get; set; } public string ParameterName { get; set; } public override ICallHandler CreateHandler(IUnityContainer container) { //创建具体Call Handler，并调用 UserLogCallHandler handler = new UserLogCallHandler(this.Message, this.ParameterName); return handler; } } } |
这个特性类就比较简单了，不过还需要在Call Handler中进行处理，增加一个构造函数，接收从Attribute中传递过来的参数：
|
1 2 3 4 5 6 7 8 9 10 |
/// <summary> /// 构造函数，此构造函数是用于Attribute调用 /// </summary> /// <param name="message">消息</param> /// <param name="parameterName">参数名</param> public UserLogCallHandler(string message, string parameterName) { this.Message = message; this.ParameterName = parameterName; } |
三、Configuration方式 如果要实现可以通过企业库配置工具进行配置Custom Call Handler的话，则需要对Call Handler增加一个特性： [ConfigurationElementType(typeof(CustomCallHandlerData))] 然后新增一个构造函数
|
1 2 3 4 5 6 7 8 9 10 |
/// <summary> /// 构造函数，此处不可省略，否则会导致异常 /// </summary> /// <param name="attributes">配置文件中所配置的参数</param> public UserLogCallHandler(NameValueCollection attributes) { //从配置文件中获取key，如不存在则指定默认key this.Message = String.IsNullOrEmpty(attributes["Message"]) ? "" : attributes["Message"]; this.ParameterName = String.IsNullOrEmpty(attributes["ParameterName"]) ? "" : attributes["ParameterName"]; } |
完成以上2步我们就可以通过企业库配置工具进行配置了，见下图： 四、具体使用 在完成了Call Handler的代码编写和登录拦截配置后，我们就可以进行使用了，我这边更改了项目的结构，建立了一个IBLL的接口层，现有的BLL层的类则实现IBLL层中接口，而且由于Policy Injection模块要实现AOP，则具体类必须继承自MarshalByRefObject或实现一个接口（如果不清楚可以查看Part1），所以为了项目的各模块解耦、方便Policy Injection对具体类的创建和未来Unity介绍做铺垫则创建了IBLL层。（具体可以参看项目代码） 由于建立了IBLL层，则表示层的代码则需要发生变化，所有BLL层创建都需要通过PolicyInjection.Create方法来创建，具体代码如下：
|
1 |
IStudentManage studentBll = PolicyInjection.Create<StudentManage, IStudentManage>(); |
这样，当我们运行代码后，进入数据库查看就可以看，操作日志已经被记录下来了。 上面说的是通过Configuration方式来进行操作日志记录，如果我们想通过Attribute方式来记录日志消息，则需要到具体的BLL层进行操作，代码如下：
|
1 2 3 4 5 |
[UserLogCallHandler("更新学生信息","student")] public bool Update(Student student) { return studentService.Update(student); } |
注意：这边需要为项目引用Microsoft.Practices.Unity.Interception，因为Call Handler的Attribute是继承自HandlerAttribute，这个HandlerAttribute就是存放于Microsoft.Practices.Unity.Interception，否则自定义的Call Handler Attribute将无法显示出来。 这样，更新下学生信息后，我们可以就可以看到具体的操作日志了，见下图： 以上就是本文的所有内容，主要介绍了如何通过Custom Call Handler实现用户操作日志记录，如果有什么不对，欢迎大家指出，谢谢：） 至此，Policy Injection模块的介绍也结束了，下面将开始介绍企业库中使用最广泛的IOC容器——Unity，敬请期待！ 转自：http://www.cnblogs.com/kyo-yo/archive/2010/10/13/Learning-EntLib-Ninth-Use-PolicyInjection-Module-AOP-PART4-Call-Handler-To-Build-User-Logging.html
View Details在前面的Part1和Part2中我已经介绍了PolicyInjection模块的内置的Matching Rule和自定义Matching Rule的基本信息及配置使用方法，不过光有Matching Rule进行验证匹配还不够，还必须要有相应的操作——Call Handler，所以今天继续介绍PolicyInjection模块内置的Call Handler。 一、PolicyInjection模块内置的Call Handler 通过将Call Handler和Part1、Part2中的Matching Rule组合起来，我们就可以实现AOP编程，如果说Matching Rule是为了匹配寻找需要进行AOP操作的对象的话，那Call Handler则是在找到对象后进行的AOP操作。在PolicyInjection模块中内置了以下6种Call Handler: 1、Authorization Call Handler——权限操作 2、Custom Call Handler——自定义操作 3、Exception Handling Call Handler——异常处理操作 4、Logging Call Handler——日志记录操作 5、Performance Counter Call Handler——性能计数器操作 6、Validation Call Handler——验证操作 在Part1中已经介绍过，PolicyInjection模块可以和企业库中的其他模块组合起来一起使用，而内置的Call Handler也基本上都是企业库所包含的且适用于AOP编程的模块，具体的Call Handler代码可以在每个模块源码下的PolicyInjection文件夹下找到，比如：Authorization Call Handler就是在Security Application Block\PolicyInjection，主要分为：AuthorizationCallHandler.cs和AuthorizationCallHandlerAttribute.cs。 下面我介绍下这6种内置Call Handler的使用及配置方式： 二、Authorization Call Handler——权限操作 Authorization Call Handler主要和Security模块进行关联，通过这个Call Handler来调用已经配置好的Authorization Provider，主要接受3个参数： 1、Authorization Provider，指向的是所配置的具体的Authorization Provider。 2、Operation Name，验证的对象，可以是{method}，{type}，{namespace}，{assembly}和{appdomian}。 3、Order，这个是表示被调用的次序，默认为0（如果制定了次序则将从1开始，0表示不按照次序执行）。 具体配置图如下： 相对应的如果想通过代码来实现这样的效果，需要进行以下操作： 1、引用：Microsoft.Practices.EnterpriseLibrary.Security.PolicyInjection; 2、为指定方法添加特性：[AuthorizationCallHandler("{method}-具体的验证操作名")] 三、Custom Call Handler——自定义操作 这个将在下篇文章中重点介绍 四、Exception Handling Call Handler——异常处理操作 Exception Handling Call Handler对应的是Exception Handling模块，接受的参数很简单，只有2个： 1、Expection Policy Name，指向的是具体的Exception处理策略（有关Exception相关的文章可以看学习之路——第三步、为项目加上异常处理（采用自定义扩展方式记录到数据库中））。 2、Order，同上。 具体配置图如下： 相对应的如果想通过代码来实现这样的效果，需要进行以下操作： 1、引用：Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.PolicyInjection; 2、为指定方法添加特性：[ExceptionCallHandler("Policy-具体异常策略名")] 五、Logging Call Handler——日志记录操作 Logging Call Handler对应的是Logging模块，相比前几个Call Handler，Logging Call Handler接受的参数就比较多了，有11个： 1、After/Before Message，类似于Logging模块中的消息配置中的Message Header/Footer，主要是对消息的开始和结尾处加上额外的信息，如：“--Call Handler开始—”。 2、Categories，指向的hi具体的Logging配置，（有关Logging相关的文章可以看学习之路——第三步、为项目加上异常处理（采用自定义扩展方式记录到数据库中））。 3、Event Id，事件ID，默认为0，如果有需要可以指定。 4、Include Call Stack，表示是否在日志记录消息中包含调用栈信息，默认为false，不添加调用栈信息。 5、Include Call Time，表示是否在日志记录消息中包含调用的时间，默认为true，在日志消息中添加调用时间。 6、Include Paramters Values，表示是否在日志记录消息中包含调用的方法中所传递的参数值，默认为true，在日志消息中添加参数值。 7、Log Behavior，日志行为，主要用于设置日志记录的位置，有3个枚举，BeforeAndAfter（之前和之后），Before（之前）和After（之后）。 8、Order，同上。 9、Prority，表示日志消息中异常记录的优先级，默认为-1。 10、Severity，日志级别。 具体配置图如下： 相对应的如果想通过代码来实现这样的效果，需要进行以下操作： 1、引用：Microsoft.Practices.EnterpriseLibrary.Logging.PolicyInjection; 2、为指定方法添加特性：[LogCallHandler(Categories = new string[] { "Category" })]，在LogCallHandler里面还对应着许多可选参数，都可以自定义指定，如不指定则为默认值。 六、Performance Counter Call Handler——性能计数器操作 Performance Counter Call Handler与其他几个Call Handler不同，其不对应企业库的其他模块（具体代码可以在PolicyInjection\CallHandlers下找到，分别是PerformanceCounterCallHandler.cs和PerformanceCounterCallHandlerAttribute.cs） 这个Performance Counter Call Handler主要是对所拦截的策略进行性能检测，如果想使用需要以下步骤： 1、企业库配置图： 主要设置2个属性： 1）Category Name：计数器名——abc 2）Instance Name：实例名——Default 至于其他属性可以不用更改，主要是对性能监视器的一些配置。 2、安装性能计数器，需要在项目中引入：System.Configuration.Install 代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
private static void InstallCounter() { PerformanceCountersInstaller installer = new PerformanceCountersInstaller( new SystemConfigurationSource()); IDictionary state = new System.Collections.Hashtable(); installer.Context = new InstallContext(); installer.Install(state); installer.Commit(state); Console.WriteLine("性能计数器已安装完成，输入【enter】继续！"); Console.ReadLine(); } |
3、调用具体的方法，同时查看其性能：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
static void Main(string[] args) { InstallCounter();//安装性能计数器 Demo aop = PolicyInjection.Create<Demo>(); for (int i = 0; i < 50000; i++)//循环50000次，主要是为了方便监视性能 { System.Threading.Thread.Sleep(50); aop.Test("wozhidao");//此处使用的是Member Name Matching Rule，具体可看前一篇文章 } Console.ReadLine(); } public class Demo : MarshalByRefObject { public void Test(string aa) { string a = aa; } } |
在调用到InstallCounter();时在Console中会出现：这时，打开计算机管理-性能-监视工具-添加，可以看到我们刚才创建的性能计数器已经存在列表当中：添加完成后，我们就可以在性能计数器中看到我们现在所正在运行的方法的性能了：4、卸载性能计数器：
|
1 2 3 4 5 6 7 8 9 |
private static void RemoveCounters() { PerformanceCountersInstaller installer = new PerformanceCountersInstaller( new SystemConfigurationSource()); installer.Context = new InstallContext(); installer.Uninstall(null); Console.WriteLine("性能计数器已移除完成，输入【enter】继续！"); Console.ReadLine(); } |
卸载后，刚才我们所安装的计数器就移除了。 以上性能计数器使用方法参考：Getting started with Enterprise Library Performance Counters 七、Validation Call Handler——验证操作 Validation Call Handler对应的是Validation模块，这个Call Handler主要接收3个参数： 1、Order，同上。 2、Rule Source，规则来源，有4个枚举可选，分别是：Both（所有来源），Attributes（特性），Configuration（配置）和ParameterAttributesOnly（仅参数特性）。 3、RuleSet，规则集，指向具体的验证配置规则集（有关Validation相关的文章可以看学习之路——第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——上篇、中篇、下篇和学习之路——第六步、使用Validation模块进行服务器端数据验证）。 具体配置图如下： 同样的Vadidation Call Handler可以不通过配置进行操作，可以直接在代码中通过特性来进行AOP。 1、首先需要引用命名空间： Microsoft.Practices.EnterpriseLibrary.PolicyInjection; Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers; Microsoft.Practices.EnterpriseLibrary.Validation.Validators; Microsoft.Practices.EnterpriseLibrary.Validation.PolicyInjection; 2、为方法添加特性：[ValidationCallHandler]，然后为方法参数指定验证特性:[StringLengthValidator(6,16,MessageTemplate="输出的消息长度必须在6-16之间！")] 代码如下：
|
1 2 3 4 5 6 |
[ValidationCallHandler] public void abc([StringLengthValidator(6,16,MessageTemplate="输出的消息长度必须在6-16之间！")] string cw) { Console.WriteLine(cw); } |
注意：如果需要在代码中使用企业库的验证模块的特性类，需要为项目添加System.ComponentModel.DataAnnotations引用。 以上就是本文的所有内容了，本文主要是对Policy Injection模块内置的Call Handler的一些配置进行简单的介绍，如果不对欢迎大家指出，下篇将主要介绍Custom Call Handler的创建及使用方法。 […]
View Details这段时间公司有新项目需要开发，所以这个企业库学习之路有点耽误了，今天继续接着上一篇文章，在上一篇文章中，我介绍了企业库的自带Matching Rule（匹配规则）的基本信息及使用方法，但是在PolicyInjection模块中的Matching Rule（匹配规则）还有2个规则没有介绍，分别是： 1、Custom Attribute Matching Rule——自定义特性匹配规则 2、Custom Matching Rule——自定义匹配规则 今天就主要对这2个匹配规则进行介绍，及有关这2个匹配规则的一些应用例子。 一、Custom Attribute Matching Rule——自定义特性匹配规则 这个匹配规则有点类似于Tag Attribute Matching Rule，只不过Tag Attribute Matching Rule已经定死了特性类——TagAttribute，具体匹配需要靠TagAttribute特性类的tag字符串来标识具体的策略名，使用起来不怎么方便，而且使用字符串来标识，可能会写错，不过企业库同样为我们预留了扩展接口，就是这个自定义特性匹配规则——Custom Attribute Matching Rule。 这个匹配规则使用起来很简单，只需自己定义个特性类，然后在企业库配置工具中进行配置既可。 这个匹配规则接收2个参数：Attribute Type Name和Search Inheritance Chain 1、Attribute Type Name，这个意思很明确了，就是特性类的名称，只需点击旁边的选择按钮即可选择到自己定义的特性类。 2、Search Inheritance Chain，这个是表示是否要查询继承关系，默认为false，表示不查询，看下面的代码就可以理解了： 我首先定义了一个自定义的特性类：
|
1 2 3 4 |
[AttributeUsage(AttributeTargets.Method)] public class MyCustomAttribute:System.Attribute { } |
然后在应用到代码中：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public abstract class CustomAttrTest : MarshalByRefObject { [MyCustom] public abstract void CwInfo(string aa); } public class ChildCustomerAttrTest : CustomAttrTest { public override void CwInfo(string aa) { Console.WriteLine(aa); } } |
可以看到我将MyCustomAttribute应用到了抽象类CustomAttrTest中的抽象方法CwInfo上，然后由子类ChildCustomerAttrTest来实现，如果将Search Inheritance Chain设置为false，则在方法调用的过程中将不会被拦截，因为MyCustomAttribute是应用在抽象类中，而不是应用在实现类中，所以如果想依靠抽象类来定义拦截，则需要将Search Inheritance Chain设置为true。 具体配置图如下： 注：由于PolicyInjection模块的一个BUG问题，在通过PolicyInjection创建对象的时候，如果创建的对象需要指向一个抽象类将会报错，代码如下：
|
1 |
CustomAttrTest customAttr = PolicyInjection.Create<ChildCustomerAttrTest, CustomAttrTest>(); |
具体的问题，可以参考Artech写的这篇文章：这是EnterLib PIAB的BUG吗？，里面介绍了这个问题的产生原因及解决办法。 通过Custom Attribute Matching Rule我们可以根据我们自己的具体需求自由建立特性类，比如：异常、权限、日志等等，通过自己来建立特性类，这样我们可以很好的分隔各个功能，在具体的时候过程中我们可以自由组合所需要的功能，如下代码： 我首先定义几个需要使用的特性类：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
[AttributeUsage(AttributeTargets.Method)] public class ExceptionAttribute : System.Attribute { } [AttributeUsage(AttributeTargets.Method)] public class LoggingAttribute : System.Attribute { } [AttributeUsage(AttributeTargets.Method)] public class SecurityAttribute : System.Attribute { } public class MyCommonAttribute : System.Attribute { } |
然后为每个特性类关联不同处理操作： 最后使用的时候只需根据需要自己为方法添加特性既可：
|
1 2 3 4 5 6 |
[MyCustom] [Logging] [Exception] public void Delete(int id) { } |
二、Custom Matching Rule——自定义匹配规则 如果企业库内置的那么多匹配规则都无法达到你想要的话，你可以尝试着自己编写匹配规则，当然企业库也预留了这个接口，就是Custom Matching Rule。如果要自己实现一个Custom Matching Rule，主要分为2步： 1、建立一个类继承自接口IMatchingRule（这个接口是属于Microsoft.Practices.Unity.InterceptionExtension，需要引用Unity.dll），并实现方法bool Matches(System.Reflection.MethodBase member)。 2、为类加上特性[ConfigurationElementType(typeof(CustomMatchingRuleData))]（需要引用命名空间Microsoft.Practices.EnterpriseLibrary.Common.Configuration和Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration），标识其继承自CustomMatchingRuleData，可以被企业库配置工具识别到。 代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
using Microsoft.Practices.Unity.InterceptionExtension; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; using Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration; namespace AOPAssembly { [ConfigurationElementType(typeof(CustomMatchingRuleData))] public class MyCustomMatchRule : IMatchingRule { NameValueCollection attributes = null; public MyCustomMatchRule(NameValueCollection attributes) { this.attributes = attributes; } public bool Matches(System.Reflection.MethodBase member) { bool result = false; if (this.attributes["matchname"] != null) { if (this.attributes["matchname"] == member.Name) { result = true; } } return result; } } } |
配置图如下： 这样就可以在Matches方法中编写匹配方法，我这边写了个简单匹配，对根据方法名进行匹配。 这个匹配是通过配置工具中配置的方法名进行匹配，如果配置的方法名和所调用的方法名相同则返回匹配成功。这里需要注意的是，如果想要在自己实现的自定义匹配类获取到配置工具中所定义的配置，需要定义一个构造函数，接收类型为NameValueCollection的参数，我这边就通过在类中定义一个attributes参数来接收配置工具中所配置的参数，然后在Matches方法中进行处理。 以上就是本文的所有内容，本文主要介绍了自定义特性匹配规则和自定义匹配规则的创建及使用方法，如有不对之处欢迎大家指出：） 转自：http://www.cnblogs.com/kyo-yo/archive/2010/09/20/Learning-EntLib-Ninth-Use-PolicyInjection-Module-AOP-PART2-Custom-Matching-Rule.html
View Details继续微软企业库5.0的学习之路，今天主要介绍的是企业库的PolicyInjection模块，这个模块是为了方便我们在项目中使用AOP而生的模块，本篇主要介绍的PolicyInjection模块信息、内置的匹配规则和内置处理模块使用。 一、PolicyInjection模块基本信息介绍 PolicyInjection模块是在企业库3.0才正式引入的模块，简称PIAB（Policy Injection Application Block），这个模块的主要功能是方便我们在项目开发中进行AOP（面向切面编程），以简化开发内容。有关AOP方面的知识在园子里已经有很多朋友介绍过了，我这边就不重复介绍了，如不了解的朋友可以到张逸的这篇文章中学习：AOP技术基础。 在.NET下其实已经有很多成熟的AOP项目，比如：PostSharp、Spring.net、Jboss等等，而我今天介绍的企业库的PIAB同样也是实现AOP功能，但是PIAB可以和企业库中的其它几大模块，如Logging（日志）、Exception（异常）、Security（权限）等进行很好的合并，只需简单的配置立刻可以实现AOP功能。 由于在国内对PIAB的文章比较少，所以想深入的朋友可以看下Artech写的《EnterLib PIAB深入剖析》系列博文（不过Artech写的比较早，是08年写，当时的企业库版本还是3.1的版本，所以与现在的企业库5.0版本已经有许多不同的地方，不过其原理并没有变，值得一看） 如果想了解PIAB在企业库配置工具怎么配置以及基本使用方法可以看看huangcong写的这篇：Policy Injection Application Block 上图就是PolicyInjection模块的配置图，从图中的图示就可以看出，中间是具体的AOP策略，左边是这个AOP策略所要的验证规则，而右边则是这个AOP策略的具体调用处理操作。 注意： 1、每个策略配置所使用的验证规则最好只使用一个，如果使用一个以上则会出现AOP效果无法实现。 2、需要实现AOP策略的类必须实现类MarshalByRefObject或这个类必须实现一个接口 二、PolicyInjection模块内置验证规则使用介绍 PolicyInjection模块继承了企业库优秀的易用性和扩展性，与其他几大模块一样，其内置了许多常用的验证规则已方便我们开发人员的使用，主要有以下11种验证规则： 1、Assembly Matching Rule——程序集验证规则 2、Custom Attribute Matching Rule——自定义特性验证规则 3、Custom Matching Rule——自定义验证规则 4、Member Name Matching Rule——名称验证规则 5、Method Signature Matching Rule——方法签名验证规则 6、Namespace Matching Rule——命名空间验证规则 7、Parameter Type Matching Rule——参数类型验证规则 8、Property Matching Rule——属性验证规则 9、Return Type Matching Rule——返回类型验证规则 10、Tag Attribute Matching Rule——Tag特性验证规则 11、Type Matching Rule——类型验证规则 下面我详细介绍一下这些内置验证规则的使用方法： 1、Assembly Matching Rule——程序集验证规则 这个验证是对程序集名进行匹配，已达到AOP的效果，这个验证规则只接收一个参数：Assembly Name。 这个参数Assembly Name可接收的字符串类型有以下几种： 1、name and version，名称和版本号 如：Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0 2、name、version and curlture，名称、版本号和Culture 如：Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0,Culture=neutral 3、full assembly name，程序集的全名，但是不能包含“.dll”后缀名 如：AOPAssembly 2、Custom Attribute Matching Rule——自定义特性验证规则 和 Custom Matching Rule——自定义验证规则 这2个验证是为开发者预留的，有关这2个验证规则我在下一篇文章中进行介绍。 3、Member Name Matching Rule——名称验证规则 这个验证规则也比较简单，对符合配置名称的类或类成员进行验证，这个验证规则只接收一个参数：Member Names（支持通配符） 见下面的代码，我想在执行Test方法的时候进行AOP策略，只需将类继承MarshalByRefObject，然后在企业库配置工具进行配置，添加Member Name Matching Rule，将Test方法名添加到配置工具中：
|
1 2 3 4 5 6 7 |
public class MyAOP : MarshalByRefObject { public void Test(string aa) { Console.WriteLine(aa); } } |
配置图如下： 4、Method Signature Matching Rule——方法签名验证规则 这个验证规则比较特殊，是根据方法签名进行AOP策略，方法签名的一般为：Test(string aa) 这个验证规则接收2个参数： 1、Match，匹配的方法名，这个Match可以接收通配符匹配，“*”（表示多个字符），“？”（表示零个或一个字符），“[]”（通过在[]中书写字符范围） 如： Test*，支持Testa，Testab等方法名的匹配 Test？，支持Test，Testa等方法名的匹配 Test[1-9]，支持Test1，Test2等方法名的匹配 2、Parameters，方法参数列表，需要制定参数名称和参数类型 需要注意的是，参数类型最好不要从配置工具旁边的“类型选择器”，因为通过这个类型选择器选择的参数类型会包含程序集的版本号等无用信息，会导致AOP策略失败，所以建议手写类型。 如：Name：aa，Parameter Type Name：System.String 实例代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class AOPClass : MarshalByRefObject { public void Test(string aa) { Console.WriteLine(aa); } public void Test2(string aa) { Console.WriteLine(aa); } public void Test3(string aa) { Console.WriteLine(aa); } } |
配置图如下： 5、Namespace Matching Rule——命名空间验证规则 这个验证规则类似于上面的Member Name Matching Rule，只不过Namespace Matching Rule是匹配命名空间验证，这个验证规则接收一个参数：Namespaces（支持通配符） 这个参数Namespaces是一个集合，可以配置需要进行AOP策略的命名空间 如：AOPAssembly.Test 需要注意的是，如果需要进行匹配的命名是不是根级命名空间，比如：AOPAssembly.Test，那么不能仅仅写根命名空间AOPAssembly，这样将会匹配不到。 配置图如下： 6、Parameter Type Matching Rule——参数类型验证规则 这个验证是对方法参数进行匹配，接收一个参数Parameters Type 这个参数Parameters Type也是一个集合，可以配置需要进行AOP策略的参数信息 这个Parameters Type主要有2个子参数：Parameter Kind（参数方向，有Input，Output，InputOrOutput和ReturnValue5种类型）和Match（匹配名） 如：Parameter Kind：Input，Match：bb 示例代码如下：
|
1 2 3 4 |
public void AssemblyAOP(string bb) { Console.WriteLine(bb); } |
配置图如下： 7、Return Type Matching Rule——返回类型验证规则 这个类型验证规则是根据方法返回值的类型进行匹配，接收一个参数Return Type 这个Return Type可以是类型名，也可以使类名 如：System.String，Class1 示例代码如下：
|
1 2 3 4 5 |
public string RelaceString(string aa) { aa = "replace"; return aa; } |
配置图如下： 8、Tag Attribute Matching Rule——Tag特性验证规则 这个验证规则是根据特性（Attribute）——TagAttribute来进行验证的，这个验证规则接收一个参数：Tag Attribute。 这个参数Tag Attribute是接收配置在类、方法或属性的特性参数（支持通配符）。 […]
View Details在介绍完企业库几个常用模块后，我今天要对企业库的配置文件进行处理，缘由是我打开web.config想进行一些配置的时候发现web.config已经变的异常的臃肿（大量的企业库配置信息充斥其中），所以决定写这篇关于Configuration Setting模块等其他方式分类管理企业库配置信息的文章。 在ASP.NET4中微软就帮我们优化过了web.config，给了我们一个干净的web.config（将原来需要通过web.config注册的程序集、ASP.NET标签和handler等都移至machine.config中）这样大大方便了我们开发人员。 虽然我们通过企业库的配置工具可以很方便的配置企业库信息，但是如果要在web.config中修改其他信息就麻烦了，而且企业库的各模块信息也都在一起不利于日后的维护，所以我们首先就要把企业库的配置信息给剥离出来，然后再根据各模块分成一个一个独立的.config配置文件，统一放在一个文件夹中，这样项目发布后再修改配置信息时也可以立刻找到需要配置的文件。 分离配置文件的方式主要有3种，这3种方式各有优势也各有劣势，主要还是看实际如何应用： 1、使用企业库提供的Configuration Setting（只需配置无需修改代码，分离出的模块无法直接统一查看，只能查看单独模块，推荐） 2、分离出独立config文件或使用编码的形式来读取配置文件（必须编写代码，使用起来较为麻烦，分离出的模块无法直接统一查看只能查看单独模块，不推荐） 3、使用.NET的configSource特性进行配置（无需企业库工具配置，只需分离代码，分离出的模块可以统一查看，但是修改配置文件后所有配置信息又会重新回到web.config中，同时无法修改分离出去的单独配置文件，推荐） 一、使用企业库中默认已经提供了Configuration Setting模块来进行配置： 1、首先将各模块的信息先分离成一个一个单独的config文件（包括这个模块的section以及具体的配置）如下（Data Access模块配置文件）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<?xml version="1.0"?> <configuration> <configSections> <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" /> </configSections> <dataConfiguration defaultDatabase="EntLibStudy" /> <connectionStrings> <add name="EntLibStudy" connectionString="server=SQL2005;database=EntLibStudy;Integrated Security=True;" providerName="System.Data.SqlClient" /> <add name="EntLibStudySQLite" connectionString="data source=|DataDirectory|EntLibStudySQLite.db3" providerName="System.Data.SQLite" /> </connectionStrings> </configuration> |
2、在企业库中添加一个Configuration Setting模块，然后选择添加一个Filed-Based Configuration Source，将路径选择为刚才所分离好的config配置文件，同时建立一个重定向设置，设置到相对应的企业库模块： 添加Filed-Based Configuration Source 指向配置文件并建立重定项模块 这样项目中有几个企业库模块就建立几个相对应的配置文件，而且不需要修改任何代码。 二、使用编码形式来进行配置： 这种方式使用的配置文件同第一种方式，在配置文件中需要包含section等模块的配置信息，然后在具体使用企业各模块的时候采用如下代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
//缓存模块 //建立一个FileConfigurationSource来根据文件名读取配置文件 FileConfigurationSource cacheDataSource = new FileConfigurationSource("Cache.config"); //通过模块工厂来读取文件配置源 CacheManagerFactory cacheManagerFactory = new CacheManagerFactory(cacheDataSource); //建立具体模块实例 ICacheManager cacheManager = cacheManagerFactory.Create("Cache Manager"); cacheManager.Add("test", "test"); //数据访问模块 FileConfigurationSource dbDataSource = new FileConfigurationSource("Data.config"); DatabaseProviderFactory databaseProviderFactory = new DatabaseProviderFactory(dbDataSource); Database db = databaseProviderFactory.Create("EntLibStudy"); |
这种方式我个人认为很不方便，每次使用企业库中的模块时候首先要通过FileConfigurationSource 来获取这个模块具体的配置信息，然后才能创建实例对象，如果一旦配置文件名称发生改变将会出现异常，所以并不推荐使用这种方式来管理配置信息 三、使用.NET的configSource特性进行配置： 这种方式的好处是显而易见的，就是不用在企业库中添加Configuration Setting，只需单独建立config文件，然后把所需的配置信息剪切到config文件中即可，但是有几点需要注意： 1、有关企业库模块的section信息必须放在web.config中 2、在单独放置的config文件应该是一个干净的XML文件，不能包含有<configuration>配置节，仅仅需要某个模块的配置即可 3、在web.config中必须保留一句指向config的配置节 虽然这种方式操作最善但是缺点也很突出，就是一旦通过企业库配置工具修改过web.config，企业库的所有配置信息又会在web.config中重新产生，同时无法单独编辑分离出去的单独的config文件 具体配置如下： web.config：
|
1 |
<cachingConfiguration configSource="Configs/CacheConfig.config"/> |
CacheConfig.config:
|
1 2 3 4 5 6 7 8 9 |
<?xml version="1.0"?> <cachingConfiguration defaultCacheManager="Cache Manager"> <cacheManagers> <add name="Cache Manager" type="Microsoft.Practices.EnterpriseLibrary.Caching.CacheManager, Microsoft.Practices.EnterpriseLibrary.Caching, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" expirationPollFrequencyInSeconds="60" maximumElementsInCacheBeforeScavenging="1000" numberToRemoveWhenScavenging="10" backingStoreName="NullBackingStore" /> </cacheManagers> <backingStores> <add type="Microsoft.Practices.EnterpriseLibrary.Caching.BackingStoreImplementations.NullBackingStore, Microsoft.Practices.EnterpriseLibrary.Caching, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="NullBackingStore" /> </backingStores> </cachingConfiguration> |
这样便完成了配置，代码中无需进行任何更改，同时在企业库的配置工具中可以查看具体的配置信息，唯一不好的就是一旦你用企业库的配置工具打开过web.congfig文件后，所有分离到各个配置文件中的配置信息又回重新返回到web.config中，可以说是有利有弊。 以上三种就是企业库配置信息的分类处理方式，总的来说推荐使用顺序是：第一种>第三种>第二种。不过具体的方式还是要根据各种使用需求情况进行选择。 源代码下载：点我下载 注意： 1、MSSQL数据库在DataBase目录下（需要自行附加数据库），SQLite数据库在Web目录的App_Data下，由于考虑到项目的大小，所以每个项目的BIN目录都已经删除，如出现无法生成项目请自行添加相关企业库的DLL。 2、由于微软企业库5.0 学习之路这个系列我是准备以一个小型项目的形式介绍企业库的各模块，所以源代码会根据系列文章的更新而更新，所以源代码不能保证与文章中所贴代码相同。 3、项目开发环境为：VS2010+SQL2005。 4、管理员帐户：admin 密码：admin 转自：http://www.cnblogs.com/kyo-yo/archive/2010/08/16/Learning-EntLib-Eighth-Use-Configuration-Setting-To-Manage-ConfigInfo.html
View Details在上一篇文章中，我介绍了企业库Cryptographer模块的一些重要类，同时介绍了企业库Cryptographer模块为我们提供的扩展接口，今天我就要根据这些接口来进行扩展开发，实现2个加密解密方法（离散加密和对称性加密），分别实现自接口IHashProvider和接口ISymmetricCryptoProvider。 首先来看下离散加密——CustomHashCryptography，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
using System; using System.Collections.Generic; //构造函数中接受参数的类型NameValueCollection所在命名空间 using System.Collections.Specialized; using System.Linq; using System.Text; using System.Security.Cryptography; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;//用于企业库配置工具绑定 using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography; using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Configuration; namespace EntLibStudy.Helper { [ConfigurationElementType(typeof(CustomHashProviderData))] public class CustomHashCryptography : IHashProvider { /// <summary> /// 构造函数，此处不可省略，否则会导致异常 /// </summary> /// <param name="attributes">配置文件中所配置的参数</param> public CustomHashCryptography(NameValueCollection attributes) { } /// <summary> /// 比较数据和已加密数据是否相等 /// </summary> /// <param name="plaintext">未加密数据</param> /// <param name="hashedtext">已加密数据</param> /// <returns>是否相等</returns> public bool CompareHash(byte[] plaintext, byte[] hashedtext) { var tmpHashText = CreateHash(plaintext); if (tmpHashText == null || hashedtext == null) return false; if (tmpHashText.Length != hashedtext.Length) return false; for (int i = 0; i < tmpHashText.Length; i++) { if (tmpHashText[i] != hashedtext[i]) return false; } return true; } /// <summary> /// 创建加密 /// </summary> /// <param name="plaintext">待加密数据</param> /// <returns>加密后数据</returns> public byte[] CreateHash(byte[] plaintext) { MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider(); return md5.ComputeHash(plaintext); } } } |
这段代码主要就是实现一个离散加密，不过还是有几点需要注意： 1、在实现接口IHashProvider的基础上，为了能让这个自定义加密可以在企业库的配置工具里调用到需要为类加上一个特性：[ConfigurationElementType(typeof(CustomHashProviderData))]，这个特性所在的命名空间为：using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;。 2、这个自定义加密必须包含一个构造函数，其参数的类型是NameValueCollection，这个参数是从配置文件中获取指定的配置属性，见下图： 注意：这个NameValueCollection类型，需要引用命名空间：using System.Collections.Specialized; 如果没有这个构造函数，将会引发异常： Type does not provide a constructor taking a single parameter type of NameValueCollection 3、方法CompareHash、CreateHash，接收和返回的类型都是字节数组。 接下来看下对称加密CustomSymmetricCryptography ，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 |
using System; using System.Collections.Generic; using System.Collections.Specialized; using System.Linq; using System.Text; using System.Security.Cryptography; using System.IO; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography; using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Configuration; namespace EntLibStudy.Helper { [ConfigurationElementType(typeof(CustomSymmetricCryptoProviderData))] public class CustomSymmetricCryptography : ISymmetricCryptoProvider { private string encryptKey=""; public CustomSymmetricCryptography(NameValueCollection attributes) { //从配置文件中获取key，如不存在则指定默认key encryptKey = String.IsNullOrEmpty(attributes["key"]) ? "kyo-yo" : attributes["key"]; } //默认密钥向量 private static byte[] Keys = { 0x12, 0x34, 0x56, 0x78, 0x90, 0xAB, 0xCD, 0xEF }; /// <summary> /// 加密 /// </summary> /// <param name="ciphertext">待加密数据</param> /// <returns>加密后数据</returns> public byte[] Decrypt(byte[] ciphertext) { if (encryptKey.Length > 8) { encryptKey = encryptKey.Substring(0, 7); } encryptKey = encryptKey.PadRight(8, ' '); byte[] rgbKey = Encoding.UTF8.GetBytes(encryptKey); byte[] rgbIV = Keys; byte[] inputByteArray = ciphertext; DESCryptoServiceProvider DCSP = new DESCryptoServiceProvider(); MemoryStream mStream = new MemoryStream(); CryptoStream cStream = new CryptoStream(mStream, DCSP.CreateDecryptor(rgbKey, rgbIV), CryptoStreamMode.Write); cStream.Write(inputByteArray, 0, inputByteArray.Length); cStream.FlushFinalBlock(); return mStream.ToArray(); } /// <summary> /// 解密 /// </summary> /// <param name="plaintext">加密数据</param> /// <returns>解密后数据</returns> public byte[] Encrypt(byte[] plaintext) { if (encryptKey.Length > 8) { encryptKey = encryptKey.Substring(0, 7); } encryptKey = encryptKey.PadRight(8, ' '); byte[] rgbKey = Encoding.UTF8.GetBytes(encryptKey.Substring(0, 8)); byte[] rgbIV = Keys; byte[] inputByteArray = plaintext; DESCryptoServiceProvider dCSP = new DESCryptoServiceProvider(); MemoryStream mStream = new MemoryStream(); CryptoStream cStream = new CryptoStream(mStream, dCSP.CreateEncryptor(rgbKey, rgbIV), CryptoStreamMode.Write); cStream.Write(inputByteArray, 0, inputByteArray.Length); cStream.FlushFinalBlock(); return mStream.ToArray(); } } } |
这个对称性加密的注意点基本和离散加密一样，但是这边的对称加密我引入了一个加密key，这个key是从配置文件中获取的。 第三点：在项目中应用自定义接口 在上面已经扩展好了2个加密方式，现在就要在实际的项目中运用这2个加密方式，首先打开企业库的配置工具，添加Cryptographer模块，然后在Hash Providers和ISymmetric Cryptograhpy Providers下分别添加刚才定义好的2个加密方式。 注意：添加的自定义加密方式必须放在项目的根目录下，如果放在项目下的文件夹下，如：Helper\Extension下，从企业库的配置文件中将无法找到自定义的加密方式，见下图： 在添加完配置后就可以在web.config看到以下配置信息：
|
1 2 3 4 5 6 7 8 9 10 |
<securityCryptographyConfiguration> <hashProviders> <add type="EntLibStudy.Helper.CustomHashCryptography, EntLibStudy.Helper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" name="CustomHashCryptography" /> </hashProviders> <symmetricCryptoProviders> <add key="kyo-yo" type="EntLibStudy.Helper.CustomSymmetricCryptography, EntLibStudy.Helper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" name="CustomSymmetricCryptography" /> </symmetricCryptoProviders> </securityCryptographyConfiguration> |
配置完后，我又在Helper.Utils类中添加了几个加密解密方法的封装，用于表示层调用（主要是根据配置实例名和待加密数据获取加密数据），代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
/// <summary> /// 根据配置进行加密 /// </summary> /// <param name="instance">配置实例名</param> /// <param name="encryptString">待加密字符串</param> /// <returns>加密后字符串</returns> public static string Encode(string instance, string encryptString) { return Cryptographer.EncryptSymmetric(instance, encryptString); } /// <summary> /// 根据配置进行解密 /// </summary> /// <param name="instance">配置实例名</param> /// <param name="decryptString">待解密字符串</param> /// <returns>解密后字符串</returns> public static string Decode(string instance, string decryptString) { return Cryptographer.DecryptSymmetric(instance, decryptString); } /// <summary> /// 根据配置进行离散加密 /// </summary> /// <param name="instance">配置实例名</param> /// <param name="plaintString">待加密字符串</param> /// <returns>解密后字符串</returns> public static string CreateHash(string instance, string plaintString) { return Cryptographer.CreateHash(instance, plaintString); } /// <summary> /// 比较离散值是否相等 /// </summary> /// <param name="instance">配置实例名</param> /// <param name="plaintString">未加密字符串</param> /// <param name="hashedString">已加密字符串</param> /// <returns>是否相等</returns> public static bool CompareHash(string instance,string plaintString, string hashedString) { return Cryptographer.CompareHash(instance, plaintString, hashedString); } |
接下来就是主要的项目应用了，在以前的代码中，例如学员的密码我是以明文的形式保存进数据库的，这显示是很不安全的，现在我就要替换这块代码，通过调用Utils.CreateHash方法加密录入的密码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
/// <summary> /// 获取已验证的学员对象 /// </summary> /// <param name="student">学员对象</param> /// <returns>是否验证成功</returns> private bool GetValidatedStudent(ref Model.Student student) { if (student == null) { student = new Model.Student(); } student.ClassId = Convert.ToInt32(ddlClass.SelectedValue); student.Sid = txtSid.Text.Trim(); student.Password = Helper.Utils.CreateHash("CustomHashCryptography", txtPwd.Text.Trim()); student.Name = txtName.Text.Trim(); student.Sex = Convert.ToInt32(rblSex.SelectedValue); student.Birthday = DateTime.Parse(txtBirthday.Text.Trim()); return student.IsValid(); } |
以上就是本文的主要内容，本文主要介绍了： 1、如何通过企业库Cryptographer模块给出的接口进行扩展加密方法，以及扩展时需要注意的问题 2、在项目中使用已经扩展好的加密方法。 本文内容比较简单，如发现问题欢迎指出，谢谢大家！ 源代码下载：点我下载 注意： 1、MSSQL数据库在DataBase目录下（需要自行附加数据库），SQLite数据库在Web目录的App_Data下，由于考虑到项目的大小，所以每个项目的BIN目录都已经删除，如出现无法生成项目请自行添加相关企业库的DLL。 2、由于微软企业库5.0 学习之路这个系列我是准备以一个小型项目的形式介绍企业库的各模块，所以源代码会根据系列文章的更新而更新，所以源代码不能保证与文章中所贴代码相同。 3、项目开发环境为：VS2010+SQL2005。 4、管理员帐户：admin 密码：admin 转自：http://www.cnblogs.com/kyo-yo/archive/2010/08/11/Learning-EntLib-Seventh-Introduce-Cryptographer-and-Expand-Part2.html
View Details在完成了后，今天开始介绍企业库中的新模块：Cryptographer（加密模块），这个模块在日常的大多数项目的作用非常重要，例如：网站会员密码、身份证号、网站配置等，通过对信息进行加密可以保证项目数据的安全性。 今天主要介绍以下几点： 1、企业库Cryptographer（加密模块）简单分析。 2、实现一个自定义加密接口。 3、在项目中应用自定义接口。 第一点、企业库Cryptographer（加密模块）简单分析 在我们日常开发中总会使用加密对数据进行加密，我们一般都会在项目中自定义一些加密方法，而企业库就是为了简便这些开发，提供了简便的方式来进行数据加密解密。 和其他的模块一样，Cryptographer（加密模块）也可以通过简单的配置进行数据加密解密，具体有关配置方面的介绍可以看园子里huangcong所写的文章，我就不多介绍了： Cryptography Application Block (初级) Cryptography Application Block (高级) Cryptographer（加密模块）主要提供2种加密方式： 1、HashCryptographer（离散加密），这种方法根据特定的算法对数据进行加密，此种加密无法被解密。 2、SymmetricCryptographer(对称性加密)，这种方法也是根据特定的算法对数据进行加密，但是数据加密后可以进行解密。 通过图可以更好的理解，下图引用自企业库5.0文档： 加密模块中静态类Cryptographer为核心，方便程序员根据配置对数据进行加密解密，其主要包含以下成员： 1、方法CreateHash，根据配置文件中所配置的离散配置名读取配置对数据进行加密。 2、方法EncryptSymmetric，根据配置文件中所配置的对称性配置名读取配置对数据进行加密。 3、方法DecryptSymmetric，根据配置文件中所配置的对称性配置名读取配置对数据进行解密。 4、方法CompareHash，比较带加密的数据和已加密的数据是否一致。 5、私有方法GetHashProvider、GetSymmetricCryptoProvider，根据配置文件名获取离散加密、对称加密实例。 在这个加密模块中，静态类Cryptographer为我们提供了根据配置名进行加密解密方式，同时还提供了一个抽象类CryptographyManager来实现自定义的加密解密管理器，在加密模块中已经为我们提供了一个CryptographyManager的实现——CryptographyManagerImpl。 抽象类CryptographyManager本质上就是一个非静态的Cryptography，其定义了4个抽象方法： 1、方法CreateHash。 2、方法EncryptSymmetric。 3、方法DecryptSymmetric。 4、方法CompareHash。 实现类CryptographyManagerImpl则主要实现了抽象类CryptographyManager，其主要信息如下： 1、字段IDictionary<string, IHashProvider> hashProviders，离散加密键值对集合，包含了多个离散加密实现。 2、字段IDictionary<string, ISymmetricCryptoProvider> symmetricCryptoProviders，对称加密键值对集合，包含了多个对称加密实现。 3、字段IDefaultCryptographyInstrumentationProvider instrumentationProvider，提供加密模块出现错误报告 4、构造函数，一共有3个构造函数，接收泛型列表形式的离散加密实现、对称加密实现以及 5、加密解密方法CreateHash、EncryptSymmetric、DecryptSymmetric，这3个方法接收3个参数：所配置的加密解密实例名、待加密数据和加密模块的错误报告（IDefaultCryptographyInstrumentationProvider）。 其内部会根据实例名到hashProviders或symmetricCryptoProviders这2个列表中寻找相应的加密解密实现，然后调用实现进行加密解密。 在实际的项目开发的开发过程中，我们既可以通过静态类Cryptographer简单的完成对数据的加密解密，也可以通过实现抽象类CryptographyManager来编写符合项目需求的加密解密管理器，总的来说企业库的这个Cryptographer模块已经为我们提供了很好的加密解密封装，同时又提供了扩展接口在其基础上可以进行进一步扩展，大大方便了我们的日常项目开发。 第二点：实现一个自定义加密接口 在第一点中，我简单介绍了企业库Cryptographer模块的重要信息，现在我来介绍下企业库Cryptographer模块为我们提供的加密解密扩展接口。 上面说过，企业库Cryptographer模块提供了2种加密解密方式： 1、HashCryptographer（离散加密），这种方法根据特定的算法对数据进行加密，此种加密无法被解密。 2、SymmetricCryptographer(对称性加密)，这种方法也是根据特定的算法对数据进行加密，但是数据加密后可以进行解密。 这2种加密解密方式对应着2个接口：IHashProvider和ISymmetricCryptoProvider，分别看下这2个接口的代码： IHashProvider接口：
|
1 2 3 4 5 6 |
public interface IHashProvider { byte[] CreateHash(byte[] plaintext); bool CompareHash(byte[] plaintext, byte[] hashedtext); } |
这个接口只有2个方法： 1、方法CreateHash，接收传入的待加密数据（字节数组）根据具体实现进行离散加密返回加密后的数据（字节数组）。 2、方法CompareHash，接收待加密数据（字节数组）和已经加密后的数据（字节数组），调用具体实现的离散加密方法将待加密数据进行加密然后与已加密数据进行比较，看其是否相等。 ISymmetricCryptoProvider接口：
|
1 2 3 4 5 6 |
public interface ISymmetricCryptoProvider { byte[] Encrypt(byte[] plaintext); byte[] Decrypt(byte[] ciphertext); } |
这个接口也比较简单，也只有2个方法： 1、方法Encrypt，接收待加密数据（字节数组），调用实现方法进行加密，返回加密后的数据（字节数组）。 2、方法Decrypt，接收已加密数据（字节数组），调用实现方法进行解密，返回解密后的数据（字节数组）。 而如果我们需要扩展自定的加密解密方法据需要从上面2个接口入手，根据需求判断是要进行离散加密还是对称性加密实现不同的接口。 以上就是今天所要介绍的企业库Cryptographer模块信息，主要介绍了Cryptographer模块的常用类、加密解密管理器，同时简单介绍了Cryptographer模块的加密解密扩展接口。 在下一篇文章中我将继续介绍如何实现自定义离散加密和对称性加密方法，以及在项目中使用自定义的加密解密方法。 转自：http://www.cnblogs.com/kyo-yo/archive/2010/08/09/Learning-EntLib-Seventh-Introduce-Cryptographer-and-Expand.html
View Details前端时间花了1个多星期的时间写了使用jQuery.Validate进行客户端验证，但是那仅仅是客户端的验证，在开发项目的过程中，客户端的信息永远是不可信的，所以我们还需要在服务器端进行服务器端的验证已保证数据的正确，今天我继续企业库的学习之路，主要介绍企业库中的Validation模块如何对数据进行验证。 本文的主要内容有以下三点： 1、根据本项目进行实体验证。 2、使用Validation提供的ASP.NET控件将实体验证和UI层页面验证联系起来 3、简单分析下Validation.Integration.Aspnet实现逻辑 文章开始前的废话： 我学习微软企业库都是首先查看企业库提供的HOL（Microsoft Enterprise Library 5.0 – Hands On Labs），里面为企业库的每个模块编写了例子，是非常好的学习材料，而其中的Validation模块的例子是最多的，足足有14个（由此可见Validation模块在企业库中的分量），我看了下，基本上将Validation的各个方面使用方法都介绍了一遍，想学习的朋友可以认真的学习下。 第一点：根据本项目进行实体验证 这个项目是一个小型的学生信息管理系统（就是班级和学生简单管理，都不好意思叫系统），主要有班级、学生、科目3个类，我们现在需要通过企业库的Validation模块为这3个类加上验证。 在前几篇文章中，我已经将企业库的Validation模块的各种验证器基本信息进行了介绍，大家可以前往查看。 我这边就是将student类进行了简单的验证：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
[StringLengthValidator(1, 16, MessageTemplate = "登录ID的长度必须在{3}-{5}之间!")] //MessageTemplateResourceType = typeof(EntLibStudy.Model.Properties.Resources), //MessageTemplateResourceName = "SidMessage")] public string Sid { get; set; } [StringLengthValidator(1, 16, MessageTemplateResourceType = typeof(EntLibStudy.Model.Properties.Resources), MessageTemplateResourceName = "PasswordMessage")] public string Password { get; set; } [StringLengthValidator(1, 16, MessageTemplateResourceType = typeof(EntLibStudy.Model.Properties.Resources), MessageTemplateResourceName = "NameMessage")] public string Name { get; set; } |
这里我就是将Sid、Password和Name进行必须输入验证。 第二点：使用Validation提供的ASP.NET控件将实体验证和UI层页面验证联系起来 在Validation模块中企业库为我们提供了一个子模块——ASP.NET控件用来和Validation模块联合起来进行客户端+服务器端的验证。 我们在页面上放上一个PropertyProxyValidator控件，并指定要验证的控件、对应的实体类型及属性名，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
<tr> <td align="right"> 登录ID: </td> <td> <asp:TextBox runat="server" ID="txtSid" /> <cc1:PropertyProxyValidator ID="PropertyProxyValidator1" runat="server" ControlToValidate="txtSid" PropertyName="Sid" SourceTypeName="EntLibStudy.Model.Student,EntlibStudy.Model" ValidationGroup="test"></cc1:PropertyProxyValidator> </td> </tr> <tr> <td align="right"> 密码: </td> <td> <asp:TextBox runat="server" ID="txtPwd" TextMode="Password" /> <cc1:PropertyProxyValidator ID="PropertyProxyValidator2" runat="server" ControlToValidate="txtPwd" PropertyName="Password" SourceTypeName="EntLibStudy.Model.Student,EntlibStudy.Model" ValidationGroup="test"></cc1:PropertyProxyValidator> </td> </tr> <tr> <td align="right"> 姓名: </td> <td> <asp:TextBox runat="server" ID="txtName" /> <cc1:PropertyProxyValidator ID="PropertyProxyValidator3" runat="server" ControlToValidate="txtName" PropertyName="Name" SourceTypeName="EntLibStudy.Model.Student,EntlibStudy.Model" ValidationGroup="test"></cc1:PropertyProxyValidator> </td> </tr> <tr> |
具体有关PropertyProxyValidator控件信息可以看下面的第三点分析，这边仅仅是介绍如何应用。 在页面中添加完指定的控件后，还需要在提交的按钮处做一下处理，代码如下：
|
1 2 3 4 5 6 7 8 |
protected void btnSubmit_Click(object sender, EventArgs e) { if (!IsValid) { return; } //具体业务逻辑 } |
这步操作是判断页面验证是否通过，如果验证不通过则返回，主要是因为PropertyProxyValidator控件所依赖的验证都在服务器端，需要点击一次提交按钮来进行验证，所以第一次页面的验证是不通过的，需要等到页面上的所有PropertyProxyValidator控件验证通过后页面的验证才会通过。 这时如果未通过验证，服务器端则会通过PropertyProxyValidator控件将验证消息返回给客户端，见下图， 如果全部填写完整则会真正提交页面信息： 虽然企业库的Validation模块为我们提供了这个ASP.NET控件来和Validation进行组合应用，但是我总觉得不友好（最好能使用AJAX验证来提高界面友好性），而且应用面比较窄（可能还有更好的使用方法我没研究出来，如果有哪位朋友有使用经验欢迎分享），使用起来也不怎么方便，建议还是采用ASP.NET原有的验证控件，在数据提交的时候通过后台代码编写进行验证。 我在网上搜索了相关的文章，认为最好的办法就是为Model层的每个子类都统一继承自一个基类，基类里提供统一的验证方法，这样就可以很好的将验证逻辑封装到Model层，表示层只需在获取到数据后调用这个验证方法，验证不通过则将错误消息返回给客户端，具体代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
namespace EntLibStudy.Helper { [Serializable] public abstract class BaseClass<T> where T : class { public string ValidateTag { get; protected set; } public virtual bool IsValid() { var validateResults = Validation.Validate<T>(this as T); if (!validateResults.IsValid) { foreach (var item in validateResults) string.Format(@"{0}:{1}" + Environment.NewLine, item.Key, item.Message); return false; } return true; } } } |
修改抽象类BaseClass，同时添加一个属性用于存储验证结果，添加一个方法用于实体验证。 界面使用代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
protected void btnSubmit_Click(object sender, EventArgs e) { //if (!IsValid) //{ // return; //} BLL.StudentManage studentBll = new BLL.StudentManage(); Model.Student student = null; try { int studentId = Convert.ToInt32(this.ViewState["studentId"]); if (studentId == 0) { if (GetValidatedStudent(ref student)) { int id = studentBll.Add(student); Helper.Utils.MessageBox(this, "新增学员信息成功!", this.GetRouteUrl("StudentRoute" { id = id })); } else Helper.Utils.MessageBox(this, student.ValidateTag); } else { student = studentBll.SelectById(studentId); if (GetValidatedStudent(ref student)) { studentBll.Update(student); Helper.Utils.MessageBox(this, "编辑学员信息成功!"); } else Helper.Utils.MessageBox(this, student.ValidateTag); } } catch (Exception ex) { throw ex; } } /// <summary> /// 获取已验证的学员对象 /// </summary> /// <param name="student">学员对象</param> /// <returns>是否验证成功</returns> private bool GetValidatedStudent(ref Model.Student student) { if (student == null) { student = new Model.Student(); } student.ClassId = Convert.ToInt32(ddlClass.SelectedValue); student.Sid = txtSid.Text.Trim(); student.Password = txtPwd.Text.Trim(); student.Name = txtName.Text.Trim(); student.Sex = Convert.ToInt32(rblSex.SelectedValue); student.Birthday = DateTime.Parse(txtBirthday.Text.Trim()); return student.IsValid(); } |
修改了页面的具体代码，添加一个GetValidatedStudent方法用于统一赋值，同时返回实体对象是否验证通过，如不通过则将验证错误消息返回给客户端 第三点：简单分析下Validation.Integration.Aspnet实现逻辑 在第二点中已经说过了，Validation.Integration.Aspnet是企业库中Validation模块所提供的一个子模块，其本质是一个ASP.NET控件，核心类就是PropertyProxyValidator.cs，下面我来简单的介绍下这个控件。 PropertyProxyValidator控件其主要作用就是根据配置信息去调用指定的服务器端的验证方法进行验证，如验证不通过则返回验证消息。 类PropertyProxyValidator，继承自ASP.NET中的BaseValidator类，同时实现了接口IValidationIntegrationProxy： 1、BaseValidator类为所有验证控件提供核心实现。验证控件用于验证关联的输入控件中的用户输入。当用户输入的值未通过验证时，验证控件将显示错误信息。由于验证控件是与输入控件分开的，您可以将错误信息定位在页面上相对于输入控件的任意位置。ASP.NET 提供了一些验证控件来执行特定类型的验证。（以上摘自MSDN） 由于PropertyProxyValidator继承自BaseValidator类，使得其成为了一个ASP.NET控件（Label控件），基本的客户端验证属性都已经包含在内了。 2、IValidationIntegrationProxy接口是由企业库定义的，其主要作用是为Validation模块提供验证所需行为整合。 在PropertyProxyValidator类中，主要实现了一下方法、属性等： 1、方法BaseValidator.EvaluateIsValid，这个方法的作用是确定输入控件中的值是否有效的代码，其内部实现很简洁，就是创建一个Validator验证器，根据配置通过这个验证器进行验证，然后通过调用内部静态方法FormatErrorMessage来拼装验证返回的消息，最后将这个消息返回给客户端。 PropertyProxyValidator实现的接口IValidationIntegrationProxy主要就为此方法服务，因为创建Validator验证器是通过ValidationIntegrationHelper这个帮助器来创建的，而这个帮助器通过构造函数接收一个实现接口IValidationIntegrationProxy的类，然后帮助器再通过PropertyValidationFactory.GetPropertyValidator属性验证类工厂类中的属性验证器方法调用这个类中所设置好的validatedType（待验证的对象类型）、validatedProperty（待验证的属性信息）、Ruleset（验证规则集）、SpecificationSource（见第5）和ValueAccessBulider（数据访问构造器，这里指向的是类PropertyMappedValidatorValueAccessBuilder）来创建验证器。 2、属性SourceTypeName，待验证对象在服务器端类型，例如：“EntLibStudy.Model.Student,EntLibStudy.Model”，其中逗号前指的是待验证对象所在的类名，逗号后指的是待验证对象所在程序集名。 3、属性PropertyName，待验证对象在服务器端类型中对应的属性名，例如"Name”。 4、属性RulesetName，验证规则集名。 5、属性SpecificationSource，指定的验证信息验证时，调用创建方法所需的源。 6、枚举属性DisplayMode，主要分为3种，List（列表形式）、BulletList（带项目符号的列表形式）和SingleParagraph（段落形式）。 7、事件ValueConvert，用于当控件的值转变时执行验证，对应着委托ValueConverter。 以上就是本文的所有内容了，本文主要介绍了企业库的Validation模块中所提供的ASP.NET验证控件。到此企业库的Validation模块就全部介绍完毕了，谢谢大家的浏览。 PS：有关在BaseClass中抽象验证参考自：將驗證方法封裝在Model之中（一位台湾的朋友写的） 源代码下载：点我下载 转自：http://www.cnblogs.com/kyo-yo/archive/2010/08/04/Learning-EntLib-Sixth-Use-Validation-To-Server-Validate.html
View Details在前一篇文章中，已经将Validation模块的内置的多种验证器（第一类验证器）的使用进行了介绍，今天继续后面两类验证器：独立验证器和自定义验证器，同时对Validation模块下有关验证器的配置类进行遗漏补充。 一、独立验证器 我上篇中我将AndCompositeValidator和OrCompositeValidator归为独立验证器，这2个验证器主要是为了第一类验证服务，可以进行多种验证组合在一起进行复杂验证： AndCompositeValidator——组合验证，逻辑与验证，所包含的多种验证全部通过则通过 OrCompositeValidator——组合验证，逻辑或验证，所包含的多种验证有一个通过则通过 这2类的验证器可以通过配置工具进行配置： 其配置方式和原有的配置一样，只不过是将各个具体的验证器放到了AndCompositeValidator或OrCompositeValidator中了。 当然也可以通过编写代码的方法进行创建：
|
1 2 3 4 |
Validator v = new AndCompositeValidator( new NotNullValidator(), new StringLengthValidator(1, 16)); v.Validate(Name4); |
这样就将2个验证器统一包装到一起对Name4属性进行验证了。 （注：在第一类的所有验证器由于都是继承自Validator ，所以除了通过特性、配置也可以进行代码编写进行验证） 二、自定义验证 当在进行项目开发时候发现Validation模块所内置的验证器不足以满足我们日常的需要的时候，我们就需要根据根据自己的需求进行扩展，建立自定义验证。 在Validation模块下已经为我们提供了扩展接口（具体有关Validation模块的验证的实现层次可以看“上篇”，具体的验证器都是需要继承自Validator类） 而具体需要实现一个自定义接口还是要思考一下步骤： 1、自定义验证器的验证方式 考虑到自定义验证器的验证方式，确定自己的自定义验证器的验证方式，是仅仅要特性验证，或者配置器验证还是2者都要？ 2、开始编码 在确定确定了验证方式就可以开始着手编写具体的验证器了，我们来看下要实现不同验证方式的验证器如何编写（我这边就直接引用微软企业库给出的HOL里面的9-11一共3个例子） 在实现各种验证方式之前首先要建立一个具体的验证器，比如StringLengthValidator等，这边由于我参考的是HOL，所以我就直接引用SSNValidator.cs了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
using System; using System.Text.RegularExpressions; using Microsoft.Practices.EnterpriseLibrary.Validation; using Microsoft.Practices.EnterpriseLibrary.Validation.Validators; namespace ValidationHOL.CustomValidators { public class SSNValidator : Validator<string> { public SSNValidator(string tag) : this(tag, false) { } public SSNValidator(string tag, bool ignoreHypens) : base(string.Empty, tag) { this.ignoreHypens = ignoreHypens; } static Regex ssnCaptureRegex = new Regex(@"^(?<area>\d{3})-(?<group>\d{2})-(?<serial>\d{4})$"); static Regex ssnCaptureNoHypensRegex = new Regex(@"^(?<area>\d{3})(?<group>\d{2})(?<serial>\d{4})$"); private bool ignoreHypens; protected override string DefaultMessageTemplate { get { throw new NotImplementedException(); } } protected override void DoValidate( string objectToValidate, object currentTarget, string key, ValidationResults validationResults) { Match match = (ignoreHypens ? ssnCaptureNoHypensRegex : ssnCaptureRegex) .Match(objectToValidate); if (match.Success) { string area = match.Groups["area"].Value; string group = match.Groups["group"].Value; string serial = match.Groups["serial"].Value; if (area == "666" || string.Compare(area, "772", StringComparison.Ordinal) > 0) { LogValidationResult( validationResults, "Invalid area", currentTarget, key); } else if (area == "000" || group == "00" || serial == "0000") { LogValidationResult( validationResults, "SSN elements cannot be all '0'", currentTarget, key); } } else { LogValidationResult( validationResults, this.ignoreHypens ? "Must be 9 digits" : "Must match the pattern '###-##-####'", currentTarget, key); } } } } |
可以看出这个验证器类还是比较简单的，这个类主要是用于验证美国社会安全号的格式正确性，这个类继承自泛型抽象类Validator<string>，实现了以下功能： 1）实现了属性DefaultMessageTemplate，返回一个异常NotImplementedException，这里我们不用去管它。 2）实现了方法DoValidate，这个是重要点，在前面的文章中也提过，这个方法主要就是用来进行具体的验证的，从方法中可以看出其本质就是通过正则表达式对社会安全号进行验证（验证规则我就不介绍了，有兴趣的可以自己搜索），如果验证不通过则通过方法LogValidationResult来记录消息及结果。 3）构造函数，这个验证有2个构造函数，构造函数接收2个参数，一个参数是验证的标签（存放一些验证信息），另一个参数ignoreHypens是表示在进行验证的时候是否忽略连字符。 在实现完了主要的业务逻辑验证器后我们就可以开始根据验证方式进行编写对应的类了： 1）方法验证 这个验证方式的话就不需要再编写任何代码了，直接实例化上面的SSNValidator后调用方法即DoValidate可进行验证。 2）特性验证 这个验证方式就需要编写一个特性类，我们可以参照Validation模块内置的验证器的格式，取名为SSNValidatorAttribute，看下带代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
using System; using Microsoft.Practices.EnterpriseLibrary.Validation; using Microsoft.Practices.EnterpriseLibrary.Validation.Validators; namespace ValidationHOL.CustomValidators { public class SSNValidatorAttribute : ValidatorAttribute { protected override Validator DoCreateValidator(Type targetType) { return new SSNValidator(this.Tag); } } } |
这个特性类也很简单，就是继承抽象特性类ValidatorAttribute，重载实现方法DoCreateValidator创建验证器SSNValidator进行验证。 这样在具体的使用的时候只需：
|
1 2 |
[SSNValidator] public string SSN { get; set; } |
3）配置器验证 为了更好的、更方便的进行验证器，我们可以让我们自己写验证通过配置器进行配置，这时我们就需要增加一个SSNValidatorData类，这个类是用来进行和企业库的配置工具进行对接的，看下具体的代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
using System; using System.Configuration; using Microsoft.Practices.EnterpriseLibrary.Validation; using Microsoft.Practices.EnterpriseLibrary.Validation.Configuration; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Design; using ValidationHOL.CustomValidators.Properties; namespace ValidationHOL.CustomValidators.Configuration { [ResourceDescription(typeof(Resources), "SSNValidatorDescription")] [ResourceDisplayName(typeof(Resources), "SSNValidatorName")] public class SSNValidatorData : ValueValidatorData { public SSNValidatorData() { } public SSNValidatorData(string name) : base(name, typeof(SSNValidator)) { } [ConfigurationProperty("ignoreHyphens")] [ResourceDescription(typeof(Resources), "IgnoreHyphensDescription")] [ResourceDisplayName(typeof(Resources), "IgnoreHyphensName")] public bool IgnoreHyphens { get { return (bool)this["ignoreHyphens"]; } set { this["ignoreHyphens"] = value; } } protected override Validator DoCreateValidator(Type targetType) { return new SSNValidator(this.Tag, this.IgnoreHyphens); } } } |
这个配置类，主要有以下3个注意点： 1）如果想在企业库的配置工具进行配置的时候增加所配置的验证器的注释时，需要和验证消息一样将注释放入资源文件，同时在类以及对应的属性上增加特性用以获取注释，如：[ResourceDescription(typeof(Resources), "SSNValidatorDescription")]，[ResourceDisplayName(typeof(Resources), "SSNValidatorName")] 2）可以在配置器中增加属性用以从企业库配置工具中获取信息。 3）配置类必须直接或者间接继承抽象类ValueValidatorData，同时实现方法DoCreateValidator用以创建验证器实例进行验证。 完成了配置类的编写后我们还需为验证器类加上一个特性用以标识可以进行配置：
|
1 2 |
[ConfigurationElementType(typeof(SSNValidatorData))] public class SSNValidator |
重新编译后我们就可以通过配置器进行配置了，我们可以在企业库配置工具里添加一个CustomValidator，然后选择我们编写的SSNValidator： 三、遗漏补充：Validation模块下有关验证器的配置类的简单介绍 在上篇我介绍了验证器和特性类的继承层次以及相关属性信息，但是遗漏了验证器在配置方面的相关信息，今天把这方面补充上，首先看下具体的结构图（这里我还是放了2种类型的验证器配置类，一个是类型转换验证器，另一个是字符串长度验证器）： 从这张图中我们可以清楚的了解到Validation模块的验证器的配置类的继承层次： IValidatorDescriptor->ValidatorData->ValueValidatorData->具体验证器配置类 接口IValidatorDescriptor 包含一个方法CreateValidator，实现类可以根据需求创建验证，同时方便企业库配置器获取所配置的具体验证类。 抽象类ValidatorData 实现接口IValidatorDescriptor，其作用基本类似于验证特性类BaseValidationAttribute和ValidatorAttribute的结合体，抽象了验证器创建方法、验证消息、验证结果等： 1）属性MessageTemplate，验证消息模板 2）属性MessageTemplateResourceName、MessageTemplateResourceTypeName，消息模板所在资源名和资源类型 3）属性Tag，存放验证结果 4）虚方法DoCreateValidator，用以被子类重写创建具体的验证器 5）方法IValidatorDescriptor.CreateValidator，实现接口IValidatorDescriptor的创建验证器的方法，其内部调用虚方法DoCreateValidator来获取具体的验证器 6）方法GetMessageTemplate、GetMessageTemplateResourceType，获取消息模板和根据资源类型获取消息模板 抽象类ValueValidatorData 封装了一个否定逻辑的属性，其作用基本类似于验证特性类ValueValidatorAttribute，但比ValueValidatorAttribute少了方法IsValid和FormatErrorMessage，功能单一。 具体验证器配置类 这个类就是根据具体的业务逻辑进行创建的，其必须实现方法Validator DoCreateValidator(Type targetType)根据配置信息读取所验证的对象，然后创建具体的验证器进行验证。 抽象泛型类RangeValidatorData<T> 在上图中还有一个类RangeValidatorData<T>，这个类不同于一般业务逻辑验证器配置类，这个类是为所有需要进行范围验证的验证器配置类提供抽象： 1）泛型属性LowerBound、UpperBound，范围上限下限 2）枚举属性LowerBoundType，UpperBoundType，表示范围边界 3）这个类的泛型T必须可以实现IComparable<T> （注：在配置类的所有属性上，如需要添加注释以方便在企业库配置工具中显示需要和验证消息一样将注释放入资源文件，同时在类以及对应的属性上增加特性用以获取注释，如：[ResourceDescription(typeof(Resources), "SSNValidatorDescription")]，[ResourceDisplayName(typeof(Resources), "SSNValidatorName")]） 至此企业库Validation模块信息、验证器实现层次以及各种验证器的使用方法就介绍完了，基本都是来自于企业库的源代码以及我个人的理解，文中如有不对请大家指出。 下一篇我将继续企业库Validation模块的介绍，主要是介绍Validation模块在学习之路项目中的一些简单应用，以及企业库Validation模块所提供的Asp.net控件的简单分析。 转自：http://www.cnblogs.com/kyo-yo/archive/2010/08/02/Learning-EntLib-Fifth-Introduction-Validation-module-information-Part3.html
View Details