亂亂寫 Blog

上週將 Entity Framework ( 以下簡稱 EF ) 至正式的專案之中

資料庫都正式來並且拉好 PK FK UK 等等的條件

一開始的想法是原本可以將 SQL 語法、 Enterprise Library 丟在一邊就可以搞定一切

我實在是太甜了 ( 太天真了 ) 

 

比方在一個「關聯式」的資料庫中大部分都會出現 mapping table ，這時用 EF 就很頭大

類似

A表	對應表	B表
1	1a	a
2	2b	b
3	3c	c

 

出現以下一堆不知所以然的錯誤

System.InvalidOperationException: 一個實體物件不能被多個 IEntityChangeTracker 的執行個體參考。

System.InvalidOperationException: 無法將此物件加入到 ObjectStateManager，因為它已經有 EntityKey。請使用 ObjectContext.Attach 來附加已經有現有索引鍵的物件。

System.InvalidOperationException: 無法定義這兩個物件之間的關聯性，因為它們是附加到不同的 ObjectContext 物件。

Add 的物件必須要做 Detach

 

簡單來說就是當要透過 ObjectContext 去修改關聯時，它無法判斷是要新增呢？還是真的換一個 id 而已

花了整整一天的時間就是想要用 EF 可以排除以上的錯誤，試了四、五種方式才發現一個關鍵性的問題

EF 壓根無法判斷你要做的動作，因為就以對應表來說裡面的欄位就是直接去抓 A 表 or B 表的值，而不是真的從 對應表來的

雖然在新增的時候可以「同時」對 A、B、對應表去新增，但就以現實作業來看我們不太會這麼做。

雖然書上有寫說可以透過 SP 的方式去對應，但做法有點繁、不太方便 ( 尤其是多層的情況下 ) 

 

當處理的表是有去引用別的表的話！

Insert 和 Update 就不建議用 EF ，改回原本的 ADO.NET ( Enterprise Library ) 會是較好的選擇

另外，若是資料表都完全沒有設計出 FK 的機制的話，就沒有以上的問題 ，但~~~~~  這真的不是一個好的方式  ( 認真貌 )

因為所有的資料檢核都要程式來做？那程式已經產生很多的 bug 了，就不要再增加自已的工作量。資料的驗證能交由DB 就給 DB 去做吧！ ( 這個以後會特別寫一個主題 )

由於因為要特別處理 FK 的欄位，所以請務必要擴充 Entity 的 class

 

所以結論是…

ADO.NET 和 Enterprise Library 是無法丟掉不用的 ^^，  另外有特別的語法時也是建議用 SQL 語法寫一寫再給程式碼。 ( 尤其是效能考量時 )

那到底 EF 好不好用呢？？   答案是肯定的！！整個 DTO 物件層 和  Table Schema 對應的部分完全不用寫程式，光是這個工就省了好幾天的時間啦！！再搭配 LINQ 整個又少了一堆的程式碼，  不用再把物件丟到 list 了 。也不需要再用那個很肥的 Dataset

自已在寫程式碼時以前要每一層都寫，一天只能寫 5 個表，現在我一天可以完成 10 個表，還連同 Unit Test 也一併寫好。