使用 ORM 进行域修改。使用 SQL 视图进行所有读取操作。这是 CQRS 的一种形式吗？
各位， 我正在研究一个模型，用户可以选择默认值或输入自定义值，结果形成许多基于人口的预测。
我喜欢使用类似于 CQRS 的方法来分离报告和影响域的代码。
我打算在一项服务中使用带有 ADO.NET 的基本 SQL 视图来生成报告，并在另一项服务中使用实体框架来保存修改。
我认为这里不需要事件溯源。报告将根据域数据库完成。
上面是CQRS的例子吗？
Folks,
I am working on a model where users can choose defaults or enter custom values, the results form a number of population-based projections.
I am drawn to using a CQRS-like approach to separate reporting and domain-affecting code.
I intend to use basic SQL views with ADO.NET in one service for reports, and Entity Framework in another service for persisting modifications.
I don't think that event sourcing is required here. Reporting will be done against the domain database.
Is the above an example of CQRS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，这是一个基本形式。毕竟，读取和写入是分离的，并且各自的职责由不同的服务处理。而且，你的读取服务不会触及你的领域层，它直接从服务层到 ORM。这绝对是 CQRS 的基础。
事件溯源实际上不是 CQRS 的一部分。不过，这两种做法经常结合在一起。
It's a basic form, yes. After all, reading and writing are separated, and the responsibilities for each are handled by different services. Moreover, your read service doesn't touch your domain layer, it goes straight from the service layer to the ORM. That is definitely the basis of CQRS.
Event Sourcing is actually not a part of CQRS. The two practices are often combined, though.
它不完全是 CQRS，但它是 CQRS 引入 DDD 解决方案的良好实践，我在博客中通过示例详细介绍了该主题 这里
您采用将读取与写入模型分离的概念，使您的域更加稳固，但没有分离的复杂性数据库和事件存储。
It is not fully CQRS but it is a good practices from CQRS to bring into your DDD solution, i blogged exactly about this topic with example here
You take the concept of separating read from write model to make ur domain more solid, but without the complexity of separating database and event storage.