在我的网络应用程序中,我正在跟踪页面上的查看次数。
现在,控制器中的操作向数据层发出命令,以在返回查询结果之前增加模型上的视图计数。
这个动作似乎打破了命令-查询-分离的规则,因为用户代理正在提交一个查询并在不知情的情况下发出一个命令(以增加视图计数)
需要采取哪些架构决策来维护此操作中的命令-查询-分离?
在我的网络应用程序中,我正在跟踪页面上的查看次数。
现在,控制器中的操作向数据层发出命令,以在返回查询结果之前增加模型上的视图计数。
这个动作似乎打破了命令-查询-分离的规则,因为用户代理正在提交一个查询并在不知情的情况下发出一个命令(以增加视图计数)
需要采取哪些架构决策来维护此操作中的命令-查询-分离?
您应该考虑相对于相关操作的概念级别的 CQS。以下是一些似乎都违反 CQS 的示例,但仅在不同的概念级别上这样做:
ReadFile
调用不会修改文件 - 但它可以更新文件上最后访问的时间戳。FindById
调用不应更改数据库 - 但它可以很好地将查询的对象添加到缓存中。这些示例有一个共同点:它们维护model
客户端工作的状态,但它们确实修改了该模型之外的数据。这并不违反CQS。
另一种看待这一点的方法是通过最小意外原则。上述 REST API 的客户端不会期望模型随着 GET 请求而改变,但他并不关心 API 是否更新统计计数器。