附加對象vs實體框架中的獨立對象

Question

使用附加對象與分離對象有什麼好處？

我目前在我的倉庫中做的是在我更新或刪除它們之前手動分離我的對象。所以，如果我正在更新或刪除，我不會做一個往返，但我通過ID刪除。我認爲與獨立的場景合作對我來說很合適。難道我做錯了什麼？

我正在使用一個使用asp.net mvc和wcf的n-teir應用程序。

Answer 1

使用附加的對象將允許您操作，跟蹤更改，進行併發優化。在大多數情況下，我使用附加對象進行更新或在有狀態的應用程序中。這也可以讓你延遲加載並從上下文緩存中獲益。如果您以完全的方式使用實體框架，這非常棒，因爲當您需要上下文中的單個對象時，可以減少對數據庫的調用次數。在對數據庫進行查詢之前，使用GetObjectByKey將查詢上下文。如果該對象先前已加載，則會爲您節省往返數據庫的時間。

使用分離對象非常棒！它允許更快的讀取，實現更簡單的對象，實體上下文的更小內存佔用。通過線路發送數據（wcf .. services）也是最好的。任何超出範圍的內容，甚至當您將對象轉換爲域對象時。由於你不需要跟蹤對象，所以這是一個很好的優化。這可以使用實體集上的NoTracking合併選項快速實現。

分離對象還將極大地簡化在EF上下文環境中的工作。在進行更改和保存之前，只需附加對象即可。

注意：使用NoTracking將不允許您使用延遲加載，更改跟蹤，GetObjectByKey或實體框架的任何狀態函數。使用NoTracking，你需要使用加載（「Include（）」）加載相關的實體/導航屬性。 EntityKeys也不會被加載。

編輯：上分離的實體

延遲加載，無法正常工作，因爲它沒有上下文，指的是它的查詢。該實體也可能缺少所需的代理和實體密鑰。

我會極大地建議使用熱切加載。這也可能是最終的優化，因爲很難評估延遲加載的影響。因爲它可能會產生如果您正在迭代集合的情況，它會向集合中的每個對象發出對數據庫的請求。當您擁有大量收藏品時，這可能會很成問題。

Answer 2

entity.User.Attach(model); 
entity.ObjectStateManager.ChangeObjectState(model,System.Data.EntityState.Modified); 
entity.SaveChanges(); 
return View(model);