具有桌面应用程序和本地数据库的短生命DbContext

Question

这个问题的灵感来自我之前提出的一个问题here，我从这个问题中得知DbContext实例应该是短生存依赖关系。现在假设我使用SQL CE使用本地数据库开发LOB桌面应用程序，我有几个问题：

1. 在我的情况下（本地数据库，单用户，桌面应用），DbContext真的应该在短时间内存在吗？
2. 如果我在每次操作时都处理了我的DbContext，那会不会让我丢失在整个生命周期中收集到的所有跟踪信息？
3. 如果对2的答案是真的（麻烦！），如何以正确的方式去做，我应该开发一个能保持更改跟踪信息的UnitOfWork还是什么？！

Answer 1

1）是的，短暂是好的。但每个用户输入/交互都是极端的

2）显然是的。但是，除了客户交互的逻辑工作单元之外，丢弃上下文的模式也很合适。例如，更改订单。也许Header，Items和cust加载。添加到cust的新地址，更改了Order标头和SaveChanges。新的逻辑交互从客户端开始。别忘了你可以有几个较小的背景。确实有界的背景是表现的关键。也许你有一个长时间运行的上下文，系统配置和其他这样的设置是非易失性的，数量很少，但经常访问。我会保持这样的背景更长时间。

* 3） *不确定问题究竟是什么。但是LUW类型的Class有一个方法Commit然后处理上下文就是这样的模式。

如果经常重新加载，请不要忘记在DbContexts上生成视图。

Answer 2

老问题，但它可能对某人有帮助。

如this文章所述，dbContext对象的生存依赖于它在web或桌面应用程序中使用的天气。

网络应用程序

• 现在，对于Web应用程序来说，这是一种常见的最佳实践， 每个请求都使用上下文。

• 在网络应用程序中，我们处理的是非常短的请求 保持所有服务器交易，因此他们是正确的 生活环境的持续时间。

桌面应用程序

• 对于桌面应用程序，如Win Forms / WPF等，使用上下文 每个表单/对话框/页面。

• 因为我们不希望将上下文作为我们的单例 当我们从一种形式转移到另一种形式时，我们将处理它。

• 通过这种方式，我们将获得很多上下文的能力而不会 受到长期背景的影响。

基本上，上下文应该是短暂的生活对象，但始终保持适当的平衡。