前篇文章主要谈了持久化是不是需要的问题，其实一开始我的想法还是觉得是需要持久层的，就像有人说的持久化可以使在编译时知道你的类型和赋值正与否，而使用那些容器确不能，此时也体现出强类型的好处。如果用类似Hashtable这些的容器会使编译通过，结果可能会在程序运行的时候出错。使用此等容器有好有坏，就如鱼和熊掌不能兼得一般，很难权衡(此等问题，还得再向园子大牛级人物讨教一下)。因为之前我也说过了，用实体层的话，可能会运用大量的反射过程，代价太高。在框架没设计验证时，我一开始就采用的是ORM那种思想，到框架加入验证想法，我的想法随之也改变了！上篇文章先说到这里，先谈谈我的框架中对验证层的相关设计吧！这里我只说明设计的思路，暂无源码提供！
我们的Web程序在验证上，可能会存在两端(服务端和客户端)都得有处理同一个验证的过程。（我这里之所以说两端都得同时处理的话，是因为我相信那句话：“永远不要信赖客户提交的数据”，所以我在服务端还是得重复这个验证过程），那么这里的两端的验证是否存在冗余呢？答案是显而易见的，如果按照老老实实的写代码的话，两端肯定得写各自的代码(js和cs代码)。
好了，我写好了所有Boss规定的所有代码！"啊？什么？",突然Boss告诉我，"小S，这个验证可能不是这样的，可能是文档里我没怎么写清晰，具体的还是得这样做。。。","天呐！老大，您不早说！"，我心里想着。不过也没事，我就改一下js吗！哦，No，还有在cs端也有个小手术。
虽然讲这里改动不是很多，但是产生了连锁改动，有些程序员会放弃（去掉）在服务器端验证代码，嘿，反正你也看不出来，管它呢！我只要快速达到你的要求好了！谁教你当初不想清楚就把文档给我呢！活该！！！去掉服务端的验证，可能影响是不大，但对于遇到恶意性的代码是，那你的好日子也就到头喽！
社会的进步都是在前人的经验累积下来的，设计模式如此，写程序代码的经验未尝不是如此。我们从一次次的摔倒中，知道了如何不去重复同样的错误！这个小小验证又能难倒我们吗？OK，呵呵，说远了！切入正题了，说说我对此类问题的解决方案吧！（感觉和java中struts的Validate有点类似）。。。
我对这验证是这样做的，整体是放在一个xml中(xml只是一个载体之一，也可以是数据库)，而且我把一些常用的验证全都封装好了！先看一下这个验证配置文件的例子：
<field name="txtCargoNo" display-name="货物编号" maxlength="11" type="text">
<depend name="required" />
<depend name="isNumeric" />
<depend name="maxLength" param="11" />
<depend name="minLength" param="11" />
<dpend name="server" reflect-validate="ExportCargo.CargoNumberIsExsit" params-validate="txtCargoNo,EG_ID"/>
</field>
required表示的字段是必填项，当required符合后，就去检测isNumeric填写的是否正确，然后再下一步。值得一提的是，这里存在一个name="server",它表示是一个服务器端即使验证，也就是我们就得使用的ajax异步验证。reflect-validate:是表示响应的服务层所对应的类和方法名,params-validate：表示验证响应的需要的参数。我在里是需要txtCargoNo,EG_ID两个参数，txtCargoNo表示自身参数，EG_ID表示该操作的实体的ID，(因为在编辑时，这步验证必须把自己本身的ID除外)。
JS端的验证过程：载体验证xml载入完毕后缓存，并根据配置文件内容，自动生成js代码且也缓存起来（因为每次提交页验证总是不会改变的）
CS端的表单提交验证过程：当表单Post进来的时候，我会先交给Validate先去除表单的一些特殊符号（如防sql注入的符号，如果是一般文本框得话还得过滤html），清理后生成一个IDictionary<string,string>,再与文档核对，验证里边的元素是否不在文档规定的提交范围内。再次清理后，就交给Validate的Factory,Facotry会反射根据depand的name（如required）动态调用需要对应到哪个CS验证方法，调用之后，如果不符合条件，那么，说明该值是不符合文档规定的范围。如果符合,只要我的Facotry队列还是不为空，我还是再得继续Validate，如此循环，每遇到不符合条件的我就退出。或者只到我发现所有条件都通过我就退出了。（注，这里的反射如果还得提高性能得话，还得去缓存）
CS端的Ajax验证:通常我把这个传送也是通过post方式传递，发送txtCargoNo,EG_ID所填入的信息，后面几步步骤同CS端的表单提交验证过程相似。
注:这里所说的factory方式，js端差不多也是这么做的。
文章写的仓促，无奈手头上还有不少活要干！写先到这里,整体就是这样构架，不知道园子里各位的有何高见？请与大家一起讨论一下。
附上测试例子：http://export.job-mate.com/BookingNote.jobmate?action=Insert
未完，待续。。。
本文转自 netcorner 博客园博客，原文链接：http://www.cnblogs.com/netcorner/archive/2008/07/22/1248458.html ，如需转载请自行联系原作者
