具有實體框架3.5和MVVM的存儲庫模式 - 我應該在任何地方共享相同的上下文嗎?

c# entity-framework mvvm repository-pattern wpf

我正在開發一個數據庫文件系統 。我在用 -

  1. .Net框架3.5
  2. 實體框架3.5
  3. WPF與MVVM模式

該項目跨越多個使用相同模型的程序集。

一個程序集,我們稱之為“服務器”,只使用EF(即相同的模型)將數據添加到數據庫。其他程序集(包括UI)都讀取和寫入數據。服務器所做的更改應立即反映在其他程序集中。

數據庫包含自引用表,其中每個實體可以具有單個OR或不具有父級和(可能是)某些子級。我想使用存儲庫模式,它也可以提供一些機制來處理這種分層性質。

我已經在Code Project上閱讀了這篇文章。它在任何地方共享相同的上下文(實體)。

我的問題是 - 我應該在各地分享相同的背景嗎?這樣做的優點和缺點是什麼?

一般承認的答案

WPF應用程序框架(WAF)的BookLibrary示例顯示瞭如何一起使用WPF MVVM和實體框架。它將層分成單獨的組件。

也許這就是你要找的東西。


熱門答案

根據我的理解,應該在需要時使用objectcontext然後扔掉。因此,您可能希望將其包含在一個工作界面單元中,以及一個工作單元工作區,以便在需要時創建工作單元。

至於你關於反映“集會”變化的實體的問題。事情是你的對像不存在於程序集中。它們存在於記憶中。

因此,為了在應用程序中反映更改,您必須在整個應用程序中維護對同一對象的引用。或者您可以實現通知系統,以便在更改實體或實體集合時,應用程序的另一端會注意並刷新數據。

保持單個上下文存活的缺點是,每次對對像上下文進行查詢時,它都會隨著從db加載的實體而增長。在長時間運行的應用程序中,這會轉化為大量內存消耗。

每次使用全新上下文的缺點是對repo的任何調用都會為您提供新的數據副本。現在這應該不是問題,因為回購的唯一關注應該是保存/加載數據;不處理跨層的並發或數據重複



Related

許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因