NServicebus / CQRS：如何处理用户界面中的内容？

Question

我一直在阅读Udi Dahan关于[Command Query separation and SOA] [1]的文章。考虑如何在我正在研究的系统中使用它来提出一些问题......

---

1

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

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

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

---

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

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

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

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

另一种方法可能是发送命令并让用户继续他接下来要做的任何事情。也许在某个用户界面的列表中显示所有未完成的命令，并指示成功或失败的指示以及用户在发生故障时显示错误消息的可能性。鉴于超时有望是特殊的，并且通常应在几秒钟内收到响应，这意味着此列表通常最多只能包含1个未完成的命令。那个以及我记不起的事实我见过用户界面以这种方式做事意味着它可能不是一个好主意。

你的问题是？ ;）

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

为长篇文章道歉，并提前感谢您的回复。

[1]：http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/“命令查询分离和SOA”

Answer 1

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

对于问题2，答案很大程度上取决于域 - 命令的种类，用户间协作的性质。作为一个总体规则，想一想你可以改变UI和/或命令的数据/处理的方法，这样命令几乎不会失败（除非我们谈论的是恶意用户）。

希望有所帮助。