我在Entity Framework系列文章的CRUD上篇中介绍了EF的数据查询，中篇谈到了EF的数据更新，下篇则聊聊EF实现CRUD的内部原理。
跟踪实体对象状态
在CRUD上篇和中篇谈到，为了实现提取和更新数据的功能，EF必须使用某种机制来跟踪实体对象，以便依据对象当前状态生成相应的SQL命令。
这里的关键是区分清楚内存中的数据实体对象和数据库中的记录。
当程序运行时，位于内存中的EF数据实体可以处于以下五种状态之一：
1. Added: 实体对象是新创建的，数据库中没有相应的记录。
2. Unchanged: 从数据库加载到内存后，实体对象属性值没有任何改变。
3. Modified: 至少有一个实体对象属性值被改变。
4. Deleted: 如果用户从实体对象集合中删除了某实体对象，则它将处于此状态。注意数据库中此对象相应的记录还存在。
5. Detached: 此实体对象未被EF所跟踪，属“黑户”和“盲流”。居于这种状态的对象多出现在拥有分布式多层架构的系统中，在后一篇谈到EF数据存取层设计的文章中我将对此再做分析。
现在，一个有趣的问题出现了：
当EF从数据库中提取一条记录生成一个实体对象之后，应用程序可以针对它的操作太多了，EF是怎么知道哪个对象处于哪个状态的？
EF的解决方案是：
为当前所有需要跟踪的实体对象，创建一个相应的DbEntityEntry对象，此对象包容着实体对象每个属性的三个值：
1. Current Value：当前值
2. Original Value：原始值，就是从数据库中刚提取出来的值
3. Database Value：数据库中对应记录的对应字段的值
刚从数据库中提取出来时，Current Value= Original Value = Database Value，以后随着程序的运行，在调用SaveChange()方法之前，Original Value维持不变，但Current Value很可能会变化，而Database Value一般情况下也不变，不过如果其他用户修改了数据库中的相应记录，则EF提供了GetDataBaseValues方法获取Database Value的新值。
所以现在很清楚了：
EF为每一个需要跟踪状态的实体对象创建一个对应的DbEntityEntry对象，保存实体对象各属性的Current Value、Original Value和Database Value三个值，只要比较这三个值，很容易地就知道哪个属性值被修改了，从而生成相应的Update命令。
对于新加入的实体，没有original values和database values
标记为删除的实体，没有current values.
Detached的实体对象（通常是通过网络从客户端发送过来的），没有相应DbEntityEntry对象，因此EF无法跟踪其状态，只能先Attach它，创建好相应DbEntityEntry对象之后，才能保存或更新到数据库中。
众多DbEntityEntry对象的管理由DbContext.ChangeTracker所引用的对象负责。
从实体对象获得它所对应的DbEntityEntry对象很简单，使用以下代码即可：
DbEntityEntry entry=DbContext对象.Entry(实体对象引用);
以下这个示例方法提取并输出指定实体对象属性的所有值：
private static voidPrintChangeTrackingInfo(DbContext context, DbEntityEntry entry)
{
//entry.Entity引用相关联的实体对象
Console.WriteLine(entry.Entity);
//entry.State值指示实体对象当前所处的状态，即前面所述几种状态之一
Console.WriteLine("State: {0}", entry.State);
Console.WriteLine(" Current Values:");
PrintPropertyValues(entry.CurrentValues);
Console.WriteLine(" Original Values:");
PrintPropertyValues(entry.OriginalValues);
Console.WriteLine(" Database Values:");
PrintPropertyValues(entry.GetDatabaseValues());
}
DbEntityEntry对象的CurrentValues/OriginalValues属性是一个DbPropertyValues类型的集合对象，以下方法输出其每个成员的值：
private static void PrintPropertyValues(DbPropertyValues values)
{
foreach (var propertyName in values.PropertyNames)
{
Console.WriteLine(" - {0}: {1}",propertyName, values[propertyName]);
}
}
处理并发冲突
在Web这种高并发的运行环境中，一个用户修改另一个用户正在处理的数据是很容易出现的场景，当这种冲突出现时，EF无法更新数据库中的数据。
举例说明，假设我们有以下实体类：
public class Person
{
public int PersonId { get; set; }
public string Name { get; set; }
public int age { get; set; }
public string Description { get; set; }
}
下面来看第一种情景：要修改的记录己被别人修改。
以下代码模拟了这个场景：
Task t1 = new Task(() =>
{
using (var context = new MyDbContext())
{
Person p =context.People.First();
p.Description ="Description Modified at " + DateTime.Now.ToShortTimeString();
context.SaveChanges();
}
});
Task t2 = new Task(() =>
{
using (var context = new MyDbContext())
{
Person p =context.People.First();
p.age *= 2;
context.SaveChanges();
}
});
t1.Start();
t2.Start();
Task.WaitAll(t1, t2);
试验的结果是：当同一条记录被甲乙两人同时修改时，如果两人修改不同的字段，则每个字段都可以得到新值。
以下是使用SQL Server Profiler截获的EF发往SQL Server数据库的SQL命令：
exec sp_executesql N'UPDATE [dbo].[People]
SET [Description] = @0
WHERE ([PersonId] = @1)
',N'@0 nvarchar(max) ,@1int',@0=N'Description Modified at 18:15',@1=11
exec sp_executesql N'UPDATE [dbo].[People]
SET [age] = @0
WHERE ([PersonId] = @1)
',N'@0 int,@1 int',@0=320,@1=11
可以很清楚地看到：EF能依据修改的实体属性名生成相应的Update命令，从而在外部看来，这相当于“合并”了甲乙两人的修改。
我们可以动手修改上述试验代码，很容易得到下述的另一个结果：
如果甲乙两人修改的是相同的字段，则到底谁胜利，取决于谁发出的SQL命令是最后执行的，即“后来者居上”。
第二种情景：要修改的记录己被其他人删除
这种情景是否出现，取决于数据库先执行哪个EF发出的Update和Delete命令：Update First or Delete First。
- 如果是先Delete后Update，则EF会抛出：DbUpdateConcurrencyException。其给出的信息为：
Store update, insert, or delete statementaffected an unexpected number of rows (0). Entities may have been modified ordeleted since entities were loaded. Refresh ObjectStateManager entries.
- 如果是先Update后Delete，则不会有任何异常出现，其实数据己被删除！但由于EF没有抛出任何异常，所以提交数据更新请求的人对此一无所知，他还以为更新成功了！这实在是不太妙的事！
所以，程序抛出异常是件好事，别害怕异常，要感谢它，它能让我们知道犯错了，知错能改，就是好同志！
话又说回来，应该怎么对付上述的情景呢？
有两个方法。
先来看第一个法子：指定实体对象的某属性用于并发检测。
public class Person2
{
public int Person2Id { get; set; }
public string Name { get; set; }
public int age { get; set; }
[ConcurrencyCheck]
public string Description { get; set; }
}
上述代码是采用Code First的EF代码，如果采用Database First方式，则可在实体设计器中设置相应属性的Concurrency Mode属性值为Fixed。
这样一来，下面尝试更新age属性的代码，
Person2 p = context.People2.First();
p.age *= 2;
context.SaveChanges();
将生成不一样的SQL命令：
exec sp_executesql N'UPDATE [dbo].[Person2]
SET [age] = @0
WHERE (([Person2Id] = @1) AND ([Description] = @2))
',N'@0 int,@1 int,@2 nvarchar(max)',@0=80,@1=1,@2=N'Description Modified at 18:49'
可以看到，加了[ConcurrencyCheck]的属性名和值将出现在Where子句中。
这就是关键所在了：
只要给实体类指定一个或多个并发冲突属性（利用[ConcurrencyCheck]），EF就会把它们作为Where子句的条件加入到生成的SQL命令中，如果Update命令返回结果为0，那肯定是出错了，因为原始记录给别人改了。
这种方式需要在实体类中指定特定的属性作为并发冲突检测依据，如果项目中实体类很多，而且程序需要运行于高并发的环境中，为每个实体类都单独地设定实在太麻烦了。这时，数据库跑来帮忙了。
许多数据库系统支持定义一种唯一标识整条记录的特殊字段，当本记录的任一其他字段值有变动时，这一特殊字段马上就会有一个不同的值。这一字段的值是由数据库生成并维护的，应用程序不要显式设置它。
在EF中，我们可以这样为指定实体类指定一个特殊属性：
public class Person3
{
public int Person3Id { get; set; }
public string Name { get; set; }
public int age { get; set; }
public string Description { get; set; }
[Timestamp]
public byte[ ] RowVersion { get; set; }
}
在SQL Server中相应的字段类型为timestamp。
添加这样的一个字段之后，在Update数据时，如果记录被他人所修改，则EF将总是抛出DbUpdateConcurrencyException，让用户知道有数据冲突发生，从而用户能采取相应行动以保证数据安全可靠。
如果有多个实体类都希望支持并发冲突检测，可以设定一个实体基类，如下所示：
public class EntityBase
{
[Timestamp]
public byte[ ] RowVersion { get; set; }
}
让所有相关实体类都派生自它即可。这是一个偷懒的方法，却很好用。
事务处理
默认情况下，当EF调用SaveChanges()时，会把生成的所有SQL命令“包”到一个“事务（transaction）”中，只要有一个数据更新操作失败，整个事务将回滚。
在多数情况下，如果你总在数据更新操作代码中使用一个而不是多个DbContext对象，并且只是在最后调用一次SaveChanges()，那么EF的默认事务处理机制己经够用了，无需做额外的事情。
然而，如果出现以下的情形，你就必须显式地处理事务了。
第一种情况：你需要分阶段地保存数据，因而需要多次调用SaveChanges()或者执行修改数据库的SQL命令。
请看以下示例代码：
using (var context = new MyDbContext())
{
try
{
Person3 p = context.People3.First();
p.Name ="newName" + (new Random().Next(1, 100));
context.SaveChanges();
context.Database.ExecuteSqlCommand("update Person3 setDescription={0} where Person3Id={1}",
"DescriptionModified at " + DateTime.Now.ToShortTimeString(),
p.Person3Id);
p.age *= 2;
context.SaveChanges();
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
上述代码中，调用两次SaveChanges()，还有一次执行Update命令。
如果在最后一次SaveChanges()中出现异常，虽然最后一次没成功，但你会发现前两次数据己经保存！这就带来了数据不一致的问题。
对于这种场景，你需要显式地编写事务代码了（注：以下代码适用于EF6）：
using (var context = new MyDbContext())
{
using (var transaction =context.Database.BeginTransaction())
{
try
{
……
context.SaveChanges();
context.Database.ExecuteSqlCommand("……);
……
context.SaveChanges();
transaction.Commit();}
catch (Exception e)
{
Console.WriteLine(e.Message);
transaction.Rollback();
}
}
}
特别要注意一定要调用commit()，我测试发现，只要不Commit，即使没有异常发生，事务仍将回滚，数据库中的数据不会更新。
第2种情况，你需要使用多个DbContext保存数据。
以下是处理这种场景的典型代码：
static void TestTransactionScope2()
{
using (TransactionScope scope = new TransactionScope())
{
String connStr = ……;
using (var conn = newSqlConnection(connStr)){
try{
conn.Open();
using (var context1 =new MyDbContext(conn, contextOwnsConnection: false))
{
……
context1.SaveChanges();
}
using (var context2 =new MyDbContext(conn, contextOwnsConnection: false))
{
context2.Database.ExecuteSqlCommand(……);
context2.SaveChanges();
}
using (var context3 =new MyDbContext2(conn, contextOwnsConnection: false))
{
……
context3.SaveChanges();
}scope.Complete();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
finally
{
conn.Close();
}
}}
}
上述代码中有几个关键点：
（1）在构造DbContext对象时，需要把一个己打开的数据库连接对象传给它，并且需要指定EF在DbContext对象销毁时不关闭数据库连接。
为实现此目的，你的DbContext对象应该类似于是这样的，提供两个重载的构造函数：
public class MyDbContext2 : DbContext
{
public MyDbContext2(DbConnection conn, boolcontextOwnsConnection):base(conn,contextOwnsConnection)
{
}
public MyDbContext2():base()
{
}
public DbSet<OtherEntity> OtherEntities { get; set; }
……
}
注意在代码结束时关闭连接。
（2）如果不Commit，则所有数据将不会保存。
（3）你的计算机需要启动MSDTC(分布式交易协调器)，请先在控制面板中打开Distributed Transaction Coordinator服务，否则上述代码将在运行时抛出MSDTC服务不可用的异常。
很明显，当事务需要使用多个不同类型的DbContext对象时，Windows需要启动MSDTC，这会对性能有所影响，因此在开发中应该尽量避免这种情况，如无必要，不要在单个事务中使用多个不同种类的DbContext对象。
小结：
到此为止，我己经把EF中与CRUD的几个话题讨论完了，下一篇将是我的Entity Framework系列的收尾之作，讨论使用EF开发数据存取层的问题。