架构：简单的CQS
我正在考虑为我的 ASP.NET MVC 网站应用 CQS，但事情非常简单。我指的不是 CQRS，因为我想对查询和命令部分使用相同的数据源，因此我不需要事件源和其他更复杂的模式。
所以，我的想法是：
- 查询部分使用同一个数据库，
- 查询部分使用命令部分，用实体框架和WCF数据服务暴露数据库视图，以便将特定视图返回给客户端，查询数据变得非常
- 容易命令部分，使用实体框架和单向 WCF 服务公开数据库表，并使用 DDD 原则。
我想要实现的主要目标是：
- 由单向服务操作执行的简单命令，并由丰富的域模型处理，客户端只需要传递真正需要的数据来
- 对简单视图执行命令灵活查询，专为客户端的特定 UI 设计，
这有意义吗？
I'm thinking about applying CQS for my ASP.NET MVC web site, but in a very simple matter. I don't mean CQRS, because I want to use the same data source for query and command parts, and so I don't need event sourcing and other more complex patterns.
So, what I have in mind is:
- use the same database for query and command part
- for the query part, expose database views with entity framework and WCF data services, so that specific views are returned to the client, querying data becomes very easy
- for the command part, expose database tables with entity framework and one-way WCF services, and using DDD principles.
The main thing I want to achieve is:
- simple commands that are executed by one-way service operations, and handled by a rich domain model, client needs to pass only the data that is really needed to perform the command
- flexible querying on simple views, designed for the specific UI of the client
Does this make sense?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所以，回答你的问题，是的，我认为这是有道理的。
我不确定您还在寻找什么。我认为您所采取的方法是有意义的，并且应该能够满足您的需求。
在我看来，CQS 和 CQRS 非常相似，其中 CQRS 具有单独的读取和写入存储的概念（有些人会认为写入存储甚至可能没有必要）。事件溯源实际上并不是 CQRS 的一部分 - 可以说，它是一个附加组件，非常适合 CQRS 的分布式特性。
您的方法放弃的是数据的一些可扩展性，因为您使用视图来展平数据。但如果您的应用程序不需要它，那就没有问题。
另外，阅读 Udi Dahan 的文章 关于何时避免 CQRS。它可能有助于证明您的决定的合理性。当他发布时，引起了不小的轰动。但他和 Greg Young 都是 CQRS 方面的专家。
我不确定我是否回答了您的问题或有所帮助，但祝您的项目顺利！我希望这有帮助。
So, to answer your question, yes I think it makes sense.
I'm not sure what else you're looking for. I think the approach you're taking makes sense and should give you what you are looking to do.
In my opinion, CQS and CQRS are very similar, where CQRS has the concept of separate read and write stores (and some would argue that the write store may not even be necessary). Event sourcing isn't really part of CQRS - it's an add-on, so to speak, that fits in nicely with the distributed nature of CQRS.
What you're giving up with your approach is some of the scalability of the data since you're flattening the data using views. But if your app doesn't require it, then there's no problem there.
Also, it may be useful to read Udi Dahan's article on when to avoid CQRS. It probably helps justify your decisions. It caused quite a stir when he released it. But between him and Greg Young, they're the experts on CQRS.
I'm not sure if I answered your question or helped, but good luck with your project! I hope this helps.