我有一个简单的时间表申请表。它管理:
用例如下:
当我第一次启动应用程序时,我在连接(在UI线程中)创建了一个ObjectContext,并在用户关闭应用程序时进行处理。
它工作得很好,但我遇到了实现打印功能的问题,因为我无法在后台工作线程中使用ObjectContext。
谷歌搜索了一下我找到了工作单元的概念。另外,我的理解是实体属于一个ObjectContext。
让我们说ObjectContext#1 - 在UI线程中用于检索当天的WorkEntries - 包含用户的两个新WorkEntries。 - 尚未处理,因为用户尚未保存其更改
让我们说ObjectContext#2 - 用于后台工作线程 - 当天的Retreive WorkEntries - 打印WorkEntries
ObjectContext#2如何识别ObjectContext#1中的两个新WorkEntries?
修改
我知道有一个缺陷......用户必须保存才能在打印报告中获得两个新条目。
但是,假设我的应用程序在网格中显示数据,例如excel。用户期望(有充分理由)相同的行为具有优势。也就是说,在excel中,我不会被迫保存以打印我的新行......我只想打印我在工作表上看到的内容,无论数据的持久性状态如何。
答案 0 :(得分:2)
如果我正确读到这一点,那么你正在考虑这个错误。流程应该是这样的(伪代码)
用户请求数据:
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
请注意,在所有这些中,只有在执行适当的数据库操作时才需要打开上下文。如果在用户保存更改之前进行打印,则不会打印更改,因为用户尚未保留更改。
现在,有时候有一种有效的方法可以在应用程序的整个生命周期内保持上下文的开放。但是,同样的规则仍然适用。如果用户保存数据,那么其他上下文无论如何都会立即意识到它,因为它会在被要求打印时从数据库中提取新数据。同样,如果用户没有保存他们的更改,那么它不在数据库中,因此不会打印。如果我们打印它并且用户决定放弃更改怎么办?如果您想避免这种情况,那么您应该提示用户打印不会拾取未保存的数据,并允许他们选择是否仍要打印或保存数据。如果您想允许他们打印已保存和未保存的数据,那么这与EF上下文不同
答案 1 :(得分:0)
当您即将开始打印时(而非应用程序启动时)创建#2。它将查询后备数据存储区并获取该时间点的最新数据。
答案 2 :(得分:0)
您可以在需要时创建上下文,然后将其丢弃。
常见的方法如下
using(YourContext context = new YourContext)
{
// Do stuff here
// and then when you pass the using block context is disposed so you can reuse it
}