资源项总计数计算(单独查询与集合)

时间:2015-09-14 09:23:32

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

我正在努力寻找获得资源集合时获取项目总项目的最佳方法我想到两种方法只是希望你的观点最好吗?

场景:

用户希望从我的10车辆中检索10000车辆的列表,其中包含一些游标,例如(限制,之前,之后,过滤器等等)

选项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所以我试图不让域泄漏

2 个答案:

答案 0 :(得分:2)

  

我试图在不必访问基础设施层的情况下这样做   来自域外

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

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

答案 1 :(得分:1)

这两个选项基本上都没问题,但我认为如果您使用选项1,那么对于10&000; 000车辆,您已经遇到了性能问题。所以我选择了选项2.

但您的设计可能存在另一个问题:

  

我试图在不必从域外访问基础架构层的情况下这样做。

此评论表明您有以下分层:

 Application
      ⇣
   Domain
      ⇣
Infrastructure

如果您不使用某种实际上使基础架构依赖于域层的Dependency Inversion Priciple,那么您就会遇到此设计的问题。域名应尽可能纯净。如果域依赖于基础结构,则意味着您无法独立于基础结构使用域模型。这很糟糕,因为基础设施是一个人为的东西,在您的域的现实世界中不存在。

那么你应该从概念上做到这一点:

Application
   ⇣     ⇣
   ⇣    Infrastructure
   ⇣    ⇣
   Domain 

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

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

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

如果您想了解更多关于使用DDD的不同架构的优缺点,我建议您阅读章节"架构"在实施DDD 中由Vaughn Vernon撰写。

关于@ plaxl答案的说明:答案是针对CQRS的,您在一个单词中没有提到。因此,在CQRS上下文之外,使用域模型进行查询操作是完全没问题的。