自跟踪实体与数据库中的时间戳列答案

【问题标题】：Self Tracking Entities versus timestamp column in database自跟踪实体与数据库中的时间戳列
【发布时间】：2010-07-05 13:44:23
【问题描述】：

在 web 应用程序的乐观并发场景中，我正在考虑为每个表提供时间戳列 (sqlserver)，与 guid 相当。然后，当使用 Entity Framework 中的某个属性装饰时间戳列时，Linq to entity 将生成 sql 更新查询，例如 WHERE id = @p0 AND timestamp = @p1。当返回的更新记录数为0时，我们检测到并发异常。

在很多帖子中，我都在阅读有关自我跟踪实体的文章，这可能是一种替代或更好的解决方案。但我没有看到比上述“简单”时间戳方法有任何优势。除了数据库不可变且不提供时间戳列的情况外。

哪种解决方案更好，为什么？

编辑

Yury Tarabanko 正确地指出 STE 是另一个概念。然而，zeeshanhirani 的回答表明并发检查是跟踪更改的主要动机之一。

让我们重新表述这个问题：为什么有人会使用 STE 概念进行并发检查，而“时间戳列”方法看起来要容易得多。

【问题讨论】：

标签： entity-framework timestamp self-tracking-entities

【解决方案1】：

您在这里混合了两个概念。 STE 根本与并发无关。

自我跟踪实体只知道如何进行更改跟踪，而不管这些更改是如何进行的。所以你总是知道实体对象图的当前状态是什么。而且您不需要调用额外的更改检测。

什么是STE。

编辑：

“并发检查是跟踪更改的主要动机之一”

AFAIK STE 和 POCO 共享相同的并发检查方法，这只会导致更新语句中的附加 where 条件发送到 DB。相当于这个：

UPDATE [schema].[table] 
     SET [prop1] = value1, ... 
     WHERE [key] = key_value 
          AND [concurrency_prop_1] = concurrency_prop1_old_value 
          AND [concurrency_prop_2] = concurrency_prop2_old_value

因此，跟踪变化的“主要动机”是跟踪 N 层应用程序中的变化。

【讨论】：

很公平。但是问题是：为什么有人要这样做来进行并发检查，因为“时间戳”方法看起来更加自然和容易。
我认为没有人会为了并发检查而选择 STE。 STE 与并发无关。正如@zeeshanhinari 指出的'STEs 与'并发检查概念一起使用。他们确实通过网络发送并发令牌的原始值。如果没有，您将无法在多层应用程序的另一层上检查这些值。 “这个想法是创建智能实体对象来跟踪它们自己的变化以及对相关实体的变化。”

【解决方案2】：

自我跟踪实体实际上适用于您描述的概念。 STE 基本上在上下文不存在时跟踪对象的更改。但是，当它使用 WCF 服务将其更改发送回服务器时，它会发送属性的当前值、实体的新状态以及主键列的原始值、独立关联值和任何列的原始值在实体数据模型中标记为 Concurrency=Fixed。

【讨论】：

顺便说一句，w.r.t. “主键列的原始值”：永远不要更改主键 - 更改设计（例如删除和添加）！