实体框架-一个应用程序/一个用户/一个简单用例..看似简单，实则不然

本文关键字：一个 简单 用户 框架 应用程序 实体 | 更新日期: 2023-09-27 18:29:36

我有一个简单的时间表应用程序。它管理：

  • 员工组
  • 员工
  • 每个员工的工作条目列表

用例如下：

  1. 我的用户启动应用程序并连接到数据库
  2. 他看了看当天的工作条目
  3. 他添加了2个新的WorkEntry，但现在正在NOT保存数据
  4. 他打印WorkEntries，一个对话框向他显示可能需要一些时间才能完成的操作进度

当我第一次启动应用程序时，我在连接处（在UI线程中）创建了一个ObjectContext，并在用户关闭应用程序时进行了处理。

它运行得很好，但我在实现打印功能时遇到了问题，因为我无法在后台工作线程中使用ObjectContext。

我在谷歌上搜索了一下，发现了工作单位的概念。

  • 创建ObjectContext
  • 你想做什么
  • 关闭它

此外，我的理解是实体属于一个ObjectContext。

比方说ObjectContext#1-在UI线程中用于检索当天的WorkEntries-包含用户的两个新WorkEntry。-尚未处置，因为用户尚未保存其更改

比方说ObjectContext#2-用于后台工作线程-检索当天的工作条目-打印工作条目

ObjectContext#2如何知道ObjectContext#1中的两个新WorkEntry？

编辑

我知道有一个缺陷。。。用户必须保存才能在打印的报告中获得两个新条目。

但假设我的应用程序是在网格中显示数据，比如excel。用户会期望（有充分的理由）同样的行为也有好处。也就是说，在excel中，我不会被迫保存以打印我的新行。。。我只想打印我在工作表上看到的内容，而不管呈现的数据的持久性状态如何。

实体框架-一个应用程序/一个用户/一个简单用例..看似简单，实则不然

如果我读对了，那么你想错了。流程应该是这样的（伪代码）

用户请求数据：

Open a context
Retrieve data
Close the context

用户保存数据：

Open a context
Save the data
Close the context

打印工作条目：

Open a context
Retrieve the data
Close the context
Print the data

请注意，在所有这些操作中，只有在需要执行适当的数据库操作时，上下文才会打开。如果打印发生在用户保存更改之前，则不会打印这些更改，因为这些更改尚未由用户持久化。

NOW，有时有一种有效的方法可以在应用程序的整个生命周期中保持上下文打开。然而，同样的规则仍然应该适用。如果用户保存了数据，那么其他上下文无论如何都会立即意识到这一点，因为当被要求打印时，它会从数据库中提取新数据。同样，如果用户不保存他们的更改，那么它不在数据库中，因此不会打印。如果我们打印它，而用户决定放弃更改，该怎么办？如果您想避免这种情况，那么您可能应该提示用户打印不会拾取未保存的数据，并允许他们选择是否仍要打印或保存数据。如果您想允许他们打印已保存和未保存的数据，那么这与EF上下文是不同的问题

在即将开始打印时创建#2（而不是在应用程序启动时）。它将查询备份数据存储，并具有该时间点的最新数据。

您只需在需要时创建上下文，然后进行处理即可。

一种常见的方法类似于以下

using(YourContext context = new YourContext)
{
 // Do stuff here
 // and then when you pass the using block context is disposed so you can reuse it
}
相关文章：