将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，就像其他资源属性（例外id）仅get一样，并且始终由服务器专门更改。 参考： https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-resources#system-vs-user-defined-resources

因此，如果我们将ETag放在我们的模型上，并且：

1. 从db读取文档到具有etag属性的强类型模型

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

3. 客户端更新并发回

4. 我们将更新/替换发送到cosmosdb（AccessCondition设置为etag从客户端获取并仍在其中一个模型属性中

我很难在那里找到问题？ 为什么要打扰dynamics/Document？

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

Answer 1

Etag是服务器构造，最初你的文档没有它。恕我直言，这是一个关于你想要如何纯粹的文件的问题。

如示例所示，您可以拥有ETag并拥有纯粹的对象（theOrder）

var theOrder =（Order）（dynamic）orderDoc;

Debug.WriteLine（ theOrder .Customer.FirstName +“。Etag”+ orderDoc .ETag）;

根据上面的示例，您必须保留返回的文档对象以获取ETag，或者您是否应该使用 theOrder 对象使用Etag属性，在您来到之前没有人关心和理解并发性。