在 Entity Framework Core 中实例化 GUID 是不好的做法吗？答案

【问题标题】：Is instantiating a GUID in Entity Framework Core bad practice?在 Entity Framework Core 中实例化 GUID 是不好的做法吗？
【发布时间】：2019-04-22 23:54:15
【问题描述】：

如果我有一个带有Guid 类型键的模型，那么在构造函数中显式设置 ID 是不好的做法吗？

我知道它会被 Entity Framework 隐式设置，但是显式设置会发生什么不好的事情（也许是性能方面）？

例子：

class MyModel
{
    public MyModel()
    {
        Id = Guid.NewGuid();
    }

    [Key]
    public Guid Id { get; set; }
}

我认为Guid 由 SQL 服务器中的顺序 ID 支持，如果我明确设置一个值，我想我会降低索引性能，因为它不再是顺序的？

我还没有找到答案，对此我非常好奇。

【问题讨论】：

自己测试一下。创建 100000 个实体并让 EF 分配 GUID。分析一些针对它的查询。擦除表格，然后使用您自己新建的 GUID 创建 100000 个实体并对其进行概要分析。我会假设（这只是一个假设），不会有任何区别。
guid 不是连续的。它们往往是由同一个系统生成的，但依赖这似乎很愚蠢。
.Net Guid 的 SQL 数据类型是 uniqueidentifier

标签： c# entity-framework-core guid

【解决方案1】：

我看到的是设计缺陷而不是性能问题：模型不应该生成它们的id。这是他们的责任。存储库在 Add 方法中这样做。

Guid 可以通过多种方式生成：例如，它可以是随机的或顺序的。有不同的算法可以生成它们。因此，您的选择仅限于一个。

并且您正在强制分配模型id 的时刻：您可能不希望这样做以延迟其分配，直到模型可能需要持久化。 例如，零 Guid 可能有助于了解某些模型尚未持久化。

【讨论】：