NServicebus / CQRS：如何处理用户界面中的事情？

Question

我一直在阅读 Udi Dahan 关于 [命令查询分离和 SOA][1] 的文本。考虑如何在我目前正在开发的系统中实践中使用它，提出了一些问题......

---

1.

考虑以下情况，我有一个 WPF 客户端应用程序，允许用户编辑条目列表：

客户端应用程序启动。启动时，它订阅将处理和发布条目更改的命令服务，并查询 WCF 服务以获取完整的条目列表。收到条目列表后，在客户端队列忙于等待 WCF 答复时可能已发布到客户端队列的任何更改（由其他客户端）都将合并到列表中。

现在对我来说，似乎有一个（可能非常小的）机会，即客户端在负责更改的命令被处理之后订阅，并且 WCS 服务的查询在相同的更改提交到数据库之前启动。在这种情况下，我最终会在客户端中得到不正确的数据，这些数据不会（也永远不会）与数据库同步（除非重新启动客户端应用程序）。 这个问题是否真的存在，如果存在，应该如何处理？

---

2.我的第二个问题是关于如何设计/实现用户界面：

用户现在想要更改列表中的条目；弹出一个窗口，数据被更改，然后按下“确定”按钮：我们向命令处理程序发送一条消息来处理此更改。用户期望看到确认（列表中的条目更改）或错误消息。

现在我可以尝试以“同步”方式处理用户界面中的事物（让用户一次做一件事，并让他等待成功或失败，然后才允许他做其他事情），如下所示：

1. 用户按下“确定”后，禁用所有控件，以便无法进行进一步编辑。
2. 创建一个带有超时等待...的 Saga？回复消息？命令服务发布的通知？两个都？
3. 当收到响应消息时，列表中的数据将发生更改，控件将启用，我们就完成了 - 或者：
4. 发生超时。命令消息已排队，因此更改最终会被执行，那么该怎么办呢？向用户显示一条消息（“这比预期花费的时间更长......”），在从命令服务收到通知后启用所有控件并更改客户端中的数据？但如果返回错误怎么办？用户可能已经开始做其他事情（可能正在编辑另一个条目），并且从之前的编辑尝试中弹出错误消息似乎不是一个好主意。

另一种方法可能是只发送命令并让用户继续下一步喜欢做的事情。也许会在用户界面某处的列表中显示所有未完成的命令，并带有成功或失败的指示符，以及用户在失败时显示错误消息的可能性。鉴于超时希望是例外情况，并且通常应在几秒钟内收到响应，这意味着该列表中通常应最多有 1 个未完成的命令。事实上，我不记得我曾经见过用户界面以这种方式做事，这意味着这可能不是一个好主意。

你的问题是？;)

好吧，我只是想知道其他人如何在他们的用户界面中解决这个问题。可能有比我想出的两种可能不太聪明的方法更好的方法来处理 UI 中的事情？

对于冗长的文字表示歉意，并提前感谢您的回复。

[1]: http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/《命令查询分离与SOA》

Answer 1

对于问题 1，查询的标准解决方案是创建客户端 RPC 请求/响应所针对的服务器端持久查询存储。

对于问题 2，答案很大程度上取决于领域 - 命令的种类、用户间协作的性质。作为首要规则，请考虑更改 UI 和/或命令的数据/处理的方法，以便命令几乎不会失败（除非我们谈论的是恶意用户）。

希望有帮助。