如何优雅的使用DbContext

转载自: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开发数据存取层的问题。


 

展开阅读全文

没有更多推荐了,返回首页