2

这个问题的灵感来自我在这里提出的一个较早的问题，我从那个问题中了解到 DbContext 实例应该是短暂的依赖关系。现在鉴于我使用 SQL CE 使用本地数据库开发 LOB 桌面应用程序，我有几个问题：

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

2 回答 2

2

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

如本文所述，dbContext 对象的生存取决于它在 Web 或桌面应用程序中使用的天气。

Web应用程序

  • 现在，对于 Web 应用程序，每个请求都使用上下文是一种常见且最佳的做法。

  • 在 Web 应用程序中，我们处理非常短但
    包含所有服务器事务的请求，因此它们是
    上下文存在的适当持续时间。

桌面应用程序

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

  • 由于我们不希望将上下文作为应用程序的单例，因此当我们从一种形式移动到另一种形式时，我们将处理它。

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

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

于 2016-10-13T09:34:46.497 回答
1

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

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

* 3) *不确定到底是什么问题。但是具有 Commit 方法然后处理上下文的 LUW 类型的 Class 是一种这样的模式。

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

于 2013-02-14T23:41:04.580 回答