使用實體框架，首選方式？

假設我們已經創建了實體模型，那麼使用它的首選方法是什麼？我個人無法彌補我的心..使用實體框架，首選方式？

使用ModelAdapter：

public statiс Product[] GetProducts() 
{ 
     using(Entities ctx = new Entities()) 
     { 
       return ctx.Product.ToArray(); 
     } 
} 



Product[] ps = ModelAdapter.GetProducts(); 
// ... 
ModelAdapter.UpdateProduct(p);

看起來整潔;
但是，有時會創建/釋放上下文，對象會與上下文失去聯繫;

到位使用上下文：

using(Entities ctx = new Entities()) 
{ 
     Product[] ps = ctx.Product.ToArray(); 

     // ... 

     ctx.SaveChanges(); 
}

有效
但是，代碼變得凌亂

混合模式，妥協？

擴展方法：

using(Entities ctx = new Entities()) 
{ 
    Product[] ps = ctx.GetProducts(); 
    // ... 
    ctx.UpdateProduct(p); 
}

其實現在，我想辦法＃4，實施實用方法，如擴展上下文。所以我可以使用一個上下文，並對這個上下文進行多次調用。

來源

2011-05-10 Petr Abdulin

通常使用任何符合您需求的，可維護且符合應用程序複雜性的任何內容。你應該考慮一下幾點：

Never share context among requests，根據您的需要使用上下文每個請求，每個動作或每個方法。
如果你想單元測試你的應用程序，你可以發現靜態方法，有時也擴展方法可能是一個問題。但是用EF測試應用程序是a separate problem。
如果要修改或插入單個工作單元中的更多項目，可以發現每種方法的上下文不是您需要的
許多開發人員喜歡使用存儲庫模式將訪問EF功能與應用程序的其餘部分。它有自己的pros and cons。

來源

2011-05-12 07:43:11

謝謝@拉迪斯拉夫！這絕對是一個很好的問題包裝。鏈接中和周圍的許多有用的信息。 – 2011-05-12 08:27:16

在開發Web應用程序時，我一直在使用每個Web請求創建的共享上下文。然後，您可以使用「ModelAdapter」方法並保留封裝，但仍然在相同的上下文中操作。我已經使用了很多，並沒有遇到任何問題。

來源

2011-05-10 12:31:47

每個請求的上下文是一個很好的方法，除非你有一些令人信服的理由否則。它使設計在邏輯上也保持簡單 - 對於請求和EF上下文來說1：1。 – Yuck 2011-05-10 12:34:43

通常情況下，我會去執行一個處理EF的複雜問題，通過使用Repository pattern來提取，但只要我需要它就可以使用上下文。（場景3）

通過「只要我需要它」我的意思是隻要服務電話需要。我不希望ObjectContext堅持通過多個服務調用，因爲我需要處理它的狀態。創建新的ObjectContext的成本可以忽略不計。

我認爲在許多方面你的ModelAdapter也提取了EF複雜性，但是基於它的靜態特性，如果你決定堅持ObjectContext，你可能會遇到併發場景中的問題。現在實施的方式可能無法爲您提供更復雜查詢所需的靈活性（加入訂單< - > OrderDetail < - > Product）。

來源

2011-05-10 12:39:45

使用實體框架，首選方式？

回答

相關問題