4
CQRS:命令返回值[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 改善这个问题 关于命令是否应该具有返回值,似乎存在无尽的困惑。我想知道是否只是因为参与者没有说明他们的背景或情况而引起的困惑。 混乱 这是混乱的例子... 乌迪·达汉(Udi Dahan)说,命令“没有将错误返回给客户端”,但在同一篇文章中,他展示了一个图,其中命令的确向客户端返回了错误。 Microsoft Press Store上的一篇文章指出“命令...不返回响应”,但随后给出了模糊的警告: 随着围绕CQRS的战场经验的增长,一些实践逐渐巩固并趋于成为最佳实践。在某种程度上与我们刚才所说的相反...今天普遍认为,命令处理程序和应用程序都需要知道事务操作的进行方式。结果必须是已知的... 吉米·博加德(Jimmy Bogard)说“命令总是有结果”,但随后又花了很多功夫来说明命令如何返回无效。 那么,命令处理程序是否返回值? 答案? 从吉米·博加德(Jimmy Bogard)的“ CQRS神话”中获取线索,我认为该问题的答案取决于您在说什么程序化/上下文“象限”: +-------------+-------------------------+-----------------+ | | Real-time, Synchronous | Queued, Async | +-------------+-------------------------+-----------------+ | Acceptance | Exception/return-value* | <see below> | | Fulfillment | return-value | n/a | +-------------+-------------------------+-----------------+ 验收(例如验证) 命令“接受”主要是指验证。假定验证结果必须同步地提供给调用方,而不管命令“完成”是同步的还是排队的。 但是,似乎许多从业者并不从命令处理程序中启动验证。从我所看到的,这是因为(1)他们已经找到了一种在应用程序层处理验证的绝佳方法(即,通过数据注释检查有效状态的ASP.NET MVC控制器)或(2)一种体系结构假设命令已提交到(进程外)总线或队列中。后一种异步形式通常不提供同步验证语义或接口。 …