【IT168 技术文档】
摘要 ：一直对WinForm中没有像WebForm中那样的验证控件耿耿于怀，这几天准备开发一套类似的控件。在网上找到大牛Michael Weinhardt的一个系列文章，写得非常棒，所以基本上按他的思路下来的。

    在获取用户输入及后续的处理过程中，数据校验是关键的一步。本文将对Windows Forms中的校验机制进行探讨，分析如何通过开发自定义验证组件来提供更为高效的验证体验（类似于ASP.NET中的验证控件）。

Windows Forms 验证机制介绍

    简单地说，验证是对数据进行处理前确保其完整和正确的过程。验证可以实现在数据层和业务规则层，而应当在表现层进行前端的”保护”。开发人员通常在UI中为用户提供友好的、可交互的验证体验，而要避免在N层应用程序中进行不必要的网络间往返验证。验证包含数据类型、范围或业务规则等类型，看下面这个简单的例子：


    这个窗体中需要进行下列验证：

    Name，Date of Birth和Phone Number为必填项
    Date of Birth必须为正确的日期值
    Phone Number必须为正确的格式
    新添加的雇员必须年满18岁（杜绝童工）

    要完成这些验证需要一个合适的机制，Windows Forms已经提供了一种，内置在每个控件中。要使控件支持验证，须将它的CausesValidation 属性设置为true，这也是所有控件的默认值。如果控件的CausesValidation 属性设置为true，那么在它将焦点转移到另一个控件（并且它的CausesValidation也为true）时会触发Validating 事件。因此，我们可以处理控件的Validating事件，在这里实现验证逻辑，像下面这样：

private void txtName_Validating(object sender, CancelEventArgs e)
{
    if (txtName.Text.Trim().Length == 0)
    {
        e.Cancel = true;
        return;
    }
}

    Validating 事件提供了CancelEventArgs 类型的参数，它的Cancel属性使我们可以指定控件的值是否有效。如果Cancel为true（即是无效的），焦点仍然停留在无效的控件中；如果Cancel值为false（即通过了验证），则会触发Validated事件，焦点也会转移到新的控件。

    现在，责任落到了我们开发人员这边，要以可视化的方式通知用户数据是否有效，也许你想到的是状态栏，这种方式存在两个问题：

    状态栏只能每次显式一条错误信息，即使窗体包含多个无效的控件输入；
    状态栏离输入控件”很远”，很难确切指明哪个控件出现了错误。

    据传闻，微软曾做过这么一个可用性研究：人们坐在椅子上运行一个程序，状态栏给出一个通知信息叫他们往椅子底下看，这样就可以得到50美元奖金。但在测试期间，竟没有任何人能拿走这50美元！

    此时，ErrorProvider组件是更好的选择：




    ErrorProvider组件的用法非常简单，此处不再赘述，Validating事件的代码如下：

if (txtName.Text.Trim().Length == 0)
{
    errorProvider1.SetError(txtName, "Name is required.");
    e.Cancel = true;
    return;
}

errorProvider1.SetError(txtName, string.Empty);

    CausesValidation、Validating和ErrorProvider提供了控件级验证的基础机制，我们可以用它们对控件逐一进行验证。