备注:本文的源代码例子,使用的数据库为SQL Server 2005下的Northwind示范数据库,同时为相关表建立了TimeStamp列。



  LINQ 是Visual Studio 2008中提供的一系列新特性,用以扩展C#或者Visual Basic语言,提供了强有力的查询能力。作为LINQ的组成部分,LINQ to SQL提供了将关系数据作为对象处理的运行时架构。从某种程度上说,它相当于是微软提供的类似于NHibernate和Castle之类的ORM工具或框 架。当我们需要对数据库进行访问时,LINQ to SQL常常会成为我们的首选。

  在LINQ to SQL中,关系数据库数据模型中的所有变量都是强类型的,它提供了编译时验证以及智能感知等优点。我们可以使用查询表达式(包括查询语法和方法语法)从数据库中获取数据。

  然而,强类型并不利于对数据操作进行抽象,因此,开发人员就不得不为每个实体对象定义特定的类,从而导致大量的重复代码。如果我们可以实现一个共同的基 类,封装公共的数据操作,例如Select、Where、Add、Update和Delete,这对于开发N层应用程序而言,是非常有用的。

  所幸,利用泛型可以帮助我们实现这一目标。方法是调用DataContext的GetTable<T>()方法。例如,我们可以实现Where方法,通过传递一个Lambda表达式找到我们希望获得的结果:

public IList<TEntity> Where(Func<TEntity, bool> predicate)
{
    InitDataContext();
    
return m_context.GetTable<TEntity>().Where(predicate).ToList<TEntity>();
}

这很简单,我们甚至可以利用动态查询,暴露一些方法去接收条件表达式:

