问题标签 [command-query-separation]

CQS 原则说，每个方法都应该是执行操作的命令，或者是向调用者返回数据的查询，但不能同时是两者。查询不做任何其他事情是有意义的，因为您不希望查询更改状态。但是，如果命令返回一些额外的信息，它看起来是无害的。您可以使用返回的值，也可以忽略它。为什么 CQS 原则要求 Command 不返回任何值？

我有一个基于查询参数和查询结果运行查询的界面

我希望任何继承自IQuery的类都能够返回一个IQueryResult或一个IEnumerable或Array的单个实例IQueryResult。我当前的设置不允许这样做，编译器对我大喊大叫GetBushCodes：

我不想使用该设置IQueryParam<TResult> where TResult : IQueryResult，因为这似乎具有限制性，我想尝试保持IQueryResult约束，IQuery因为GetBushCodes如果我摆脱了约束，则编译。

如果 CQS 阻止命令返回状态变量，那么如何为可能不成功的命令编写代码？假设您不能依赖异常。

似乎任何请求/响应都违反了 CQS。

所以看起来你会有一组“我可以妈妈”的方法来给出命令返回的状态。在多线程/多计算机应用程序中会发生什么？

如果我有三个客户端希望请求服务器的对象增加一（并且对象的限制为 0-100）。所有人都检查他们是否可以，但一个人得到了——而另外两个人不能，因为它刚刚达到了极限。看起来返回的状态可以解决这里的问题。

我一直在使用在线提供的 MVVM 示例中通常提到的基本设计模式编写我所有的 MVVM 应用程序。我遵循的模式如下所述：

模型

本节包括 DTO 类及其属性和接口 IDataService 等：

代理人

该层包含实现 IDataservice 的 Dataservice 调用，例如：

视图模型

该层包含 ViewModel 以及对从中接收所有数据的模型和代理层的引用：

所有的 ViewModel 都继承 BaseViewModel。每个 viewModel 还包含在 UI 触发事件时执行的 Delegatecommand。然后，它通过在代理层调用 DataService 从服务器获取数据并执行业务逻辑并填充绑定到视图的 ViewModel 中的属性。对于每个 View，都有一个绑定到 View 的 Datacontext 的 VM。ViewModel 还负责启动我使用触发器启动故事板的动画，该故事板绑定到我在 VM 中的枚举以更改这些触发器的状态，例如： http: //www.markermetro.com/2011/05/technical/ mvvm-friendly-visual-state-management-with-windows-phone-7/

看法

在这一层中，我拥有所有视图、用户控件和业务逻辑，并实现了某些依赖项，例如 GeoLocation 服务、AES 加密、视图之间的 NavigationService 等。

每个视图都有 .xaml 和 .xaml.cs 文件。在 .xaml.cs 文件中，我将视图的数据上下文与 VM 绑定，如下所示：

从这里开始，所有的绑定都会发生。

我的问题是，最近我知道这种模式没有遵循我在回答我的问题时了解到的 SOLID 设计模式： Simple Injector injection multiple dependency in BaseClass

我正在努力按照我之前的问题答案中给出的建议来改变我的设计。但我无法得到一些东西，比如：

1. 当前 View Datacontext 绑定到 ViewModel，因此所有控件都由 VM 中的属性控制。我将如何使用处理器/服务或 DialogHandler 将其更改为上述模式？

2. 我正在使用绑定到 UI 元素的命令属性的委托命令。执行这些命令会发生某些动作，例如动画，显示用户控件。如何在命令模式中做到这一点？

3. 我怎样才能开始改变我当前的实现，以用最好的方法来适应所有这些变化？

我正在创建一个拉式解析器，它在很大程度上依赖于以顺序方式读取字符。解析器的状态随着字符的读取而变化，因此我们可以说有一个“上下文”指定如何解释下一个字符。

问题是我通常发现有一些方法应该是查询，但它们也修改了状态。

例如，这个方法：

如您所见，这不仅会检索标识符，还会更改状态。如果最后一个字符是“=”，则状态为一，如果是“;” 国家是另一个。

这不符合 CQS 原则，我不太喜欢它:(

但鉴于它是一个解析器，也许这是最好的方法。所以我的问题是：你能想出一个更好的方法来做到这一点而不破坏 CQS 吗？

谢谢！

我可能对这个问题听起来很愚蠢，但我真的很困惑。创建命令、查询、命令处理程序、查询处理程序和存储库并使用依赖注入来分别基于查询和命令解析查询处理程序和命令处理程序符合 cqs 或 cqrs 吗？

或者将任务并行库用于命令和查询处理程序符合 cqrs 而不是 cqs ？

或者是否真的基于 Use Case 是否存在协作域的场景 --> 多个用户试图访问有限的数据。

这两个片段来自 JDK 源代码：

命令-查询分离 (CQS) 指出，每个方法都应该是执行操作的命令或将数据返回给调用者的查询，但不能同时是两者。JDK 源代码中的这两个片段是否违反了 CQS 原则？

我在服务端将查询和命令分开，如下所示：

命令查询分离接受方法应该改变状态或返回结果。没有问题。

我在服务端应用命令查询分离，但不在控制器类中应用。因为用户可能想查看创建的产品结果。但是commandService在Create Controller Action 方法中工作并且不返回创建的产品。

我们将返回给用户什么？所有产品？CQS 是否适用于应用程序生命周期？

我在我的应用程序中实现了事件溯源和 CQRS 模式。我受到CQRS 之旅的启发，我下载了示例代码。在那里，我找到了事件溯源的整个基础设施（CommandHandlers、EventHandlers、事件、信封......等），但它的代码量非常大，我无法想象我需要所有代码来进行简单的事件溯源。

您是否知道一些经过测试的常见库/nuget 包/项目，其中包含用于发送/注册命令、事件以及我在事件源模式中需要的所有基础设施？还是我应该自己实施？

在我的网络应用程序中，我正在跟踪页面上的查看次数。

现在，控制器中的操作向数据层发出命令，以在返回查询结果之前增加模型上的视图计数。

这个动作似乎打破了命令-查询-分离的规则，因为用户代理正在提交一个查询并在不知情的情况下发出一个命令（以增加视图计数）

需要采取哪些架构决策来维护此操作中的命令-查询-分离？