作为上一篇文章 (Architecture: simple CQS) 的结果，我一直在思考如何构建一个足够灵活以便以后扩展的简单系统。
换句话说:我认为现在不需要成熟的 CQRS，但我希望它在以后可以很容易地发展到它，如果需要的话。
所以我想将命令与查询分开，但两者都基于同一个数据库。
查询部分会很简单:一个基于 View 的 WCF 数据服务，它很容易查询数据。那里没什么特别的。
命令部分比较难，这里有一个想法:命令当然是以异步方式执行的，所以它们不返回结果。但是，我的 ASP.NET MVC 站点的 Controller 通常需要来自命令的反馈(例如，成员注册是否成功)。因此，如果 Controller 发送命令，它还会生成与命令属性一起传递的事务 ID(GUID)。命令服务接收到这个命令，将其放入数据库中状态为“processing”的事务表中，然后执行(使用 DDD 原则)。执行后，交易表被更新，状态变为“完成”或“失败”，以及其他更详细的信息，如生成的主键。
同时站点正在使用 QueryService 轮询此事务的状态，直到收到“完成”或“失败”，然后它可以根据此结果继续工作。如果轮询事务表且结果为“已完成”或“失败”，则删除该条目。
一个副作用是我不需要 guid 作为我的实体的键，这对性能和大小来说是一件好事。
在大多数情况下，可能不需要这种轮询机制，但如果需要则可以使用。界面在设计时考虑了 CQS，面向 future 开放。
您认为这种方法有什么缺陷吗？其他想法或建议？
谢谢!
路德
最佳答案
我认为您的方法非常接近完整的 CQRS 系统。
我有一个网站，我曾经做过与您描述的类似的事情。我的网站，braincredits.com ，是使用 CQRS 构建的，所有命令本质上都是异步的。因此，结果是，当我创建一个条目时，除了命令已成功提交处理(不是它已处理)之外，实际上没有给用户任何反馈。
但是我在网站上有一个用户分数(他们的“信用”计数)应该随着用户提交更多项目而改变。但我不希望用户一直按 F5 来刷新浏览器。所以我按照你的建议做——我有一个 AJAX 调用，每隔一两秒就会触发一次，以查看用户的信用计数是否发生了变化。如果是，则返回新的金额并更新 UI(用一点点动画来吸引用户的注意力——但不要太花哨)。
您所说的是最终一致性——用户看到的应用程序状态最终将与系统数据(记录系统)保持一致。这个概念对于 CQRS 来说非常关键，而且在我看来，它很有意义。一旦您在系统中检索数据(无论是否基于 CQRS 的系统)，数据都是旧的。但是，如果您假设并假设客户最终会保持一致，那么您的方法就有意义，您也可以设计您的 UI 来说明这一点并加以利用。
就建议而言，我会观察您进行了多少轮询以及您来回发送了多少数据。不要过度使用投票，这听起来好像你不是。但是，将您网站上应定期更新的内容作为目标，我认为您会做得很好。
用于查询端的 WCF 数据服务层是个好主意 - 只需确保它仅支持读取(我相信您已经做到了)。
除此之外，听起来您的开端不错。
希望对您有所帮助。祝你好运!
关于c# - 建筑问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7031510/