ASP.NET MVC3 入门指南之数据验证

无论你编写什么样的网页程序，都需要对用户的数据进行验证，以确数据的有效性和完整性。

ASP.NET MVC3允许你采用一种被称之为“数据注释”的方式来进行数据验证，这种验证包含了客户端浏览器

和服务器端的双重验证。或许你会问为什么要进行两次验证？首先，客户端验证能够直接响应客户，减少了服务

器压力的同时还提高了用户体验，但是你永远不能信任来自客户端的信息（用户可以关闭浏览器的脚本功能，

让你的js验证彻底不起作用），所以服务器端验证也是必须的。如下图所示：

1，常规验证（必填字段、字符串长度、正则表达式验证、范围验证<数值、日期>）

先看一个添加界面的反馈的错误信息

实体类代码如下：

/// <summary>
/// 员工信息
/// </summary>
public class StaffInfo
{
    public virtual int StaffInfoId { get; set; }

    [Required]
    [Display(Name = "登录账号")]
    public virtual string LogID { get; set; }

    [StringLength(10, MinimumLength = 4, ErrorMessage = "{0}的长度必须大于{2}个字符并小于{1}个字符")]
    [Display(Name = "密码")]
    public virtual string LogPassword { get; set; }

    [StringLength(10, ErrorMessage = "{0}的长度不能大于{1}个字符")]
    [Display(Name = "姓名")]
    public virtual string RealName { get; set; }

    [Display(Name = "出生日期")]
    //[Range(typeof(DateTime), "2011-12-31", "1950-1-1", ErrorMessage = "{0}的范围是{1}到{2}")]
    public virtual DateTime Birthday { get; set; }

    [RegularExpression(@"\d{17}[\d|X]|\d{15}", ErrorMessage = "{0}的格式不正确")]
    [Display(Name = "身份证号码")]
    public virtual string IdentityNo { get; set; }

    [RegularExpression(@"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}", ErrorMessage = "{0}的格式不正确")]
    [Display(Name = "邮箱")]
    public virtual string Email { get; set; }

    [Display(Name = "逻辑删除标识")]
    public virtual int IsLogicDelete { get; set; }
}

其中，Required代表必填字段，

StringLength代表字符串长度，

RegularExpression代表正则表达式验证

Range代表范围验证<整数、浮点数、日期>

这4中验证方式可以满足我们常见的验证要求。

使用常规验证请引入命名空间：

using System.ComponentModel.DataAnnotations;

下面我们来验证一下MVC是否进行了客户端和服务器端的双重验证，

首先，我们关闭IE浏览器的脚本功能。

菜单->Internet选项，打开如下界面所示：

单击“自定义级别…”按钮，弹出如下界面： 找到“脚本”->“活动脚本”，选择“禁用”，“确定”。

在看看我们呢禁用脚本后的界面，由于禁用了脚本，连界面的样式都发生了变化，

但是服务器端还是验证了所有数据并返回 了错误信息，如下图所示：

我们可以看到状态栏上，客户端发送请求的过程

2，附加验证（服务器端Json验证、比较验证）

使用附加验证请引入命名空间：

using System.Web.Mvc

  为了演示这两个扩展的验证方法，我们新建一个实体类：

public class StaffInfoEx
{
    public virtual int StaffInfoExId { get; set; }

    [Required]
    //其中StaffInfoEx是控制器的名称，CheckLogId是验证方法
    [Remote("CheckLogId", "StaffInfoEx", ErrorMessage = "登录账号已经被占用,请改用其他账号")]
    [Display(Name = "登录账号")]
    public virtual string LogID { get; set; }

    [StringLength(10, MinimumLength = 4, ErrorMessage = "{0}的长度必须大于{2}个字符并小于{1}个字符")]
    [Display(Name = "密码")]
    public virtual string LogPassword { get; set; }

    [Display(Name = "确认密码")]
    [Compare("LogPassword", ErrorMessage = "密码必须一致")]
    public virtual string LogPasswordConfirm { get; set; }

    [Display(Name = "姓名")]
    public virtual string RealName { get; set; }
}

这里请注意确保Remote声明的控制器名称、验证方法名称拼写正确，否则会导致Create按钮没有响应。

2.1 Remote，服务器端Json验证

请修改URL为：http://localhost:XXXX/staffinfoex。正如实体类中声明的一样，

我们只需要控制类StaffInfoExController中添加如下Json方法就行：

　　　　　　//验证登录账号是否已经被占用
        public JsonResult CheckLogId(string logid)
        {
            var result = db.StaffInfoEx.Count(u => u.LogID == logid) == 0;
            return Json(result, JsonRequestBehavior.AllowGet);
        }

当登录账号字段失去焦点时，会自动调用服务器端json方法验证账号的使用情况。

也就是说Remote声明并没有采用客户端验证，而是直接进行了异步的服务器端验证。

因为像是登录账号这类信息，你没法在客户端进行验证，除非你把所有的登录账号都

发送到客户端。

2.2 Compare，比较验证

只是在实体类中进行了简单的声明，就可以很好的实现类似密码确认的功能，

ASP.NET MVC真的是太给力了。

　　[Display(Name = "确认密码")]
　　[Compare("LogPassword", ErrorMessage = "密码必须一致")]
　　public virtual string LogPasswordConfirm { get; set; }

3，数据库约束验证

此外我们还能使用各种数据库约束验证来保证数据的有效性和完整性。

如果不希望用户使用123456这样的过于简单的密码，我们可以使用check约束

来实现：

ALTER TABLE staffinfoes WITH NOCHECK 
ADD CONSTRAINT chk_logPassword
CHECK (logPassword NOT IN('123','123123','123456'))

其中，staffinfoes是表名称，chk_logPassword是约束名称，logPassword是列名称。

先在我们来添加一个StaffInfo，密码为123456，看看我们的程序会出现什么情况？

错误信息：

INSERT 语句与 CHECK 约束"chk_logPassword"冲突。

该冲突发生于数据库"BingoMvc3DataAnnotations"，表"dbo.StaffInfoes", column  'LogPassword'。 语句已终止。

最后，我们总结一下这三种数据验证方式

1）客户端脚本验证，使用javascript等脚本进行验证，但是这种验证可以轻易的被屏蔽。但是它却能够

提供最好用户体验。

2）服务器端验证，需要回发给服务器验证，可以确保数据在客户端活动脚本被禁用时依然进行数据

验证。缺点是增加了服务器压力。

3）数据库约束验证，这是一种特殊解决办法，比如网站在运行过程中你没法更新网站。所有的压力

都在数据库上，过多的约束会影响网站的响应速度。

此外，ASP.NET MVC的数据验证还可以自由的扩展，以满足不同情况的需求，

自定义数据验证下次再讲。

原文地址：http://www.cnblogs.com/BingoLee/archive/2011/12/23/2298822.html