在前面的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在上一篇文章中，我介绍了企业库的Validation模块的基本信息、使用方法，同时对企业库的内置验证器的实现及验证器的特性类实现进行了简单的分析，今天我将继续前一篇文章，介绍Validation模块内置的多种验证器的使用进行介绍。 （注：本文仅仅就Validation模块的各种验证器根据我个人的理解进行介绍，如果有误欢迎大家指出！） 0、验证器的命名参数 在上一篇文章中我已经介绍过验证器的特性类的层次： BaseValidationAttribute->ValidatorAttribute ->ValueValidatorAttribute ->具体验证器特性类 在具体的验证器的父类们中，已经封装好了许多通用的验证参数： 1）ErrorMessage，继承自ValidationAttribute，在Validation模块中没用使用。 2）ErrorMessageResourceName，继承自ValidationAttribute，在Validation模块中没用使用。 3）ErrorMessageResourceType，继承自ValidationAttribute，在Validation模块中没用使用。 4）MessageTemplate，验证错误消息模板，继承自BaseValidationAttribute。 5）MessageTemplateResourceName，验证错误消息模板所在资源名，继承自BaseValidationAttribute。 6）MessageTemplateResourceType，验证错误消息模板所在资源类型，继承自BaseValidationAttribute。 7）Negated，否定验证逻辑，继承自ValueValidatorAttribute。 8）Ruleset，验证规则集，继承自BaseValidationAttribute。 9）Tag，验证结果，继承自BaseValidationAttribute。 这些参数在每个具体的验证器中都是通用的，都被设置为可选的命名参数，使用者可以根据业务需求指定需要的参数。 例如指定错误消息：MessageTemplate = "名称中必须包含kyo字符串!"，具体参数的介绍可以查看上一篇文章。 下面介绍每个验证器的时候就不介绍了。 1、ContainsCharactersValidator——是否包含字符串验证 这个验证器主要是验证字符串对象中是否包含指定的字符串，其具体用法如下： ? 1 2 3 4 [ContainsCharactersValidator("kyo")] [ContainsCharactersValidator("kyo", MessageTemplate = "名称中必须包含kyo字符串!")] [ContainsCharactersValidator("kyo", ContainsCharacters.All)] //ContainsCharacters.Any public string Name { get; set; } 这个验证器有4个重载的构造函数，接收3类参数： 1）字符串characterSet，指定要求包含的字符串 2）枚举ContainsCharacters，包含字符串验证枚举，有2个值：All（待验证的字符串必须包含指定的字符串中所有字符），Any（待验证的字符串只需包含指定的字符串中一个字符） 3）命名参数 2、DateTimeRangeValidator——时间范围验证 这个验证器主要是验证日期对象是否在指定范围内，具体的使用方法如下： ? 1 2 [DateTimeRangeValidator("1990-01-01T00:00:00+08:00", RangeBoundaryType.Exclusive, "2010-01-01T00:00:00+08:00", RangeBoundaryType.Inclusive)] public DateTime Birthday { get; set; } 这个验证器一共有12个构造函数，接收3类参数： 1）日期类型lowerBound、upperBound，字符串类型lowerBound、upperBound，这类参数是接收日期范围的上限和下限，日期类型的lowerBound、upperBound我就不多说了。 需要注意的是字符串类型lowerBound、upperBound，字符串类型的上限下限日期格式必须要符合ISO8601格式，就如我给出的代码一样，具体有关ISO8601知识可以看百度百科：ISO8601，里面有很详细的介绍。 2）枚举RangeBoundaryType，表示日期上限下限的范围，共有3个值：Ignore（忽略边界）、Inclusive（可以等于边界，下限<=值<=上限），Exclusive（不可以等于边界，就是小于边界，下限<值<上限） 3）命名参数 3、DomainValidator——通过检查验证对象，判断它是否属于一个集合 这个验证器主要是验证对象是否在一个指定的集合里，具体的使用方法如下： ? 1 2 [DomainValidator("a1", "a2", "a3")] public string DomainItem { get; set; } 这个验证器只有4个构造函数，接收2类参数： 1）param参数集合domain，指定验证的集合 2）命名参数 4、EnumConversionValidator——检查字符串是否可以转换成枚举中的某一项 这个验证器主要是验证字符串对象是否可以转换成指定的枚举中某一项的值，其具体使用方法如下： ? 1 2 3 4 5 6 7 public enum ValidationEnum { A = 1, B = 2 } [EnumConversionValidator(typeof(ValidationEnum))] public string EnumItem { get; set; } 这个验证很简单，只有2个构造函数，接收2类参数： 1）枚举的类型enumType，指定要验证的枚举类型 2）命名参数 5、HasSelfValidation——自我验证，只能用于类，为SelfValidationAttribute服务 这个验证器比较特殊，它无法通过企业库的配置工具进行配置，它仅仅是为要进行自验证的类添加一个表示，其本身没有什么业务逻辑，同时它也只能作用于类上，其具体用法如下： ? 1 2 [HasSelfValidation] public class TestValidation 由于其本身没有业务逻辑，所以不需要接收任何参数。 […]
View Details本文是为后面的学习之路做铺垫，简单介绍下企业库中的Validation模块的一些相关知识，包括Validation模块的简介、用途、使用方法、默认提供的多种验证器的介绍等。 一、简介及用途 在实际的项目开发中，我们总会需要对数据进行验证，以保证数据的可靠性，而为了使这些验证可以在不同的地方进行复用（如winform、web、WPF等），就需要将验证进行封装，EntLib的Validation模块就为我们解决了这个问题而产生的，其内置了多种常见的验证器，如字符串、日期、类型转换、正则表达式等，同时还提供了自定义验证的接口，方便我们根据实际的业务需求进行扩展。 同时，在Validation模块中还为我们加入了ASPNET、WINFORM和WCF的验证器。 二、使用方法 企业库的Validation模块为我们提供了2种验证方式： 1、在具体的类、属性、字段和方法前添加特性，如：[StringLengthValidator(1, 25)] 2、使用企业库提供的配置工具，通过配置的方式将验证信息存入配置文件 当然你也可以动态的添加验证规则，这个就不是常规使用方式了，这里就不讨论了。 首先介绍下第一种验证方式： 在最新的EntLib5中，Validation模块被进行了修改，各验证Attribute的继承也进行了修改，导致了原有的4.1直接在字段等前面书写Attribute无法使用。 会显示错误信息：StringLengthValidator不是一个有效的AttributeClass 参考园子里：Enterprise Library 5.0 中的Validators 在上面链接的文章里已经需要引用System.ComponentModel.DataAnnotations命名空间，主要原因就是Validation模块的所有验证器都是继承自命名空间System.ComponentModel.DataAnnotations下的ValidationAttribute类（MSDN描述：作为所有验证特性的基类），所以我们如果需要使用特性的方式为实体类或字段等进行验证时必须为项目添加System.ComponentModel.DataAnnotations引用。 接着我们来看下，如何使用特性进行验证： 在代码中引入：
|
1 2 |
using Microsoft.Practices.EnterpriseLibrary.Validation; using Microsoft.Practices.EnterpriseLibrary.Validation.Validators; |
然后就可以在类、属性、字段和方法前添加特性了，下面是一个简单的字符串长度验证，表示输入的用户名长度必须在1-16之间：
|
1 2 3 4 5 |
[StringLengthValidator(1, 16, MessageTemplate = "用户名长度必须在1-16位之间")] [StringLengthValidator(1, 16, MessageTemplateResourceType = typeof(EntlibStudy.Model.Properties.Resources), MessageTemplateResourceName = "SIDMessage")] public string Sid { get; set; } |
这边有2点需要注意： 1、我书写了2种验证失败的错误消息，一种是直接书写MessageTemplate，这种方式的好处就是简便（在使用企业库配置工具进行配置时也是设置这个属性），另一种是将错误消息统一放在一个资源文件中，这种的好处是可以将所有的错误消息统一管理，而且如果项目需要进行国际化处理时，可以直接添加新的资源文件即可，坏处是书写起来比较烦，需要指定资源文件的类型及对应消息的资源名。 具体关于StringLengthValidator的使用在下面会讲到。 2、使用特性进行验证时，特性只能应用于public的字段或属性，否则会报错。在3.0以前没有自动属性时我们通常会使用一下方式书写属性：
|
1 2 3 4 5 6 7 |
[StringLengthValidator(1, 16, MessageTemplate = "用户名长度必须在1-16位之间")] private string _aid; public string Aid { get { return _aid; } set { _aid = value; } } |
很不幸的是，这种方式是错的，因为特性指定的字段是private的，而且就算把特性书写到属性Aid上也是不可行的，因为最终还是为_aid赋值。 接下来应该是介绍如何使用企业库的配置工具进行配置了，不过有关配置的方法园子里已经有很多人写过了，想学习的朋友可以到这边查看： Microsoft Enterprise Library 5.0 系列(三) Validation Application Block (高级) Enterprise Library 4.1 Validation Block 快速使用图文笔记 这2篇都已经将每步的配置进行截图，已经很详细了，我就不多介绍了。 三、Validation模块内置的多种验证器的介绍 在Validation模块中已经内置了很多验证器，这些验证器也有所不同，我自己总结了一下这些验证的分类： 1、可作为特性的验证器，这种验证器是可以直接通过特性为类、属性、字段段进行验证，同时又可以通过配置进行验证。主要有： ContainsCharactersValidatorAttribute——是否包含字符串验证 DateTimeRangeValidatorAttribute——时间范围验证 DomainValidatorAttribute——通过检查验证对象，判断它是否属于一个集合 EnumConversionValidatorAttribute——检查字符串是否可以转换成枚举中的某一项 HasSelfValidationAttribute——自我验证，只能用于类，为SelfValidationAttribute服务 IgnoreNullsAttribute——可为空验证 NotNullValidatorAttribute——不为空验证 ObjectCollectionValidatorAttribute——对象集合类型验证 ObjectValidatorAttribute——对象类型验证 PropertyComparisonValidatorAttribute——属性比较验证 RangeValidatorAttribute——范围验证，判断对象是否在一个指定范围内 RegexValidatorAttribute——正则表达式验证 RelativeDateTimeValidatorAttribute——检查日期是否属于一个范围相对于当前时间或日期 SelfValidationAttribute——对调用一个方法进行自验证 StringLengthValidatorAttribute——字符串长度验证 TypeConversionValidatorAttribute——类型转换验证，判断是否可以转换成指定类型 ValidatorComposition——验证组合器，可以将不同的验证组合在一起 2、独立验证器，主要是为第一种验证服务，可以进行多种验证组合在一起进行复杂验证，如： AndCompositeValidator——组合验证，逻辑与验证，所包含的多种验证全部通过则通过 OrCompositeValidator——组合验证，逻辑或验证，所包含的多种验证有一个通过则通过 3、自定义验证，这种则是为需要根据自己的业务逻辑进行扩展验证所提供的一个扩展。 首先来介绍下第一种验证，可作为特性的验证器： 这类验证工作原理简单的说就是通过特性类来接收要验证的信息，再通过特性类的DoCreateValidator来创建相应的验证类来进行验证。 *具体验证器特性类 *这类验证器的特性最终都是继承自抽象类：BaseValidationAttribute，在这个类的主要作用就是为子类提供错误消息和规则的抽象封装
|
1 |
public abstract class BaseValidationAttribute : ValidationAttribute |
主要有以下几个字段及方法： 1、ruleset：规则集，开发人员可以为要验证的对象设置规则集，可以在每个规则集下建立针对某个字段或属性等的不同验证方式，例如在A规则集中，对Name字段需要有长度1-16的限制，而在B规则集中则是是否包含“test”字符串，这样通过制定不同的规则集则可以根据实际需求进行不同的验证。 2、messageTemplate，消息模板，指定验证不通过的错误消息 3、messageTemplateResourceType，消息模板所在资源类型，指定消息所存放的资源的类型 4、messageTemplateResourceName，消息模板所在资源名称，指定消息所存放的资源名称 5、tag，验证标签，获取或设置标签所代表的特征验证的结果记录 6、string GetMessageTemplate()，获取消息模板的方法，通过指定的messageTemplateResourceType和messageTemplateResourceName获取错误消息 7、bool IsValid()，重写ValidationAttribute.IsValid方法 在具体的验证特性类和BaseValidationAttribute之间还存在着2个特性类：
|
1 |
public abstract class ValidatorAttribute : BaseValidationAttribute, IValidatorDescriptor |
*这个类的作用是抽象出验证逻辑以供子类使用： 1、方法CreateValidator，调用DoCreateValidator创建的Validator实例，并将tag和消息模板赋给Validator实例。 2、方法DoCreateValidator，用以创建实现Validator类的特定验证实例，以供各验证器进行验证。
|
1 |
public abstract class ValueValidatorAttribute : ValidatorAttribute |
*这个类的作用是为各验证器的特性类提供抽象，同时重写了父类方法： 1、方法IsValid，重写了BaseValidationAttribute.IsValid，用以判断对象值是否有效。 2、方法FormatErrorMessage，重写了ValidationAttribute，格式化错误消息 3、属性Negated，用以获取或设置否定逻辑 这样我们就可以清楚的知道每个验证器特性类的具体继承关系了： BaseValidationAttribute->ValidatorAttribute ->ValueValidatorAttribute ->具体验证器特性类，看图可以更加直观一点（为了看的清楚，我这边仅放了2个具体的验证器特性类）： 至于具体的验证器特性类则根据不同业务逻辑进行设置，这边就不讲解，想了解的朋友可以或直接看源代码。 *具体验证类 在上面已经说过，具体的验证器验证是通过验证器的特性类（如：StringLengthValidatorAttribute）调用ValidatorAttribute类中的DoCreateValidator方法来创建具体验证器（如：StringLengthValidator）来进行验证。 […]
View Details