azure - 将 ETag 添加到强类型模型真的是一个坏主意吗？

Question

我正在使用 .NET SDK 与 DocumentDb API 实现乐观并发。

在几个地方我发现提到有 ETag在强类型模型上是一个坏主意。这里明确表示: https://www.google.hr/amp/s/peter.intheazuresky.com/2016/04/28/documentdb-revisited-part-3-concurrency-in-documentdb/amp/

甚至 github 上的官方示例也显示它使用 dynamic/Document类而不是强类型的类。

现在，我不明白的是为什么不存储 ETag在模型上？根据文档，ETag ，就像其他资源属性(异常(exception)是 id )是 get仅且始终由服务器专门更改。引用: https://learn.microsoft.com/en-us/azure/cosmos-db/documentdb-resources#system-vs-user-defined-resources

所以，如果我们输入 ETag在我们的模型上:

1. 使用 etag 将文档从数据库读取到强类型模型属性(property)

2. 将其发送到客户端(为了简单起见，让我们忽略表示层 dto s)

3. 客户端更新并发回

4. 我们将更新/替换发送到 cosmosdb(将 AccessCondition 设置为从客户端获取的 etag，并且仍在模型属性之一中)

我很难找到那里的问题？为什么要费心dynamics/Document根本吗？

或者我错过了一些明显的东西？

Answer 1

Etag 是服务器结构，最初您的文档在生成时没有它。恕我直言，这取决于您希望文档的纯粹程度如何。

正如示例所示，您可以拥有 ETag 并拥有纯对象 (theOrder)

var theOrder = (订单)(动态)orderDoc;

Debug.WriteLine(theOrder.Customer.FirstName + “.Etag “+ orderDoc.ETag);

根据上面的示例，您必须保留返回的文档对象才能获取 ETag，或者您是否应该有一个带有 Etag 属性的 theOrder 对象，而在您了解之前没有人关心和理解该属性并发性。