【问题标题】:CQRS with multiple entities in EFEF 中具有多个实体的 CQRS
【发布时间】:2021-12-29 09:00:13
【问题描述】:

我有以下情况:

State 实体是根,它包含多个参数,最重要的是 URL 和 ID。 然后我有 3 个实体可以选择连接到状态,但总是必须是 1 并且只能是 1。

将消息(实体)发送到命令时。我应该为每个选项制作 3 个不同的命令(这对我来说似乎最有可能),还是应该发送所有实体,即使有些实体可能是空的并在命令中弄清楚? 或者是否有另一种/更好的方法来处理这个问题。因为我习惯将所有数据都包含在 1 条消息中,但我现在不能拥有。

【问题讨论】:

  • 对我来说似乎很基于意见。
  • @GertArnold:并非每个具有多种可能解决方案的问题都是基于意见的。 OP 的问题是恕我直言,充分具体地说明了采取哪种方法(何时)。

标签: c# entity-framework cqrs


【解决方案1】:

CQRS 并没有规定您应该如何划分命令(或查询)的逻辑。没有什么本质上表明您必须将此创建逻辑分成几个单独的创建命令。

可以在 BLL 或 DAL 上实施 CQRS。这会影响首选方法。你没有具体说明,所以我无法判断。

一般来说,在 BLL 上使用 CQRS 时,我将命令范围限定为单个事务。如果您需要 State 与其依赖项之间的交易安全(这在您的情况下听起来很可能),请坚持使用单个命令。
如果您不需要交易安全,例如如果您可以将依赖项的创建推迟到稍后阶段,则将这两个命令分开。

请注意,即使使用单个命令,您仍然可以将每个实体的创建逻辑抽象为例如它们自己的存储库方法将由命令处理程序调用(通过其注入的依赖项)。这很好。您无需通过单独的命令进行路由。

如果您的 CQRS 在 DAL 上实现,但 BLL 管理事务(或您没有事务),您可以创建单独的 DAL 命令,BLL 服务将在需要时触发这些命令。然而,用可能是空的信息盲目地触发这些命令是没有意义的,这意味着什么都不应该做。仅当您知道需要执行命令时才触发命令。 BLL 服务应该检查是否需要创建依赖实体,然后才应该触发相应的命令。

在所有情况下,应为 State 实体仅创建一个依赖项这一事实是业务逻辑,这应在 BLL 上实现。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多