我使用EntityFramework創建我的第一個應用程序。我正在使用實體框架核心和MVVMLight。DbContext的良好用法
我創建了一個DbContext後代類。我想知道什麼時候這個DbContext實例化。
我的第一個想法是爲每個視圖創建1個實例。
試想以下情形：
當用戶退出詳細視圖：
這是一種正確的做事方式嗎？我讀過的地方應該只有一個DbContext實例。但是在這種情況下，即使詳細視圖被取消，對詳細視圖的每個修改都會傳播到列表視圖。
聽
因此，您正在開發WPF應用程序，您可以使用每個窗體的上下文實例。
這是EF團隊：
用的Windows Presentation Foundation（WPF）或Windows窗體 工作時，每使用形式的上下文實例。這使您可以使用上下文提供的變更跟蹤功能 。
我想推薦使用存儲庫模式與依賴注入（DI）。然後你不需要擔心實例化和處置dbcontext。那些是自動的。
因此，您使用的是EF內核，您可以使用Autofac作爲DI API。
你的好文章：How to work with DbContext
另一個很好的文章，其中解釋瞭如何基於與實體框架，IoC容器和依賴注入通用Repository模式實現解耦，單位可測試，N層架構。是的，這篇文章是針對MVC的。但是你可以使用這篇文章瞭解這種模式。
Generic Repository and Unit of Work Pattern, Entity Framework,Autofac
有噸的文章和做題上，許多感謝名單，谷歌「的DbContext一生桌面應用程序」。此外，這本MSDN雜誌可能會有所幫助，雖然他們討論nHibernate的情況，但規則完全相同。
Data Access - Building a Desktop To-Do Application with NHibernate
桌面應用程序的推薦的做法是每個表單使用會話，因此，在申請每種形式都有它自己的會話。每個表單通常代表用戶想要執行的一項獨特的工作，因此將會話生命週期與表單生命週期相匹配在實踐中運行良好。額外的好處是你不再有內存泄漏問題，因爲當你在應用程序中關閉一個表單時，你也會處理會話。這將使會話加載的所有實體都有資格被垃圾回收器（GC）回收。
對於每個表單更喜歡單個會話還有其他原因。您可以利用NHibernate的更改跟蹤功能，以便在您提交事務時清除對數據庫的所有更改。它還在不同的表單之間創建了隔離屏障，因此您可以將更改提交到單個實體，而不用擔心其他表單上顯示的其他實體發生更改。
儘管這種管理會話生存期的風格被描述爲每個表單的會話，但實際上您通常會按照發言人來管理會話。
至於「的DbContext的1個實例」，這也被評論有：
一種常見的不良做法與[...]桌面應用程序是有一個單一的全球會議對整個應用。
和原因在下面討論。
爲了澄清，我不是一個深化發展的WPF應用程序，但一個UWP之一。但是這不會改變我猜想的任何事情。 –
是的，你是對的。沒有區別。同樣的模式也可以應用在那裏:) – Sampath