转载自：http://blog.csdn.net/bitfan/article/details/14231561

EntityFramework走马观花之

CRUD（下）

我在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("\nCurrent Values:");

PrintPropertyValues(entry.CurrentValues);

Console.WriteLine("\nOriginal Values:");

PrintPropertyValues(entry.OriginalValues);

Console.WriteLine("\nDatabase 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开发数据存取层的问题。