资源项总数计算（单独查询与集合）答案

【问题标题】：resource items total count calculation (separate query vs collection)资源项总数计算（单独查询与集合）
【发布时间】：2015-09-14 09:23:32
【问题描述】：

在返回资源集合时，我正在努力寻找获取项目总数的最佳方法，我正在考虑两种方法，只是希望您对什么是最好的有意见？

场景：

用户想要从我的10000 车辆中检索10 车辆列表，其中包含一些光标，例如（限制、之前、之后、过滤器等...）

选项 1：

class VehiclesRepo()
{
    function getVehicles(){
        // get 10000 vehicles with one query; : returns collection
        // return 10000 vehicles and do filtration on transformation layer to keep total_count of vehicles 
    }
}

选项 2：

class VehiclesRepo()
{
    function getVehicles(){
        // get 10 vehicles with one query including filtration; : returns collection
        // return 10 vehicles, and do another query for total_count
    }
}

请考虑对内存、cpu 循环的操作影响？我的系统也完全是 ddd 所以我尽量不要有域泄漏

【问题讨论】：

问题是什么？您是在谈论 “此查询匹配 10 个可能的 10000 个结果中的 10 个结果” 以输入到您的响应中吗？这里不是很清楚。
正是@BlakesSeven 我试图做到这一点，而不必从域外部访问基础设施层
这就是伟大的 DDD pfft！和问题。如果你想设计对底层存储机制一无所知的类基础设施，那么你最终会得到只处理基本编码概念的垃圾，例如 “拉入这个巨大的数据列表，计算其中有多少东西，然后给我一个过滤后的计数和该标准的结果”。对于小型阵列来说，这当然很好，但在现实世界中却分崩离析（我似乎有人尝试过）。如果有的话，有“总计数”和“查询”的访问器，你可以将它们与下面的“智能”方法联系起来。两个查询。

标签： php performance mongodb domain-driven-design transformation

【解决方案1】：

我试图做到这一点，而不必访问基础设施层域外

这实际上是你的问题。 DDD 聚合是围绕命令处理、事务一致性和业务不变量设计的，而不是查询需求。

这就是如今 CQRS 如此受欢迎的原因。我强烈建议您不要依赖您的域模型来满足查询需求。

【讨论】：

OP 没有询问 CQRS，所以我认为这不能回答问题。
@theDmi CQRS 没什么神奇的。它只是意味着将查询与命令分开。您不需要框架、单独的数据存储或异步命令。在通过域模型进行查询时，您将在某些时候遇到 SELECT n+1 问题，事情会变得越来越糟。不仅如此，共享单个模型也有利于使用延迟加载来进行大型聚合，这在当今也被认为是一种反模式。
我知道这没什么神奇的，但也不是灵丹妙药。但这甚至不是这里的主题，我只是说问题与 CQRS 无关。对于 OP 的项目，CQRS 是否是一种好的架构风格，恕我直言，仅凭这个问题就无法判断。

【解决方案2】：

这两个选项基本上都可以，但我认为如果使用选项 1，10,000 辆汽车已经存在性能问题。所以我会选择选项 2。

但是您的设计可能还有另一个问题：

我正在尝试这样做，而不必从域外部访问基础设施层。

此评论表明您具有以下分层：

 Application
      ⇣
   Domain
      ⇣
Infrastructure

如果您不使用某种Dependency Inversion Priciple，它实际上使基础架构依赖于域层，那么您的这种设计就有问题。域应尽可能纯净。如果域依赖于基础设施，这意味着您不能独立于基础设施使用域模型。这很糟糕，因为基础架构是人为的东西，在您的域的现实世界中并不存在。

所以你在概念上应该做的是：

Application
   ⇣     ⇣
   ⇣    Infrastructure
   ⇣    ⇣
   Domain

然后您的存储库实现变得自然并允许查询操作，例如：

给我 ID 为 X 的车辆
给我所有车轮超过 Y 的车辆
给我所有符合过滤器 Z 的车辆

请注意，这些查询操作应返回实际的业务对象，而不是 DTO 或数据库行等。

如果您想详细了解不同架构与 DDD 的优缺点，我建议您阅读 Vaughn Vernon 的实施 DDD 中的“架构”一章。

注意@plaxl 的答案：答案是针对 CQRS 的，您在问题中只字未提。所以在 CQRS 上下文之外，使用域模型进行查询操作是非常好的。

【讨论】：