4

使用 guid 作为标识字段而不是自动递增整数时，实现域驱动设计是否更容易？使用 guid，您不必跳转到数据库来获取实际值。

4

6 回答 6

6

DDD 的核心原则之一是持久性无知。所以是的，GUID 是为您的对象提供唯一标识而无需依赖持久性存储的最简单方法。

注意：如果您担心使用 GUID 的数据库性能，请考虑使用 COMB（专门针对 SQL Server 索引碎片）

于 2009-11-21T15:41:39.700 回答
6

好吧，GUID 很简单，看起来最合适。他们对前端程序员很有吸引力，因为他们不必处理数据库。

另一方面，当在没有过多考虑数据库问题的情况下查看它们的潜在缺点时，我会尽可能地警告它们。

真正的问题是：在将实体存储到数据库之前，您真的需要知道实体的 ID 吗？真的吗？为什么？

如果您最终决定使用 GUID，并且如果您使用 SQL Server 作为数据库后端（我对其他 RDBMS 的了解不足，无法提出明智的建议），我强烈建议您绝对确保GUID未用作表上的集群键。这会扼杀你的表现——毫无疑问。

如果您确实使用 GUID 作为主键，请确保使用其他东西，即对数据库造成较少破坏的其他列，作为您的集群键 - INT IDENTITY 将是我的首选。

查看 Kimberly Tripp 撰写的这些文章，了解为什么 GUID 作为 SQL Server 数据库中的集群键绝对不是一个好主意——她是索引和索引性能问题的终极大师，她可以使这些观点比我曾经可以：

马克

于 2009-11-21T16:52:36.393 回答
2

我推荐Guids，因为您不会混淆您正在查看的内容。另外，我知道这经常被当作一个玩笑，但我不得不调试系统中发生的一个问题，它正在寻找 uint 而不是 guid。这导致 sharepoint 中的模板被停用，并且我们无法重新激活它。花了 2 天时间才发现根本问题是什么。所以回顾一下Guid's。

于 2009-11-21T15:33:53.057 回答
2

我认为 GUID 相对于递增整数的唯一优势是身份创建的去中心化。也就是说，递增整数需要原子增量并读取共享值，而 GUID 可以独立创建而无需担心冲突。

至于您关于 GUID 允许人们在不咨询数据库的情况下取消引用实体的建议，我不明白这是怎么回事，因为您的问题中没有提到其他一些信息。您在这里的选择是密钥类型之一，而不是是否使用密钥。如果您手头有一个键，并且该键通过数据库映射到一个值或实体，则您需要查阅数据库以取消引用该键。

于 2009-11-21T15:35:23.850 回答
2

我使用 guid 的原因有两个：

  • ID 不仅在创建它的上下文中是唯一的，因此可以在不同位置生成相同类型数据的 ID。这适用于您在地理上分布的多个安装相互交换数据的情况，或者在断开连接的情况下。
  • 它抵消了以逻辑方式处理 ID 的冲动，而是强制开发人员将值视为“公正和 ID”。

但是，我不一定会说这些论点仅对领域驱动设计有效。

于 2009-11-21T15:39:41.747 回答
1

不，绝对不是。GUID 是一个实现细节，不应泄漏到您的域中。你需要一个标识值对象，我不在乎你如何实现它。

于 2015-08-26T22:43:42.260 回答