LINQ中的数据模型验证

在讲MVC的token的时候，我简单的说了一下如果用LINQ生成实体的话如何做业务逻辑验证。现在我来详细说一下：

        [Column(Storage="_userMail", DbType="VarChar(100)")]
        public string userMail
        {
            get
            {
                return this._userMail;
            }
            set
            {
                if ((this._userMail != value))
                {
                    this.OnuserMailChanging(value);
                    this.SendPropertyChanging();
                    this._userMail = value;
                    this.SendPropertyChanged("userMail");
                    this.OnuserMailChanged();
                }
            }
        }

上面代码是dbml的designer类，是由LINQ自动生成的代码，从代码中可以看到LINQ为userMail的字段生成了get，set方法，留意一下set方法里面，首先调用了this.OnuserMailChanging(value)的方法，也就是说我们可以在这个方法里面做一些业务逻辑的判断，如：

       partial void OnuserMailChanging(string value)
        {
            Regex reg = new Regex(@"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*");


            if (!reg.IsMatch(value))
            {
                throw new ArgumentException("format error!");
            }
        }

我在OnuserMailChanging方法中去判断传入的Value是否是邮件格式，这个方法会在实体赋值的时候（set）的时候就调用，如果格式错误，则报错，不再进行赋值，如果我们试图在Changing方法中就对value进行过滤HTML字符的操作，那么实际上是无效的，首先是形参跟实参的关系，改了value的值实际上不会更改到实参的值，其次如果在Changing方法里面就更改_userMail字段的值，如下所示：

        partial void OnuserMailChanging(string value)
        {
            _userMail = FilterContent(_userMail);
        }

在Changing事件中过滤并且赋值给字段，这么改实际上是可行的，但是留意下desinger类里面的set处理中当调用完Changing事件之后又会把value值重新赋给字段，那么之前Changing事件里面所做的赋值操作实际上是没有意义的。有人说可以把后面的赋值代码去掉，实际上desinger类不主张修改，因为该类是自动生成的，你所做的修改实际上下次更改layout的时候又会被覆盖掉了。最好的做法是把过滤放到Changed事件里面，留意下set处理中Changed事件是在赋值后，所以在里面更改字段的值是有意义的，如：

        partial void OnuserMailChanged()
        {
            _userMail = FilterContent(_userMail);
        }

这样把Changing与Changed相结合，在实体中即做格式验证，又做脚本过滤，才能使实体更加健壮！