DbContext的良好用法

Question

我正在使用EntityFramework创建我的第一个应用程序。我正在使用Entity Framework Core和MVVMLight。

我创建了一个DbContext后代类。我想知道何时实现这个DbContext。

我的第一个想法是为每个视图创建一个实例。

想象一下以下场景：

• 我有一个Item类
• 我创建了一个ItemsViewModel来管理项目列表。在这个viewModel中，我为DbContext
添加了一个属性
• 当用户双击某个项目时，它会在详细视图中显示，并与ItemViewModel相关联。此视图模型还有一个我的DbContext实例。

当用户退出详细信息视图时：

• 如果他保存，我会更新列表的DbContext
• 如果他取消了，则列表不需要更新

这是一种正确的做事方式吗？我已经读过某个地方应该只有一个DbContext实例。但在这种情况下，即使细节视图被取消，对细节视图的每个修改都会传播到列表视图。

很多听力

Answer 1

因此，您正在开发WPF应用程序，您可以为每个表单使用上下文实例。

来自EF团队：

  

使用Windows Presentation Foundation（WPF）或Windows时   表单，使用每个表单的上下文实例。这可以让你使用   上下文提供的更改跟踪功能。

我建议使用带有依赖注入（DI）的存储库模式。然后，您不必担心实例化和处理dbcontext。这些是自动的。

因此，您使用的是EF核心，您可以使用Autofac作为DI API。

适合您的文章： How to work with DbContext

另一篇好文章，它解释了如何基于具有实体框架，IoC容器和依赖注入的通用存储库模式实现解耦的，可单元测试的N层架构。是的，本文适用于MVC。但是你可以使用这篇文章了解这种模式。

Generic Repository and Unit of Work Pattern, Entity Framework,Autofac

Answer 2

有很多文章和SO问题，谷歌为“DbContext终身桌面应用程序”。此外，这篇MSDN杂志可能会有所帮助，虽然他们讨论了nHibernate的情况，但规则完全相同。

Data Access - Building a Desktop To-Do Application with NHibernate

  

桌面应用程序的推荐做法是使用每个表单的会话，以便应用程序中的每个表单都有自己的会话。每个表单通常代表用户想要执行的独特工作，因此将会话生命周期与表单生命周期相匹配在实践中非常有效。额外的好处是您不再遇到内存泄漏问题，因为当您关闭应用程序中的表单时，您也会处置该会话。这将使会话加载的所有实体都有资格通过垃圾收集器（GC）进行回收。

     

每个表单更喜欢单个会话还有其他原因。您可以利用NHibernate的更改跟踪，因此在提交事务时它将刷新对数据库的所有更改。它还在不同的表单之间创建隔离屏障，因此您可以将更改提交到单个实体，而无需担心对其他表单上显示的其他实体的更改。

     

虽然这种管理会话生命周期的方式被描述为每个表单的会话，但实际上您通常会按演示者管理会话。

至于“DbContext的1个实例”，这里也有评论：

  

桌面应用程序的常见不良做法是为整个应用程序提供单个全局会话。

以下讨论原因。