每組操作都可重用的ObjectContext或新的ObjectContext？

Question

我是實體框架的新手，並且在業余時間開始使用它。 我的主要問題之一是關於如何處理ObjectContexts。

這些通常是首選/推薦的：

這個

public class DataAccess{

    MyDbContext m_Context;

    public DataAccess(){
        m_Context = new MyDbContext();        
    }

    public IEnumerable<SomeItem> GetSomeItems(){
        return m_Context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        m_Context.DeleteObject(item);
        m_Context.SaveChanges();
    }
}

或這個？

public class DataAccess{

    public DataAccess(){ }

    public IEnumerable<SomeItem> GetSomeItems(){
        MyDbContext context = new DbContext();
        return context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        MyDbContext context = new DbContext();
        context.DeleteObject(item);
        context.SaveChanges();
    }
}

Answer 1

ObjectContext應該是“工作單元”。

本質上，這意味着對於每個“操作”（例如，每個網頁請求），都應該有一個新的ObjectContext實例。 在該操作中，應重新使用相同的ObjectContext。

當您考慮時，這是有道理的，因為事務和變更提交都與ObjectContext實例相關。

如果您不是在編寫Web應用程序，而是在編寫WPF或Windows Forms應用程序，那么它將變得更加復雜，因為您沒有Web頁面加載所提供的嚴格的“請求”范圍，但您明白了。

PS：在您的任何一個示例中，ObjectContext的生存期將是全局的或短暫的。 在兩種情況下，它都不應存在於DataAccess類中-應該將其作為依賴項傳遞

Answer 2

如果您為長時間運行的進程保留了相同的上下文，則對它運行很多查詢 ，則linq-to-sql（我沒有針對實體的linq進行測試，但我想這是相同的問題）變得非常慢（每秒查詢1次）經過大約1000次簡單查詢）。 定期更新上下文可以解決此問題，並且不會花費太多。

發生的情況是上下文會跟蹤您對它所做的每個查詢，因此，如果不進行某種方式的重置，它會變得很胖...另一個問題是它占用的內存。

因此，這主要取決於應用程序的工作方式，是否定期新建DataAccess實例或是否始終保持相同。 希望這可以幫助。

斯特凡

Answer 3

簡要說明一下-這兩個代碼段的基本問題大致相同。 這是我一直在研究的內容，因為您不想同時打開和關閉上下文（請參見第二個示例），因此不確定您是否可以信任Microsoft為您正確處理上下文。

我要做的一件事是創建一個公共基類，該基類可以懶惰地加載Context並實現基類的析構函數來處理事物。 這對於MVC框架之類的東西來說效果很好，但是不幸地導致了必須將上下文傳遞到各個層以便業務對象可以共享調用的問題。

最后，我使用Ninject進行了一些操作，將這種依賴關系注入到每個層中，並使其跟蹤使用情況

Answer 4

盡管我不總是總是創建復雜對象，但我每次都需要創建復雜對象-我也發現，Linq to Sql中的DataContexts和EF中的ObjectContexts最好在需要時創建。

這兩種方法都基於您運行它們的模型執行了大量的靜態初始化，該模型被緩存供后續調用使用，因此您會發現上下文的初始啟動將比所有后續實例更長。

您面臨的最大障礙是，一旦您從上下文中獲得實體，就不能簡單地將其傳遞回另一個實體以執行更新操作或重新添加相關實體。在EF中，您可以重新附加實體適應新的環境。 在L2S中，這個過程幾乎是不可能的。