Pages

2015-07-04

EF的異動偵測DetectChanges機制

EF執行資料庫Update指令時,由於在UI上都會挾帶PK ItemId, 因此我們常用Attach(entity)方式來取代得多下一道Select指令的問題:

// 一般作法,得多一道DB Select指令
var entity = dbContext.Entities.Single(x => x.ItemId = 1);
entity.ItemText = "abc";
entity.ItemKey = 0;
dbContext.SaveChanges();

// Attach方式,不會下一道DB Select指令
EntityType entity = new EntityType();
entity.ItemId = 1;
dbContext.Entities.Attach(entity); // EntityState = Unchanged

entity.ItemText = "abc";
entity.ItemKey = 0;

//dbContext.Entry(entity).State = EntityState.Modified; // 此行不需寫,因為它會讓DB修改所有欄位值,而非指定的欄位,這也是一個隱藏Bug地雷
dbContext.Configuration.ValidateOnSaveEnabled = false; // 因為Entity有些欄位必填,若不避開會有Validate錯誤
//dbContext.ChangeTracker.DetectChanges(); // 不需撰寫此行,因為dbContext.Configuration.AutoDetectChangesEnabled = true (Default)會自動呼叫
dbContext.SaveChanges();

首先令人覺得好奇的是,只是修改一個很單純POCO Entity的屬性值,為何EF會知道異動了? 原來當你Attach(entity)後,EF透過DbSet宣告時virtual關鍵字,暗地把原本的POCO類別ref位址指向內部DynamicProxy類別,這Proxy為每一個屬性Property作了延伸處理,讓內部ChangingTracker記錄了每個屬性的Old, New值及IsModified狀態。可查看一下EF PropertyEntry源碼宣告,就知大概的追蹤異動處理手法。


因此,當一個Property改值時,它會比對新舊值,一旦不一樣就會把EntityState狀態由Unchanged變為Modified,並在SaveChanges()之前自動呼叫DetectChanges()來搜集每個Properties的新舊值變動狀況。在這樣的原則下,上述用Attach(entity)省下DB Select指令的寫法,就藏著一個可怕的Bug,原來只要Property的值沒有異動到,DB指令裏該欄位就不會修改到,這點是筆者尚未明白EF偵測異動原理前遇到的血淚地雷經驗。

// 調整如下,才能確保要修改的欄位值會被DB更新
EntityType entity = new EntityType();
entity.ItemId = 1;
entity.ItemKey = -1; // Entity int類型屬性,預設是0,所以要指定不可能的值造成異動
dbContext.Entities.Attach(entity); // EntityState = Unchanged

entity.ItemText = "abc"; // 字串通常不需要在Attach()前先調值,因為string預設是null,而UI取值通常是String.Empty
entity.ItemKey = 0; // 若事先沒調值,當有UI把某值改為0時,DB執行時並不會修改到此欄位,造成Bug

dbContext.Entry(entity).Property(x => x.ItemKey).IsModified = true; // 可以直接使用這方式強制某欄位要更新,只是查詢集合耗效能而己

dbContext.Configuration.ValidateOnSaveEnabled = false; // 因為Entity有些欄位必填,若不避開會有Validate錯誤
dbContext.SaveChanges();

由於EF預設下都會自動偵測異動(dbContext.Configuration.AutoDetectChangesEnabled=true),尤其在以下操作時都會自動呼叫DetectChanges()比對所有的entry集合的每一個屬性Properties的新舊值,若在大量操作時難免效能不佳,因此特殊情況時,會讓dbContext.Configuration.AutoDetectChangesEnabled=fase,完成複雜的操作,才只作一道dbContext.ChangeTracker.DetectChanges()比對異動。



  • DbSet.Find
  • DbSet.Local
  • DbSet.Remove
  • DbSet.Add
  • DbSet.Attach
  • DbContext.SaveChanges
  • DbContext.GetValidationErrors
  • DbContext.Entry
  • DbChangeTracker.Entries

EntityState是EF執行DB指令重要的判斷依據,不了解底層原理就直接使用Attach(entity),其實隱藏了很多可能Bug錯誤。不過,或許大多數EF使用者不在乎修改資料時多下一道DB Select指令,也就不會遇到這樣的問題了。EF內部行為已為大多數DB操作行為作了合理推斷,不過每個開發者追求效能的心態層次不一樣,想自由穿梭其間,就得多閱讀理論基礎就是了。

Post a Comment