如何在Web服务更新消息（DTOs）中使用可选属性？
如何在Web服务更新消息（DTOs）中使用可选属性？
背景：
假设你有一个管理图书馆中图书的（SOAP）web服务，名为BookService。在信息模型中，假设Book实体具有以下属性：
- id
- author
- publisher
- title
- shelfId
为了操作数据，定义了四个web服务操作：
- AddBook
- GetBook
- UpdateBook
- DeleteBook
为每个操作定义了请求和响应消息。但是，更新消息的XML模式设计更加复杂。我们希望实现以下质量：
- R1：能够重置/删除属性的先前值。例如，假设你不再在图书馆保留该书，并且希望重置/清空/删除该特定书籍的shelfId属性值。
- R2：避免web服务中的冗余通信。参见反模式Chatty Services。
- R3：为并发控制和乐观锁定做好未来需求的准备。我们可能希望最小化（或删除）基于旧信息进行的更新的风险。
设计备选方案：
我看到了三个主要的备选方案，其中一个有几个子选项，用于设计更新消息：
1. 发送整个业务文档。被省略的元素（在模式中具有minOccurs="0"）或明确设置为null的元素，即
2. 强调变化或只发送差异。
- 发送整个业务文档，但使用专门用于此目的的属性标记修改的元素。示例：
- 在消息模式中，将除标识符id之外的所有元素设置为minOccurs="0"。消费者只发送要修改的那些元素。被省略的元素不能被语义上解释为删除。要删除一个值，必须使用显式的XML NULL值。示例：
- 发送整个业务文档，但同时提交先前读取的文档的副本。然后，服务提供者可以比较这两个文档，并仅更新新旧文档不同的属性。
3. 定义多个操作。不仅使用一个操作UpdateBook，而是基于你认为需要更新的元素定义多个操作，例如UpdateBookAuthor，UpdateBookPublisher等。每个操作只包含必填元素，要删除元素，使用XML的显式NULL，例如
讨论：
备选方案3的优点是易于理解，但缺点是如果需要更新Book实体中的多个字段，则消费者需要调用多个操作。这使得服务变得冗余（参见R3），导致性能下降。
备选方案2比备选方案1更复杂，但备选方案2有一些与乐观并发控制相关的优势：
- 对于在数据库中存储每个字段的时间戳/版本（例如authorVersion）进行乐观锁定的情况=>备选方案2提供了一种让多个用户并发修改同一本书的不同部分（如author和publisher）的方法，减少故障风险。
- 对于在数据库中仅存储整个Book的一个时间戳/版本的乐观锁定的情况=>备选方案2与备选方案1相比没有真正的优势。即使更新只修改一个字段，如果请求的版本号过旧，将导致故障。
- 对于不使用并发控制或乐观/悲观锁定的情况=>备选方案2相比备选方案1的风险较小，但其他不一致的更改可能会导致问题。
备选方案2（和备选方案3）在另一种情况下比备选方案1具有优势。消费者可能不会存储有关Book实体的所有数据。例如，机器人从书架上取书可能会更有效地工作，如果它不需要在更新书架信息时跟踪（缓存）作者的信息，而只需要书架信息。
备选方案2.3的方法优势在于消费者提交先前版本的完整副本，而不是版本号或时间戳。这样就不需要为版本号或时间戳在数据库中专门设置列。
总之，我认为备选方案2.2对大多数情况来说是最有吸引力的。挑战在于解析XML的框架必须能够区分省略的元素和明确设置为NULL的元素，例如
问题：
你会选择哪个备选方案？你是否看到其他更好的备选方案？你对这个讨论有什么看法？
在Web服务更新消息（DTOs）中如何使用可选属性的问题是出于以下原因和解决方法：
原因：
1. 对于minoccurs=0和nil之间的区别经常被框架忽略，对于很多用户来说也很难理解。
2. 对于乐观锁定机制的实现以及其影响已经进行了广泛讨论。
解决方法：
1. 可以使用etag作为乐观锁定的标准。
2. 可以选择使用更简单的设计和使用/实现的消息方案（Alt 1）。
3. 如果流量不是一个问题，并且对于整个对象的乐观锁定已经足够（这在大多数情况下是成立的），那么也可以使用Alt 1。
4. 在某些业务流程中，不同属性的更改是相互依赖的，因此为属性单独进行版本控制是没有意义的，因为即使在更改时只有另一个属性过时，对于一个属性的更改也可能是错误的。如果出现这种情况，那么Alt 1也是一个解决方法。
以上是关于如何使用Web服务更新消息（DTOs）中的可选属性的问题的原因和解决方法。