从微软的DBML文件中我们能学到什么（它告诉了我们什么是微软的重中之重）~二 DBContext实例中，表实体对象是怎么被加入的

一 DBContext的构造方法，方法的重载

二 DBContext实例中，表实体对象是怎么被加入的

三 分部类是否破坏了单一职责

四 分部方法从另一方面定义了类型的操作规范

五 LINQ实体类中对属性的赋值，变化前与变化后SendPropertyChanging与SendPropertyChanged

六 LINQTOSQL中为我们触发了SendPropertyChanging和SendPropertyChanged，它的真正用意是什么

七 为DBContext对象应该作为其它实体操作类型的基类，并为它提供统一的提交动作

 

 

这个系列的主角将一直是linqtosql.dbml，我们一般叫它数据对象关系映射，或者称为ORM，简单说就是数据库与对象之间作一个关系，这种关系我们称为Mapping，在LinqToSQL中，我们直接将某个数据库对象托到DBML文件中，这种关系映射就形成了，也就是说，以后想操作数据库直接操作DBML中的实体类型就可以了。

我们在使用某种ORM工具时，总有一个习惯，那就是将需要抽象的东西进行抽象，因为在管理起来比较方便，结构上也更符合面向对象，对面LinqToSQL的实体类，我们是否应该把它进行一个抽象？其实，微软在设计LinqToSQL实体类时已经把答案告诉了我们，那就是“要，必须要”，从实体类型用partial修饰符就可以看出，微软很希望我们把它重新进行一行抽象，将自己项目需要的东西加入到实体类中，在项目中，代码可能是这样：

   /// <summary>
   /// 用户实体

 4   /// </summary>
   public partial class UserBases : EntityBase
   {
       /// <summary>
       /// 统一主键
       /// </summary>
       protected override object[] PrimaryKey
       {
           get { return new object[] { this.UserID }; }
       }

       /// <summary>
       /// 字段变化
       /// </summary>
       public override void OnPropertyChange()
       {
           if (this.IsValid)//实体是否验证通过

{
               base.OnLoaded();
               this.PropertyChanged += new PropertyChangedEventHandler(base.PropertyChangedEvent);
           }
       }
    }

 

在UserBases实体中由于它继承了EntityBase这个统一的实体抽象类，所以，在DATA层作统一实体GURD操作时，方法参数和返回值可以写成这样：

protected virtual IQueryable<EntityBase> GetEntities<TEntity>(Expression<Func<TEntity, bool>> queryFunc) where TEntity : EntityBase
{
}

 

对于实体的抽象，不仅是LinqToSQL，对于其实的架构也同样适用。