问题标签 [command-query-separation]

我有一个调用 2 个 WCF 服务的 WPF 客户端。

一项服务仅用于查询，一项服务用于命令（CQS 模式）。

我应该如何调用命令服务？

我在某处读到命令服务中的所有操作都必须是“单向”的，因为它们不应该返回任何值。如果出现问题 - 操作应该向客户端抛出“FaultException”。

但是如果命令都是单向的 - 我在客户端做什么？

假设我在 WPF 客户端中有一个“添加产品”窗口，我输入信息并按“保存”。

我现在在服务中调用“AddProduct(Product)”，但是：

1. 它应该关闭窗口吗？
2. 是否应该等待 10 秒以查看是否没有任何 FaultException ？
3. 操作不应该是“单向”吗？如果是这样 - 命令服务中的所有操作是否应该返回某种类型为“成功”或“失败”的通用“结果”对象？
4. 如果第 3 部分为“是”-我是否应该在单独的线程中调用该服务并“禁用”窗口上的所有控件，直到我从该服务得到响应？

谢谢。

在我的各种项目中，我实现了命令/查询分离模式并使用 NHibernate 作为我的 ORM。

一般来说，我将我的命令和查询保存在与特定活动集相关的单独项目中，例如，UserManagement等。TagManagementQuestionManagement

我非常喜欢将所有内容都很好地划分到这些存储库中，并具有易于查找的功能。以这种方式做事当然有好处。

然而，我开始怀疑这种抽象对于基本查询的价值，特别是考虑到 NHibernate 本身已经提供了如此强大的抽象。

在我的 MVC 控制器中考虑这一点：

我可以将其抽象为UserManagement存储库中的查询，但我不确定它提供了什么价值。

你怎么看？您会将所有内容都保留在命令/查询范式中，还是直接在控制器中使用 nhibernate 会话来处理像这样的简单请求？

命令-查询分离“规定每个方法要么是执行操作的命令，要么是向调用者返回数据的查询，但不能两者兼而有之。换句话说，提出问题不应改变答案。”

在这里，在 Ruby 中，pop命令返回从数组中弹出的项目。

这是一个方法中的命令和查询示例，似乎有必要这样做。

如果是这种情况，拥有一个本质上既是查询又是命令的方法真的是代码异味吗？

我目前正在开发一个 MVC 4 应用程序。我计划实现一个命令查询分离模式来提高性能和应用程序的结构。我对我的命令很满意——将我的视图模型映射到我使用的实体，然后使用 nhibernate 来保存我的数据。命令和查询将在同一个数据库上运行。

我有点不确定管理我的查询的最佳方法。在我的上一个项目中，我对所有读取/查询都使用了存储过程，然后使用 automapper 将我的 IDataReaders 映射到我的 ViewModels。这工作正常，但主要问题是编写存储过程的周转时间以及域模型更改存储过程不同步的时间。

因此，理想情况下，我想要从我的视图模型中自动生成视图或存储过程的东西。但实际上，我看不到这样做的方法。由于 Sprocs/Views 需要一些可能不止一张表的知识。因此，仅仅反映 View 模型属性是不够的。我可以为每个视图模型自动生成一个表，在开发过程中读取它，然后一旦域稳定并且在我们去测试之前将它们转换为视图/存储过程？

所以我想我要问的是：

1. 有没有人设法解决我上面描述的 sproc/view 自动生成问题？（这将是我最喜欢的结果！）或者更好的是设计了一个更优雅的解决方案！
2. 或者只在绝对必要的地方实现原始 ADO 读取是否更明智——即搜索，并且不需要大量的存储过程/视图。但是仍然将我的查询分离到一个单独的通道中（但其中一些使用 NHibernate，而另一些使用我的 ADO 阅读器）。

（ps我已经查看了其他与stackoverflow CQS相关的问题，我希望我的问题足够不同以保证这个问题）

我将使用 CQS（作为其设计的一个方面）开始一个新项目，但没有 CQRS + 事件溯源、事件流处理或历史建模。当我遇到这样一种情况时，我将有一大群人使用一小部分数据（并且不想阻止用户），我将实施事件溯源。这意味着（至少对我而言）我所做的只是从命令与查询的分离（关注点分离）开始。

我在命令端使用 EF ORM 和实际的 Schema。在查询方面，最好只使用视图（根据我正在阅读的内容），但我认为这种观点并不妨碍我使用 ORM（或不使用）和/或 Repo，或 ADO.NET + 存储过程，等等，作为从数据库访问这些视图的方法（我认为）。

