为什么实体框架 ConcurrencyStamp 不使用 ROWVERSION/TIMESTAMP？答案

【问题标题】：Why is Entity Framework ConcurrencyStamp not using ROWVERSION/TIMESTAMP?为什么实体框架 ConcurrencyStamp 不使用 ROWVERSION/TIMESTAMP？
【发布时间】：2016-12-08 08:02:03
【问题描述】：

我是 EF 新手，之前设计过自定义 ORM，它们使用 TIMESTAMP 字段进行并发，并确定记录以与其他数据库同步。

为什么 EF (Core) 使用 nvarchar(max) 来存储看起来像 Guid 的内容？

即为什么 EF 会做数据库可以做的工作？

显而易见的事情是在某些时候（可能在扩展到多个服务器/数据库时）我们希望在其中存储多个 Guid，和/或可能仅仅是因为 ROWVERSION/TIMESTAMP 在目标数据库上的实现不一致英孚？

（在类似的注释中，为什么 ID 字段是 nvarchar(450)？）

更新：

migrationBuilder.CreateTable(
    name: "AspNetRoles",
    columns: table => new
    {
        Id = table.Column<string>(nullable: false),
        ConcurrencyStamp = table.Column<string>(nullable: true),
        Name = table.Column<string>(maxLength: 256, nullable: true),
        NormalizedName = table.Column<string>(maxLength: 256, nullable: true)
    },
    constraints: table =>
    {
        table.PrimaryKey("PK_AspNetRoles", x => x.Id);
    });

【问题讨论】：

EF 不应该为此使用 nvarchar(MAX)，而在 EF6 中，它没有。某处可能存在配置问题，但如果这在 EF Core 中确实发生了变化，我怀疑这是一个错误，而不是一个功能。你能展示你的类定义和映射，以及生成的表吗？旁白：“（在类似的注释上，为什么 ID 字段是 nvarchar(450)？）”——这是不相关的，可能最好省略，但请注意，如果你只是简单地做，你应该能够在 SQL Server 的警告中发现问题它在 EF 之外 nvarchar(MAX)。
这是另一篇带有数据类型屏幕截图的帖子：stackoverflow.com/questions/34252640/…

标签： entity-framework

【解决方案1】：

这似乎是 ASP.NET Core Identity 的一个有问题的设计决策，而不是 Entity Framework Core 中的问题。他们使用public virtual string ConcurrencyStamp { get; set; }，但对于RowVersion/Timestamp 列，实体框架使用byte[] 和附加注释或映射，以确保EF 理解更新后应重新读取的值。来自one of EF's own test files：

public class Two
{
    [Key]
    public int Id { get; set; }

    [StringLength(16)]
    public string Data { get; set; }

    [Timestamp]
    public byte[] Timestamp { get; set; }

    public virtual C NavC { get; set; }
}

如果您自己使用 EF，您应该可以毫无问题地使用 RowVersion/Timestamp 列。

【讨论】：

当我不了解一些标准/惯例时，我通常会因为试图匆忙实施新框架然后重新发明轮子（毫无疑问）而感到内疚。我试图在这里避免这种情况。一定有一些理由在这里使用字符串，我想知道在我的项目中看到的大部分内容将包括可扩展的并发和同步问题。但我同意你的看法，现在在我看来，这像是 Identity 中的一种设计选择，而不是 EF。