CQRS 命名约定
我正在实现一个新的 Web 服务，虽然我还没有使用 CQRS，但我想创建我的服务，以便将来可以轻松地将其迁移到 CQRS。因此，我想知道 DTO 类和方法的命名约定。
我读过这篇博客文章 关于 DTO 命名约定，这对我来说似乎很明智。它建议以下...
- SomeSortOfQueryResult
- SomeSortOfQueryParameter
- SomeSortOfCommand
- SomeSortOfConfigItem
- SomeSortOfSpecification
- SomeSortOfRow
- SomeSortOfItem（对于集合）
- SomeSortOfEvent
- SomeSortOfElement
- SomeSortOfMessage
我在这里问的是我应该如何命名我的方法。使用 GetSomething 是个好习惯还是 SomeQuery 更好？
I'm implementing a new webservice and while I'm not yet using CQRS I would like to create my service so it could easily be moved to CQRS in the future. So, I'm wondering about naming convention for my DTO classes and also my methods.
I've read this blog post on DTO naming conventions and it seems sensible to me. It suggest the following ...
- SomeSortOfQueryResult
- SomeSortOfQueryParameter
- SomeSortOfCommand
- SomeSortOfConfigItem
- SomeSortOfSpecification
- SomeSortOfRow
- SomeSortOfItem (for a collection)
- SomeSortOfEvent
- SomeSortOfElement
- SomeSortOfMessage
What I'm asking here is how I should name my methods. Is it good practise to use GetSomething or would SomeQuery be better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
命名实际上应该来自该方法正在执行的操作。退后一步，首先查看命令查询分离 (CQS)。您在这里真正想做的是确保任何给定的方法要么查询数据或命令发生某些事情。
即“请求一个值不应改变该值”。
CQRS 是不同的东西，规模更大，而且通常不太容易被理解。不过，它不一定很复杂，只需在架构级别而不是代码级别应用 CQS 概念即可。例如，您可以选择 WCF 作为命令，选择原始 SQL 作为查询。它的目的是让您自由地使您的查询成为可能有效的最简单的事情，同时您的命令仍然可以获得完整的域模型或其他适合您的业务规则的实现的丰富性。
CQRS 还引导您远离 CRUD 应用程序，转向基于任务的应用程序，在这种应用程序中，您可以更多地关注用户交互方面的问题域，而不仅仅是读取和保存数据。
查询
一般来说，只要意图明确（即 < strong>返回一些数据，不修改任何数据）。
命令
通常，命令很难命名，尽管您可以用与 PowerShell 的 cmdlet 命名约定类似的术语来思考 -
动词-名词。就我个人而言，我倾向于将命令实现为 CommandProcessor 模式，其中命令实际上是包含参数的对象（有时只是实体的主键）。有代码可以为每个命令的类型查找适当的“处理器”。通常在 CQRS 中，您会尝试保持同步，因为异步意味着您在处理无法处理的命令方面有更多工作要做，但如果您确实需要异步命令，那么命令的处理程序可能会发送向 ESB 发送消息以执行此操作。Naming should really just come out of the thing the method is doing. Take a step back and looking at Command-query separation (CQS) first. What you're really trying to do here is make sure that any given method is either querying for data or commanding that something happen.
I.e. "Asking for a value should not change the value".
CQRS is something different, on a larger scale, and generally less well understood. It's not necessarily complex, though, just applying the CQS concept at an architectural level rather than a code level. You might choose WCF for commands and raw SQL for queries, for example. It aims to allow you the freedom to make your queries the simplest thing that could possibly work, while your commands still get the richness of a full Domain Model or other suitable implementation for your business rules.
CQRS also steers you away from a CRUD application, to a task-based one where you focus more on the problem domain in terms of user interactions than just reading and saving data.
Queries
Generally I name "queries" variations on
FindXYZ(),GetXYZ()orLoadXYZ, as long as the intent is clear (i.e. return some data, don't modify any).Commands
Typically commands are harder to name, though you can think in similar terms to PowerShell's cmdlet naming conventions -
verb-noun. Personally though I tend to implement commands as a CommandProcessor pattern, where commands are actually objects containing parameters (sometimes only a primary key of an entity). There is the code to look for appropriate "processors" for each command'sType. Typically in CQRS you'd try and keep this synchronous, because async means you have more work to do with respect to handling commands that failed to be processed, but if you really need a command to be async, then your command's handler might send a message to an ESB to do so.在 CQRS 的背景下谈论 DTO 对我来说敲响了警钟，因为你专门谈论了查询方面。引用那篇博客文章
架构对我来说意味着薄查询端，即您不需要使用序列化对象或 DTO 在它们之间移动信息的层数太多。您可能以不同的方式使用 DTO 一词。
这并不能真正回答你的问题，但我想指出这一点。
Talking about DTOs in the context of CQRS rings alarm bells for me where you are specifically talking about the query side. Quoting that blog article
A CQRS architecture implies a thin query side to me i.e. you don't have lots of layers where you need to move information between them with serialized objects or DTOs. It might be that you're using the term DTO in a different sense.
That doesn't really answer your question but I wanted to point it out.