这是我为大致说明我的想法而制作的图表（它绝不是全面的）：

我的问题：

第 1 部分：我不知道从数据库中检索数据（来自a View) 并使用 ViewModels (DTO) 为客户端提供某种状态的新视图（在调用命令端之后）？

第 2 部分：在我更改了基于任务的 Web UI 并因此更改了作为 UI 基础的 ViewModel 之后，当 ViewModel 与命令端的实体（域模型）完全分离时，如何从中发出命令. 这些 ViewModel (DTO) 可能是与实体完全不同的“形状”。

更新：

需要明确的是，我不打算使用异步和事务是一个加号，这只是命令和查询分离（不是完整的 CQRS，命令端只返回“void”）——我正在寻找这里的基础知识。此外，从我目前所读的内容来看，似乎 DDD 和有界上下文与 CQRS 齐头并进，在这一点上，我对 DDD 或聚合根以及有界上下文没有真正的经验，到目前为止还没有看到真正迫切需要参与这种方法/模式。目前，我似乎将在命令端使用 EF/Migrations，但尚未决定在查询端使用什么（正在考虑使用 ADO.NET）。

在我的例子中，命令端将返回一个对象，例如一个具有数据库生成的 CustomerId 的新客户。我将为命令和查询使用一个数据库，并希望使用数据库中构建的视图作为查询的返回模型（换句话说，我希望查询大部分“映射”到视图） . 我不知道如果我要使用查询端为命令端返回数据，在应该返回对象的情况下，命令应该如何看待。在 MVC 的情况下，我将尝试结合 Automapper 将对象转换为 ViewModel。

我有一个方法可以在数据库中创建一些条目并返回它的Id。我想以某种方式将这两者分开，因为它违反了命令-查询分离。
例如方法（简化）：

我知道有使用ref或out的解决方法，但我认为这些解决方案unclean。我想要具有以下签名的命令。

有没有办法我可以做到这一点？注意：我需要在创建后立即
知道新创建的条目的Id是什么。

我在高可扩展性网站上工作以用于学习目的。我决定使用 CQS 模式和 CQRS 的一些想法。我有单独的写入和读取层，供系统从消息总线（两个单独的消息总线）发送和接收的命令处理程序和事件处理程序使用。

我在处理命令时遇到了一些问题。我读到该命令不应该返回任何内容。现在的重点是：例如，我有一个表单，用户可以创建一个事件，或者例如更改他的个人资料（照片或姓名）中的某些内容。用户单击保存后，我想向他展示他的个人资料或将新事件添加到他的墙上。但是当命令只发送到总线时，我怎么知道他的个人资料已经更新了？我如何连接命令和 CRUD 操作的想法？或者可能是这个错误的想法？

考虑到领域事件模式和这篇文章，为什么人们建议每个事务模型保留一个聚合？当一个聚合可以改变另一个聚合的状态时，有很好的例子。即使通过删除聚合（或更改其身份）也会导致更改引用它的其他聚合的状态。有人说每个聚合保留一个事务有助于可伸缩性（每个服务器保留一个聚合）。但是这种思维方式不是打破了 DDD 的基本特征：技术不可知论吗？

因此，根据上面的陈述和您的经验，设计聚合、领域事件是否会导致其他聚合发生变化，这将导致每个交易有 2 个或更多聚合（例如：下新订单时）有 100 个项目将客户的状态从正常更改为 VIP )？

I'm trying to implement a command-query design pattern into a MVC spring based application.

I have, for example, some decorated commands using decorator pattern like bellow:

How can I inject such a handler into a controller constructor? Where should I instantiate this handler? A place where this can be instantiated can be the controller constructor, but this isn't the best solution. Any other ideeas?

Thanks

我已经阅读了这个 Spring MVC 应用程序的代码：

https://github.com/spring-guides/tut-rest/tree/master/6/complete/src/main/java/com/yummynoodlebar/core/events

我不了解事件文件夹中这些类的作用。我怎样才能在应用程序的另一个地方捕捉到这样的事件？

在这个应用程序中我不明白的另一件事是为什么他们不在服务层的某处使用命令查询分离。他们在休息控制器上使用了 CQS。我不同意这一点，相反，他们应该在服务层上使用 CQS 来提供一种简单的方法来向他们的服务添加验证或其他核心操作。这个链接描述了我所说的服务层上的 CQS 分离。

如果您对如何实现上面链接中描述的 CQS 模式有任何建议，请告诉它。