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

　　　　[Column(Storage="_userMail",DbType="VarChar(100)")]
　　　　publicstringuserMail
　　　　{
　　　　　　get
　　　　　　{
　　　　　　　　returnthis._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)的方法，也就是说我们可以在这个方法里面做一些业务逻辑的判断，如：

　　　partialvoidOnuserMailChanging(stringvalue)
　　　　{
　　　　　　Regexreg=newRegex(@"w+([-+.']w+)*@w+([-.]w+)*.w+([-.]w+)*");
　　　　　　if(!reg.IsMatch(value))
　　　　　　{
　　　　　　　　thrownewArgumentException("formaterror!");
　　　　　　}
　　　　}

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

　　　　partialvoidOnuserMailChanging(stringvalue)
　　　　{
　　　　　　_userMail=FilterContent(_userMail);
　　　　}

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

　　　　partialvoidOnuserMailChanged()
　　　　{
　　　　　　_userMail=FilterContent(_userMail);
　　　　}

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