【发布时间】：2009-12-22 22:12:49
【问题描述】：
我一直在阅读 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"
【问题讨论】：
标签： user-interface nservicebus cqrs