如果您計劃序列化您的POCO，您是否需要放棄EntityFramework中的代理對象？

我很困惑。整個代理對象似乎是通過使用延遲加載和更好的更改跟蹤來提高性能。但是，當您從Linq檢索代理結果到EF查詢並且希望通過HTTP將結果作爲JSON返回時，由於存在類型不匹配，您將因序列化而發生錯誤。如果您計劃序列化您的POCO，您是否需要放棄EntityFramework中的代理對象？

所有解決方案都表示關閉代理服務器。那麼如果你不能使用它們，那麼它們有什麼意義呢？我錯過了什麼，如何返回序列化的代理對象，而不實例化新的非代理匿名類型或POCO類型（對象分配）來鏡像我要返回的每個對象？

來源

2013-03-25 brushleaf

代理對象的序列化將遞歸地觸發所有導航屬性的延遲加載。這是你想要達到的目標嗎？在高度連接的模型中，它可能會導致「完整的數據庫」。 – 2013-03-25 09:51:05

使用延遲加載/代理的性能改進是，您不會一次抓取所有數據，從而更快地往返數據庫，減少減慢甚至阻止其他數據庫操作的可能性。如果你知道你會加載所有的數據，它不一定是一個性能的改善。

也就是說，如果您不能使用Include（...）（由於其侷限性，例如GroupBy），有一些選項。

要加載具有多次到DB的數據的數據，您可以使用引用或集合屬性上的Load方法顯式加載數據而不訪問它。您可以然後禁用代理生成。（http://blogs.msdn.com/b/adonet/archive/2011/01/31/using-dbcontext-in-ef-feature-ctp5-part-6-loading-related-entities.aspx）

如：

context.Entry(entityObj).Reference("PropertyName").Load(); 
context.Entry(entityObj).Collection("PropertyName").Load();

如果你想利用延遲加載W /代理的某些屬性，但要避免試圖延遲加載他人一旦環境被設置WCF數據契約序列化，您可以在離開數據庫上下文的範圍之前分離實體。

EntityA a = null; 
EntityA a2 = null; 

using (var db = new TestEntities()) 
{ 
    a = db.EntityAs.Where(ea => ea.Id == 1).Single(); 
    db.Entry(a).State = System.Data.EntityState.Detached; 

    a2 = db.EntityAs.Where(ea => ea.Id == 2).Single(); 
} 

var b1 = a.EntityB; // c will remain null; no exception thown 
var b2 = a2.EntityB; // blows up b/c it attempts to lazy load

來源

2013-03-26 22:21:08 Moho

如果您計劃序列化您的POCO，您是否需要放棄EntityFramework中的代理對象？

回答

相關問題