2

当您有多个相同对象的表示时，您如何解决这种情况，具体取决于视图？

例如，假设您有一家书店。在书店中，您有 2 种主要的书​​籍表示形式：

  1. 在列表中（搜索结果、按类别浏览、作者等）：这是一个紧凑的表示，可能有一些聚合，例如 NumberOfAuthors 和 NumberOfRwviews。每个作者和评论都是自己保存在数据库中的实体。
  2. DetailsView：在这里你不会有聚合，而是每个作者的真实值，因为 Book 有一个属性 AuthorsList。

案例 2 很清楚，您从 DB 中获取所有内容并显示出来。但是如何解决案例 1. 如果您想减少与 DB 之间的连接数和有效负载？因此，如果您不想从 DB 中获取所有实际的作者和评论，但每个人只需要 2 个整数来计数。

完全规范化的解决方案是 2，但 1 似乎需要一些非规范化或创建 2 个不同的实体：业务层中的 BookDetails 和 BookCompact。

重要提示：我不是在谈论查看 DTO，而是实际上从不适合业务层书籍类的数据库中获取数据。

4

2 回答 2

0

通过以下设计，我得到了非常好的结果：

  • domain包包含@Entity包含所有必要数据的类，这些数据存储在数据库中

  • dto包含将从服务返回的实体的视图/视图的包

Dto 应该有以实体为参数的构造函数。为了更轻松地复制数据，您可以使用BeanUtils.copyProperties(domainClass, dtoClass);

通过这样做，您只共享了最少量的信息，并且它在没有任何功能的对象中返回。

于 2016-11-25T15:35:46.280 回答
0

对我来说，这听起来像是多个查询模型 (QM)。我使用具有 CQRS/ES 样式的 DDD，因此聚合根根据传入的命令生成事件。为这些事件订阅了多个 QM。所以我根据需求创建了多个“视图”。
ES（事件溯源）具有巨大的力量——我可以稍后通过重放存储的事件来引入另一个 QM。
听起来像是管理大量相似甚至重复的数据，但这对我来说很有意义。
QM 可以并且经过优化以包含足够的数据/结构/索引用于给定目的。这就是“共享数据模型”的出路。我看到了“RDMS”中的巨大邪恶，一种适用于所有方法的方法。你总是会迷失在管理共享模型的复杂性中——就像你一样。

于 2016-11-18T10:15:59.887 回答