我一直在阅读 Udi Dahan 关于[命令查询分离和 SOA][1] 的文章。考虑到我将如何在我目前正在研究的系统中使用它，提出了一些问题......
1.
考虑以下情况，我有一个允许用户编辑条目列表的 WPF 客户端应用程序：
客户端应用程序已启动。在启动时，它订阅将处理和发布条目更改的命令服务，并查询 WCF 服务以获取完整的条目列表。接收到条目列表后，在客户端队列忙于等待 WCF 回复时可能已发布到客户端队列的任何更改（由其他客户端）都将合并到列表中。
现在对我来说，似乎有一个（可能非常小）的机会，即客户端在处理负责更改的命令之后订阅，并且 WCS 服务的查询在相同的更改提交到数据库之前启动。在这种情况下，我最终会在客户端中得到不（并且永远不会）与数据库同步的不正确数据（除非重新启动客户端应用程序）。这个问题真的存在吗，如果存在，应该如何处理？
2.我的第二个问题是关于如何设计/实现用户界面：
用户现在想要更改列表中的条目；弹出一个窗口，更改数据并按下确定按钮：我们向命令处理程序发送消息以处理此更改。用户希望看到确认（列表中的条目发生更改）或错误消息。
现在我可以尝试以“同步”的方式处理用户界面中的事情（让用户一次做一件事，让他在允许他做任何其他事情之前等待成功或失败），方式如下：
- 用户按下确定后，禁用所有控件，因此无法进行进一步编辑。
- 创建一个具有等待...的超时的 Saga？响应消息？命令服务发布的通知？两个都？
- 当收到响应消息时，列表中的数据会更改，控件会启用，我们就完成了——或者：
- 发生超时。命令消息已经排队，所以最终会执行更改，那该怎么办呢？从命令服务收到通知后，向用户显示一条消息（“这比预期花费的时间长......”），启用所有控件并更改客户端中的数据？但是如果返回错误怎么办？用户可能已经开始做其他事情（可能正在编辑另一个条目）并且从先前的编辑尝试中弹出错误消息似乎不是一个好主意。
另一种方法可能是只发送命令，让用户继续他接下来喜欢做的任何事情。也许在用户界面的某个地方的列表中显示所有未完成的命令，并带有成功或失败的指示符，以及用户在失败时显示错误消息的可能性。鉴于超时希望是异常的，并且通常应该在几秒钟内收到响应，这意味着该列表通常最多应该有 1 个未完成的命令。这一点以及我不记得我见过的事实用户界面以这种方式做事意味着它可能不是一个好主意。
你的问题是？;)
好吧，我只是想知道其他人如何在他们的用户界面中解决这个问题。与我想出的两种可能不太聪明的方法相比，在 UI 中可能有更好的处理方式吗？
对长文本表示歉意，并提前感谢您的回复。
[1]：http ://www.udidahan.com/2008/08/11/command-query-separation-and-soa/ 《命令查询分离与SOA》