【问题标题】:CQS and updating an existing entityCQS 和更新现有实体
【发布时间】:2016-12-12 09:03:18
【问题描述】:

我只是想弄清楚如何使用 CQS 更新实体。假设 UI 允许用户更新特定实体的多个属性,并在提交时,在后端创建并调度更新命令。

我不太明白的部分是:

  1. cmd 处理程序是否从调度程序接收消息,然后从数据库中检索现有实体,然后映射接收到的库存项目属性,然后保存?或者
  2. 是否在发送 cmd msg 之前完成了对现有项目的检索,然后将其附加到该消息(检索到的附加到 cmd 的实体,然后发送)?

我的理解是,CQS 允许以后更轻松地过渡到 CQRS(如有必要)?那是对的吗?

如果是这种情况,上面 2 的问题是可以从一个看起来与命令/写入模式非常不同的模式检索查询。我错过了什么吗?

【问题讨论】:

    标签: entity-framework cqrs command-query-separation


    【解决方案1】:

    cmd 处理程序是否从调度程序接收消息,然后从数据库中检索现有实体,然后将接收到的库存项目属性映射到然后保存

    是的。

    如果你想了解,阅读 会有很大帮助——并不是说它们一定是耦合的,而是因为很多关于 CQRS 的文献都假设你熟悉 DDD词汇。

    但是命令处理程序的职责的粗略概述是

    1. 加载命令目标的当前状态
    2. 在目标上调用命令
    3. 保留对记录簿的更改

    我的理解是,CQS 允许以后更轻松地过渡到 CQRS(如有必要)?

    这不太对——理解 Meyer 对命令和查询的区别会使 CQRS 模式更容易思考,但我不相信这实际上有助于过渡。

    如果是这种情况,上面 2 的问题是可以从一个看起来与命令/写入模式非常不同的模式检索查询。我错过了什么吗?

    也许 - 查询通常使用针对查询进行优化的架构;另一种思考方式是查询返回相同实体的不同表示。

    当命令表示和查询表示解耦时,事情会变得棘手——也就是最终的一致性。从某种意义上说,你总是在查询过去的状态,但向现在的状态发送命令。因此,您将需要一些机制来处理错误地假设目标仍处于某个先前状态的命令。

    【讨论】:

    • 谢谢。我已经完成了几门 ddd 课程并阅读了一些 Eric Evans、Greg Young 和 Martin Fowler 围绕该主题的帖子,但在尝试应用我所学的内容时发现,我只是不太确定一些方面。感谢您填补空白,非常感谢。
    • 可能是另一个很明显的愚蠢问题,但是命令和查询处理程序最好放在 BLL 或 DAL 层吗?我更倾向于 BLL 层,因为那时我不需要从处理程序外部将我的域模型映射到我的数据/实体模型(映射都可以封装在处理程序中 - 防止进一步污染我的 BLL映射代码) - 这是正确的吗?这也更符合单一职责原则。
    • 业务逻辑层,通常——在您的单元测试中,您通常会使用存储库 (DAL) 的测试替身来测试命令。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-05-20
    • 2022-10-18
    • 2011-12-19
    • 1970-01-01
    • 2017-05-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多