Breeze 并发的最佳实践

我正在使用breeze在我的SPA和Web服务器之间进行交互，可能需要一些关于并发“问题”的帮助

只要更新是一个简单的对象，并发就可以正常工作。然而，当处理层次实体时，问题就开始了

产品有一些简单的属性，比如代码、名称、描述，还有一些导航属性。为了简洁起见，我将只讨论其中的一个：产品包（一个具有id、代码、名称和productId的实体，它是产品的外键）。在保存产品时，只有发生更改的实体才会发送到服务器，因此，如果我们将产品包添加到产品中，这就是此产品包实体

当此产品由两个人同时编辑时，可能会导致问题，例如，由于产品包上发生了一些业务验证

产品本身有一个“版本”属性，因此一个选项可能是在产品包列表（或其他导航属性之一）发生更新时手动将产品实体状态设置为“修改”，但这需要为每个操作发送产品实体（并不是说它需要那么多的带宽，但它感觉像一个黑客）

对于这样的事情，最好的做法是什么

发送根实体及其所有子实体（即使没有更改）

将根实体（有更改或没有更改）与有更改的实体一起发送

只需发送更新的实体并使用另一种机制进行并发性检查

完全避免并发检查，并使用最新/最后的更改

还有别的吗

---

我的感觉是，你的问题不仅仅是关于锁定，而且（或者更确切地说）是关于关于合作编辑这不是一个可以用单一答案解决的问题。合作编辑非常复杂，人们可以就此撰写书籍。这取决于合作编辑会话的要求、数据的结构以及不同节点之间的松散/严格约束/规则/关系数据可能有很多解决方案，其中没有一个是完美的，但有自己的优点和缺点

我最近一直在工作（有时还在工作）在合作编辑工具上，所以我对问题的复杂性有一个线索，但不要期望你的模糊问题有一个明确的答案，因为你不会得到答案。不可能给你一个好的答案，因为正如我前面提到的，即使是一个明确指定的合作编辑问题，通常也不可能提供一个好的答案，因为解决方案有一些折衷，您必须决定哪种解决方案对您有可取的优点和可接受的缺点。例如，您的客户可能更喜欢使用“fluid”的良好用户界面响应时间会话就像他单独使用一个桌面应用程序一样，有时会因为隐藏网络延迟而稍后发现的冲突而回滚其工作，但另一个客户端可能更喜欢另一种方式：每次更改后始终提交/验证数据，即使这需要时间，而且支付的费用更糟糕这方面的经验/速度较慢

分层数据？如何用锁保护数据以防止并发访问始终是一个大问题。这里的大问题是，您必须定义数据的“一致性”意味着什么。假设有人想要编写一个小单元，即“节点”在您的数据中，您必须在实际提交数据之前验证数据。您不仅必须锁定即将更改的节点，而且还必须锁定所需的所有其他节点，以便根据您的规则检查新写入的数据是否与其他节点的内容一致。因此，您的编辑会话非常简单如果节点之间的关系较少，一致性规则限制较少，则使用较少的锁会更有效。请尝试使规则尽可能松散

以下是一些如何让你的生活更轻松的随机提示：

• 一致性规则越少，松散耦合的数据就越容易协同编辑。尝试仅在彼此相邻的节点之间创建关系，但最好的方法是将一致性规则限制为仅在单个节点内工作。定义“节点”的人也是你，将数据组织到正确的数据结构中
• 给所有节点一个唯一的id，或者在互联网编辑数据的情况下，给所有节点一个全局唯一的id。这有很多好处
• 有时一棵树不是一棵真正的树。：-，至少在记忆中是这样。如果所有树节点都有一个唯一的id，那么您可以将树视为一个节点列表，这些节点使用唯一的id相互引用。通常，在编辑/差异化/合并/冲突处理方面，处理节点列表要比处理分层数据结构容易得多。更不用说，如果您的用户删除了一个节点，并且有其他节点引用了已删除的节点，那么您仍然可以在其他节点中保留无效引用，并且如果用户“取消删除”/undo执行他的删除操作，那么您尚未删除的引用将再次生效，并且可以很容易地使用ID处理undo/redo功能
• 协作编辑与撤消/重做缓冲区有很大关系。撤消/重做缓冲区基本上包含一系列以下3个操作：
• 使用具有默认属性值的新ID创建新节点
• 修改现有节点的属性。（请注意，对其他节点的引用实际上可以被视为具有唯一id类型的属性，因此可以将节点间连接的创建/删除视为属性更改）
• 正在删除节点
• 请注意，客户端和服务器之间的网络通信（或对等网络中的对等网络之间的通信）通常由保存到撤消/重做缓冲区中的相同操作组成

锁定：

• 正如我说的，你可以用更少的lo工作