将GUI与SOAP/WS-API更新/写入调用解耦的好方法？

让我们假设我们有一些配置GUI，其当前形式使用直接DB事务以一致的方式提交多个可配置组件的新配置

现在，让我们将数据数据库的内容转移到一些SOAP/WSAPI后面。GUI不再具有直接的数据库访问权限。必须保留事务行为，但API的设计不应明确地适应GUI表单提交。事实上，我甚至不知道新的GUI将如何工作，也不知道用户输入将如何构造。因此，我需要在API服务器端提供类似的内容。但是，至少有两个注意事项：

GUI是用PHP编写的：我认为PHP中没有任何WS-Transaction支持。 我不想在等待其他客户机请求时在服务器端保持DB事务打开。 我能想到的解决办法是：

使用。然而，这至少会在两个方面使事情变得更加复杂： 不能在同一事务内的后续调用中使用新插入行的DB row ID。您需要使用某种符号反向引用，因为在处理聚合消息时，客户机和服务器之间没有通信。 呼叫回复不会是即时的，或者对每个呼叫的即时和单独回复只能是某种存根，即，除了您的消息之外，不包含任何有用的信息已附加到TX xyz-如果在骆驼聚合情况下可能的话。 前面解决方案的两个缺点让我想到了请求批处理，其中WS-standards可能提供了在批处理事务中的后续调用中引用调用结果的方法。已经有这样的东西了吗？甚至作为一个PHP客户端？ 试图通过小心地使用行级锁等来消除数据库中的锁争用。但是，在插入新元素时，我猜想通常需要DB锁定页面和索引页面。 也许是使用乐观锁定的服务器端持久层？但是，如果DB写入延迟到提交时才知道是否可能，那么在最终提交之前，不会将任何DB ID返回给客户机。

---

你认为呢？

交易是一个强大的工具，我们很容易进入一种思维模式，在这种模式中，我们把每个问题都看成是我们用这把大锤敲打的钉子。我能理解你的困惑，因为我自己也经历过。不幸的是，我没有更好的建议给你，那就是尽量不要考虑事务，而是考虑原子API调用

当我从交易的角度思考时，我的思维模式通常是这样的：

启动事务 根据需要重复阅读 根据需要重复更新 提交/回滚 需要一些时间才能意识到我们过度使用了这种模式。实际冲突很少，处理冲突的方法还有很多。下面是API中常用的一个

读取数据并发送到客户端原子API调用 更新客户端上的数据 将原始+更新发送回服务器原子API调用 在服务器上启动事务 阅读 与客户提供的原件进行比较 如果不相同，则返回错误客户端应重试 如果相同，请更新 犯罪 最后六点是API调用实现的一部分

费伦茨·米哈利

---

你说得有道理。但是您缺少一个要求，即API的设计不应明确地适应GUI表单提交，这意味着多个任意更新必须是可组合的。。。