2

我正在尝试确定处理演示逻辑的最佳位置。我已经分离出我的读取查询 (CQRS)，每种方法都为我的视图查询和生成 DTO。但我的视图只是模板，其中散布着来自 DTO 的变量。他们没有任何逻辑。

假设我想做一些事情，比如重新格式化日期的外观，将标志转换为实际的描述性词，或者根据从数据库中查询的内容对显示的内容添加一些条件，等等。我正在考虑将这个逻辑放入每个查询中，并且不用担心过于干燥（我发现在某些情况下，如果你干燥太多，那么你可能会让事情变得难以改变，因为你必须检查每个依赖项或希望您的单元测试能够坚持下去）。我可能会在这里和那里使用一些“助手”来进行我发现我一直在做的格式化，但我认为不需要添加一个完整的其他“表示层”。因此，表示逻辑将驻留在每个查询中并进入返回的 DTO，然后直接放入视图中。这将使 CQRS 的读取端保持超薄，并且有意义，因为每个视图对应于一个读取查询。但我也担心某些表示逻辑将非常特定于域。新加入的开发人员需要查看其他查询并重复相同的格式化技术，而不是直接从原始查询中扔出数据。

这是合理的方法，还是在 DDD/CQRS 中使用了另一种方法？我无法从我所做的 CQRS 研究中找到任何指导。注意：我碰巧使用的是 PHP/MySQL，但我想这个问题与语言无关。

4

1 回答 1

5

我认为了解 CQRS 最重要的部分是它不必很复杂。事实上，对于事情的阅读方面，选择最简单的解决方案，该解决方案将起作用且可维护。如果您只需要一个视图中的 SELECT 语句来绑定到网格，那么为什么要制作一堆层、DTO 和 Web 服务呢？这是否为业务增加了任何价值？但是，如果有正当理由在等式中添加层，那么您可以这样做，并且通常 DTO 是在这些层之间进行通信的好方法。

根据手头的用例，您的系统可能需要不同的查询策略，因此这不必是一种万能的方法。性能应该始终是您最关心的问题之一，因此请让数据尽可能接近使用的演示代码，并且仅在真正需要时才增加复杂性。

如果表示层直接从数据库中读取，有人可能会说这不是松散耦合的。然而，仅仅因为你在两件事之间有很多层，并不会使它们松散耦合。事实上，它可能是相同数量的耦合，但现在你已经添加了一个维护头痛，因为每次添加一个字段都必须触摸 10 个地方。

更多地关注您的命令方面，并为阅读方面做任何觉得实用的事情。

于 2015-04-13T21:55:25.333 回答