public static class DynamicQueryable
{
    
public static IQueryable<T> Where<T>(this IQueryable<T> source, string predicate, params object[] values)
    {
        
return (IQueryable<T>)Where((IQueryable)source, predicate, values);
    }
public static IQueryable Where(this IQueryable source, string predicate, params object[] values)
    {
        
if (source == nullthrow new ArgumentNullException("source");
        
if (predicate == nullthrow new ArgumentNullException("predicate");
        LambdaExpression lambda 
= DynamicExpression.ParseLambda(source.ElementType, typeof(bool), predicate, values);
        
return source.Provider.CreateQuery(
            Expression.Call(
                
typeof(Queryable), "Where",               
                
new Type[] { source.ElementType },
                source.Expression, Expression.Quote(lambda)));
    }
}
public IList<TEntity> Where(string predicate, params object[] values)
{
    InitDataContext();
    
return m_context.GetTable<TEntity>().Where(predicate, values).ToList<TEntity>();
}

   当然,对于抽象一个基类而言,查询并没有问题,因为我们在调用这些方法时,是不需要实体属性的,也不必关心Lambda表达式的组成。

  关键的问题是如何更新或删除数据表记录。在更新或删除它之前,我们必须获得要操作的实体。而查询的关键字通常是记录的ID。此外,在Data Context中的Object Identity和Change Tracking也需要对象的ID来跟踪它的变化。ID通常是自增长字段或者Guid字段,并作为表的主键。这样我们就可以根据它获得实体:

public void Update(Employee employee)
{
    LinqSampleDataContext context 
= new LinqSampleDataContext();
    Employee emp 
= this.Where(e => e.EmployeeID == employee. EmployeeID);
    emp.FirstName 
= "First Name";
    emp.LastName 
= "Last Name";
    context.SubmitChanges();            
}

  显然,如果使用泛型例如TEntity,我们并不知道实体的属性。没有关键字,我们又该如何关联已经存在的记录的变化呢?LINQ引入了Attach方法,通过它可以将修改的对象附加到Data Context中。Attach方法具有三个重载版本,如下所示:
Attach(Object entity): 以未修改状态将实体附加到DataContext中;
Attach(Object entity, bool asModified): 以修改或未修改状态将集合中的所有实体附加到DataContext中;
Attach(Object entity, Object orginal): 通过指定实体及其原始状态,以修改或未修改状态将实体附加到 DataContext。.
Attach方法通常用来将反序列化的实体与DataContext的一个新实体关联。但我们也可以将一个DataContext中的实体关联到另外一个DataContext中。在修改或删除操作中,这一方法是非常有用的。

例如,我们根据另外一个DataContext中已修改的实体更新记录:

public void Update(TEntity changedEntity)
{
    InitDataContext();
    
try
    {
        m_context.GetTable
<TEntity>().Attach(changedEntity, true);
        m_context.SubmitChanges();
    }
    
catch (ChangeConflictException)
    {
        m_context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
        m_context.SubmitChanges();
    }       
}

   这样的实现看起来很美,却远远不够。我们不能附加一个修改过的实体,除非该实体所对应的表中具有TimeStamp列(或者主键字段的IsVersion 为true)。因此,我们需要在数据库中添加列,使其类型为Timestamp,或者在LINQ to SQL设计器中将ID属性的IsVersion属性设置为true。我的建议是为所有数据表创建一个TimeStamp列,它可以提高系统的性能,因为在 处理并发的时候,系统只需要检查主键和TimeStamp是否有变化,而不需要检查所有的字段。

  事实上,我们也可以通过泛型传递原始的实体值,这种方法就不需要为每个表添加TimeStamp列,方法是使用Action<T> 委托,代码段如下所示:

public void Update(TEntity originalEntity, Action<TEntity> update)
{
    InitDataContext();
    
try
    {
        m_context.GetTable
<TEntity>().Attach(originalEntity);  
        update(originalEntity);
        m_context.SubmitChanges();
    }
    
catch (ChangeConflictException)
    {
        m_context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
        m_context.SubmitChanges();
    }       
}


现在,我们可以通过传递Lambda表达式来调用该方法:
[TestMethod()]

public void UpdateWithAction()
{
    LinqSampleDataContext context 
= new LinqSampleDataContext ();
    EmployeeAccessor accessor 
= new EmployeeAccessor();
    Employee employee 
= context.Employees.Single(e => e.EmployeeID == 1);
    accessor.Update(employee, t 
=> { t.FirstName = "First"; t.LastName = "Last"; });
}

遗憾的是,这样的测试用例有时却无法通过,会抛出NotSupportedException异常,异常的信息如下:An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext.  This is not supported.

原因何在? 究竟发生了什么? 真正的原因是我们所处理的实体与其他实体之间存在关联。如图1所示:

 

图1  具有关系的实体对象

如果移除Employee表中的所有关系,然后重新生成数据模型,测试就能够通过了。

如何解决这个问题呢?显然,显式地去除表的关联并非解决这一问题的最佳方法。这样会影响整个数据模型。对此,Steve Michelotti提出了一个解决方案,也就是利用partial类,为每个数据实体提供一个Detach方法,用以移除实体间的关系:

public partial class Contact
{
    
public void Detach()
    {
        
foreach (Address address in this.Addresses)
        {
            address.Detach();
        }
    }
}
public partial class Address
{
    
public void Detach()
    {
        
this._AddressType = default(EntityRef<AddressType>);
        
this._State = default(EntityRef<State>);
    }
}

  好办法,但还不是最好。首先,采用这种方法,我们需要为每个数据实体都定义Detach方法,这过于繁琐。其次,我们不能用这种方法对该逻辑进行抽象。由于在基类中,我们并不知道TEntity的具体类型。此时,我们应该使用反射技术,以下是我的实现:

private void Detach(TEntity entity)
{
    
foreach (FieldInfo fi in entity.GetType().GetFields(BindingFlags.NonPublic |BindingFlags.Instance))
    {
        
if (fi.FieldType.ToString().Contains("EntityRef"))
        {
            var value 
= fi.GetValue(entity);
            
if (value != null)
            {
                fi.SetValue(entity, 
null);
            }
        }
        
if (fi.FieldType.ToString().Contains("EntitySet"))
        {
            var value 
= fi.GetValue(entity);
            
if (value != null)
            {
                MethodInfo mi 
= value.GetType().GetMethod("Clear");
                
if (mi != null)
                {
                    mi.Invoke(value, 
null);
                }
                fi.SetValue(entity, value);
            }
        }
    }
}


针 对EntityRef<T> 字段,可以通过调用FieldInfo的SetValue方法将值赋为null,以此来移除关联。但是,对于EntitySet则不能用同样的方法,因为 该字段为集合。如果设置为null,会抛出异常。因此我通过反射调用了该字段的Clear方法,清除集合中的所有元素。最后,我实现的Update方法如下所示:

public void Update(TEntity originalEntity, Action<TEntity> update, bool hasRelationship)
{
    InitDataContext();
    
try
    {
        
if (hasRelationship) 
        {
             
//Remove the relationship between the entitis
             Detach(originalEntity);
        }
        m_context.GetTable
<TEntity>().Attach(originalEntity); 
        update(originalEntity);
        m_context.SubmitChanges();
    }
    
catch (ChangeConflictException)
    {
        m_context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
        m_context.SubmitChanges();
    }       
}

删除方法是相似的,除了不需要调用Attach的第二个版本 (Attach(object entity, bool asModified))。代码片断如下:

public void Delete(TEntity entity, bool hasRelationship)
{
    InitDataContext();
    
try
    {
        
if (hasRelationship)
        {
            
//Remove the relationship between the entities;
            Detach(entity);
        }
        m_context.GetTable
<TEntity>().Attach(entity);
        m_context.GetTable
<TEntity>().DeleteOnSubmit(entity);
        m_context.SubmitChanges();
    }
    
catch (ChangeConflictException)
    {
        m_context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
        m_context.SubmitChanges();
    }
}
public void Delete(IList<TEntity> entities, bool hasRelationship)
{
    InitDataContext();
    
try
    {
        
if (hasRelationship)
        {
            
//Remove the relationship
            foreach (TEntity entity in entities)
            {
                Detach(entity);
            }
        }
        m_context.GetTable
<TEntity>().AttachAll(entities);
        m_context.GetTable
<TEntity>().DeleteAllOnSubmit(entities);
        m_context.SubmitChanges();
    }
    
catch (ChangeConflictException)
    {
        m_context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
        m_context.SubmitChanges();
    }            
}

  虽然移除了实体间的关系,但却不用担心最终结果的正确性。Attach方法只负责将实体与DataContext的一个新实例进行关联,并跟踪实体的变 化。在提交修改时,DataContext会检查映射的数据库中实际的值,然后再根据传递进来的实体更新或删除记录。特别的,我们需要在数据库中设置级联 的Action,如图2所示:

 

图2:设置删除规则

  如果没有action,在删除实体时,可能会抛出System.Data.SqlClient.SqlException异常,信息如下:

The DELETE statement conflicted with the REFERENCE constraint "FK_Orders_Employees". The conflict occurred in database "Northwind", table "dbo.Orders", column 'EmployeeID'.

  或许,你已经注意到在每个方法中都调用了InitDataContext方法,实现如下:

private TContext m_context = null;
private TContext CreateContext()
{
    
return Activator.CreateInstance<TContext>() as TContext;
}
private void InitDataContext()
{
    m_context 
= CreateContext();
}

  为何需要为每个方法创建一个DataContext实例?原因在于DataContext的缓存机制。如果创建了一个DataContext的新实例,然 后通过它查询数据库的数据,再修改其值;假设使用同一个实例执行下一次查询,DataContext就会返回存储在内部缓存中的数据,而不是重新映射数据 表中的列。更多信息,请参考Linq in Action.

  因此,最佳实践应该是为每个操作创建一个新的DataContext实例。不用担心性能的问题,DataContext属于轻量级的资源。

  再来看看并发的问题。默认的选项是乐观并发(Optimistic Concurrency)。一旦保存了值, DataContext会检查之前的值是否更改。如果发生冲突,DataContext需要知道是否:自动重写之前的修改,或者保存之前的修改,或者以某 种方式合并修改。

  关于并发的问题并非本文讨论的问题。我们无法确定哪一种方法最好,或者最差,这需要视业务逻辑而定。通常,我会以last submit win的策略处理并发。因此,我封装了SubmitChanges方法,并将其定义为虚方法。若有必要,子类可以重写该方法:

public class AccessorBase<TEntity, TContext>
    
where TEntity : classnew()
    
where TContext : DataContext, new()
{
    
private TContext m_context = null;
    
protected virtual bool SubmitChanges(TContext context)
    {
        
try
        {
            context.SubmitChanges(ConflictMode.ContinueOnConflict);
            
return true;
        }
        
catch (ChangeConflictException)
        {
            context.ChangeConflicts.ResolveAll(RefreshMode.KeepCurrentValues);
            context.SubmitChanges();
            
return true;
        }
        
catch (Exception ex)
        {
            LogService.Error(
"Submit Changes error.", ex);
            
return false;
        }
        
finally
        {
            context.Dispose();
        }
    }
    
public bool Update(TEntity originalEntity, Action<TEntity> update, bool hasRelationship)
    {
        InitDataContext();
        
try
        
{
            
if (hasRelationship)
            {
                
//Remove the relationship between the entitis
                Detach(originalEntity);
            }

            m_context.GetTable
<TEntity>().Attach(originalEntity);

            update(originalEntity);

            SubmitChanges(m_context);
      }
      
catch (InvalidCastException ex)
      {
          LogService.Error(
"Update Entity error.", ex);
          
return false;
      }
      
catch (NotSupportedException ex)
      {
          LogService.Error(
"Update Entity error.", ex);
          
return false;
      }
      
catch (Exception ex)
      {
          LogService.Error(
"Update Entity error.", ex);
          
return false;
      }    
    }
}

现在,我们拥有了一个通用的公共类,实体对象的访问类可以继承它。例如:

public class EmployeeAccessor:AccessorBase<Employee,NorthwindDataContext>
{
}


你不需要实现任何方法,就能够很方便地对实体对象进行操作:
[TestMethod()]

public void UpdateEmployee()
{
    EmployeeAccessor accessor 
= new EmployeeAccessor();
    IList
<Employee> entities = accessor.Where(e => e.EmployeeID == 1);
    
if (entities != null && entities.Count > 0)
    {
        entities[
0].FirstName = "Bruce";
        entities[
0].LastName = "Zhang";

        accessor.Update(entities[
0],true,true);
    }
}

你甚至可以直接让Employee实体类继承基类:

public partial class Employee:AccessorBase<Employee,NorthwindDataContext>
{
}


这种方法类似于充血模式,正如Martin Fowler在Anemic Domain Model一文中提到的那样。