1

我正在使用 Seedstack 16.7 及其支持 JPA 插件的业务框架。

从数据源获取数据有两种方法。

  1. 存储库http://seedstack.org/docs/business/manual/repositories/

    • 它们几乎是代表 JPA 上的传统 EntityManager 行事的那些，以保持类型安全。

  2. 查找器http://seedstack.org/docs/business/manual/finders/

    • 他们从数据源中检索 Dto。

它们之间唯一明显的区别是 finder 是数据源的只读接口。

查找器所需的大多数查询都可以通过调用存储库并从聚合转换为 Dto 来完成

他们之间有什么真正的区别，或者他们的意图吗？除了关于这个问题的说明。

4

1 回答 1

1

用几行来解释它有点复杂，因为建模决策来自对 DDD、CQ(R)S、快速读取模型、最终一致性等的深入理解。

  • 发现者

正如手册所说：“查询持久层或任何数据源以获取特定于应用程序接口的对象”。这里的关键字是Interface。在图形 UI 的情况下，查找器的使用是检索具体视图以将其呈现在桌面表单或网页中。在非 CRUD 应用程序中，UI 应该是基于任务的，因此：

  1. 您的视图与您的实体和聚合不匹配。
  2. 您的实体和聚合不（不应该）包含选择数据的完整列表，即：州和城市（经典级联依赖组合框）
  3. 您的聚合和实体不（不应该）包含引用实体的完整列表（具有大量订单的客户类，其中包含所有订单数据，是错误的 DDD 聚合建模），但您必须在应用程序的某个位置显示完整的订单列表。
  4. 您的视图和聚合可以从不同的数据源中检索（通常是为了查询性能和/或最终一致性）。即NoSql readmodels，非规范化的关系数据库或域关系数据库中的预计算视图（而不是代表您的实体的表）。

所以你在 UI 和聚合/实体之间有一个阻抗错配。解决这个问题的最好方法是明确地创建一种处理从持久性到视图的方法。查找器开始发挥作用。

  • 存储库

当用户发出一个暗示您的域发生更改的命令时，您必须检索一个聚合并将聚合根用作操作的入口点。这确保了域的一致性和不变量（规则）。聚合建模有很多细微差别（看这里），这使得尝试为视图使用聚合和实体是个坏主意。因此，您需要一种从数据源读取和构建内存聚合的方法。这是存储库的工作。有时，存储库会为您提供在检索视图数据时不需要的额外功能，例如实体更改跟踪、创建唯一标识以持久保存等。在处理视图时，您不需要任何这些。存储库开始发挥作用。

于 2016-09-20T10:09:43.523 回答