在WPF MVVM中使用不断刷新的存储库持久保存EF更改

本文关键字：存储 保存 更改 EF 刷新 MVVM WPF | 更新日期: 2023-09-27 18:19:28

使用MVVM并由实体框架提供支持的WPF应用程序。出于可用性的目的，我们非常希望允许用户多窗口使用该应用程序。然而，这有可能导致EF出现问题。如果我们坚持通常的建议，即每个ViewModel创建一个Repository副本，而有人打开同一ViewModel的多个窗口，这可能会导致"IEntityChangeTracker的多个实例"错误。

我们没有使用Singleton，因为它有自己的问题，而是通过在存储库中放置一个Refresh方法来获得新的数据上下文来解决这个问题。然后我们在整个商店里都这样做：

using (IRepository r = Rep.Refresh())
{
    r.Update(CurrentCampaign);
    r.SaveChanges();
}

这基本上是好的。然而，它会导致维护状态的问题。如果在用户处理对象时刷新上下文，则其更改将丢失。

我可以看到两种方法，它们都有自己的缺点。

  • 我们经常调用SaveChanges。这可能会通过不断的数据库调用来降低应用程序的速度。此外，有时我们不想存储不完整的对象
  • 加载时，我们将EF对象复制到内存中，让用户处理这些对象，然后添加一个"保存"按钮，将所有对象复制回EF对象并保存。我们可以用自动映射器来完成这项工作，但这似乎仍然是不必要的麻烦

还有别的办法吗？

在WPF MVVM中使用不断刷新的存储库持久保存EF更改

我认为，将用于访问实体框架的存储库作为单例可能并不总是错误的。

如果你有一个场景，如果你有客户端存储库，即一个存储库，它是客户端应用程序的可执行文件的一部分，即由一个客户端使用，那么单例可能是可以的。当然，我会而不是在服务器端使用单例。

我在pluralsight网站上的"MVVM"课程上问了Brian Noyes（微软MVP）一个类似的问题。

我问："处理视图模型中使用的客户端服务的正确方法是什么？"

在回应中，他写道："……我的大多数客户服务都是单身汉，并为应用程序的生命而活。"

此外，只要有一个singleton的接口，拥有singleton并不能阻止您编写单元测试。

如果您使用依赖注入框架（请参阅Marks注释），这本身就是一个好主意，那么更改为单例实例化只需对相应类的注入容器的设置进行一个小的更改。

相关文章：