WPF應用程序中短命的DbContext合理嗎？

Question

在他關於DbContext的書中，@ RowanMiller展示了如何使用DbSet.Local屬性來避免1.）對數據庫進行不必要的往返，以及2.）在應用程序中傳遞集合（使用例如ToList（）創建）（第24頁）。 然后我嘗試遵循這種方法。 但是，我注意到從使用[} - block到另一個，DbSet.Local屬性變為空：

ObservableCollection<Destination> destinationsList;

using (var context = new BAContext())
{ 
   var query = from d in context.Destinations …;
   query.Load();
   destinationsList = context.Destinations.Local; //Nonzero here.
}
//Do stuff with destinationsList

using (var context = new BAContext())
{ 
   //context.Destinations.Local zero here again;
   //So no way of getting the in-memory data from the previous using- block here?
   //Do I have to do another roundtrip to the database here to get the same data I wanted
   //to cache locally???
}

那么，第24頁的重點是什么？ 如果DbSet.Local只能在using-block中使用，我怎樣才能避免傳遞我的集合？ 此外，如果我使用這些短期上下文實例而不是將任何緩存數據交給其他人，那么我如何從更改跟蹤中受益？ 因此，如果上下文應該是短暫的，以釋放連接等資源，我是否可以放棄緩存？ 即我不能同時使用兩者（短期連接但長期緩存）？ 所以我唯一的選擇是將查詢返回的結果存儲在我自己的變量中，這完全是第24頁的動機中不鼓勵的內容嗎？

我正在開發一個WPF應用程序，它可能在未來也將成為多層次的，涉及WCF。 我知道朱莉婭在她的書中有這樣的例子，但我目前無法訪問它。 我在網上找到了其他幾個，例如http://msdn.microsoft.com/en-us/magazine/cc700340.aspx （舊的ObjectContext，但很好地解釋了層間協作）。 在那里，使用了長壽命的背景（雖然提到了缺點，但沒有解決這些問題）。 不僅單個Destinations.Local會丟失，因為您肯定知道查詢提取的所有其他實體也是如此。

[編輯]：在Julia Lerman的書中再讀一遍之后，似乎歸結為EF默認情況下沒有二級緩存; 但是，有些（相當多，我認為）努力，可以添加第三方緩存解決方案，如書中和MSDN上的各種文章，codeproject等中所述。

如果在DbContext書中有關DbSet.Local的部分中提到這個問題，它實際上是在使用{}塊結束時被破壞的第一級緩存（我只是提議使其更透明），我將不勝感激。讀者）。 在第一次閱讀之后我得到了印象DbSet.Local總是會在第二個使用{}塊返回相同的引用（Singleton樣式），盡管有新的DbContext實例。

但是我仍然不確定二級緩存是否是我的WPF應用程序的方式（因為Julia在她的文章中提到了分布式應用程序的二級緩存）？ 或者是通過using {}塊中的一個或一些查詢將我的域模型的聚合根實例（DDD，Eric Evans）放入內存，處理DbContext並僅保存對聚合實例的引用的方法避免長期背景的方式？ 如果你能幫助我做出這個決定，那將是很棒的。

http://msdn.microsoft.com/en-us/magazine/hh394143.aspx http://www.codeproject.com/Articles/435142/Entity-Framework-Second-Level-Caching-with-DbConte http：// blog.3d-logic.com/2012/03/31/using-tracing-and-caching-provider-wrappers-with-codefirst/

Answer 1

Local屬性提供“此集合中所有已添加，未更改和已修改實體的本地視圖”。 與所有更改跟蹤一樣，它特定於您當前使用的上下文。

DB Context是用於加載數據和准備更改的工作空間。

如果兩個用戶同時添加更改，則在保存更改之前，他們不得知道其他更改。 他們可能會丟棄他們准備好的更改，這些更改突然會導致其他用戶出現問題。

DB Context確實應該是短暫的，但在必要時可能比超短。 還要考慮如果您不加載和丟棄數據但只添加您將保存的更改，則可能無法通過保持資源來保存資源。 但它不僅關於資源，而且關於DB狀態可能在DB Context仍處於活動狀態並且已加載數據時可能發生變化; 對於更長的生活環境，請記住這一點很重要。

如果您還不知道要立即保存到數據庫中的所有相關更改，那么我建議您不要使用DB Context將更改存儲在內存中，而是存儲在代碼中的數據結構中。

當然，您可以在沒有活動數據庫上下文的情況下使用實體對象。 如果您沒有其他適當的數據類並且不想創建一個，或者決定准備其中的更改更有意義，這是有意義的。 然后，您可以使用DbSet.Attach將實體附加到數據庫上下文，以便在准備好時保存更改。