为何需要为每个方法创建一个DataContext实例？原因在于DataContext的缓存机制。如果创建了一个DataContext的新实例，然后通过它查询数据库的数据，再修改其值；假设使用同一个实例执行下一次查询，DataContext就会返回存储在内部缓存中的数据，而不是重新映射数据表中的列。更多信息，请参考Linq in Action.
因此，非常好的实践应该是为每个操作创建一个新的DataContext实例。不用担心性能的问题，DataContext属于轻量级的资源。
再来看看并发的问题。默认的选项是乐观并发（Optimistic Concurrency）。一旦保存了值， DataContext会检查之前的值是否更改。如果发生冲突，DataContext需要知道是否：自动重写之前的修改，或者保存之前的修改，或者以某种方式合并修改。
关于并发的问题并非本文讨论的问题。我们无法确定哪一种方法最好，或者最差，这需要视业务逻辑而定。通常，我会以last submit win的策略处理并发。因此，我封装了SubmitChanges方法，并将其定义为虚方法。若有必要，子类可以重写该方法：
public class AccessorBase<TEntity, TContext>
where TEntity : class, new()
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
where TEntity : class, new()
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
