【问题标题】:Data Transfer Objects of entities with M:N or 1:N relationships具有 M:N 或 1:N 关系的实体的数据传输对象
【发布时间】:2013-11-15 10:15:48
【问题描述】:

我有 2 个实体 - 电影和演员 - 具有 M:N 关系。在为这些实体设计 DTO 对象时,我不确定正确的方法是什么。

电影

@Entity
@Table(name = "Movies")
public class Movie extends AbstractBusinessObject {    

    private String name;
    private String short_info;    

    @ManyToMany
    private Map<String, Actor> cast;

}

演员

@Entity
@Table(name = "Actors")
public class Actor extends Person{

    private String name;

    @ManyToMany(mappedBy = "cast")
    private Set<Movie> movies;

}

现在关于 DTO: 我遇到了两种处理 1:N 和 M:N 关系的不同方法。

仅保存 ID:

public class MovieDto {    

    private String name;
    private String short_info;    

    // Long represents Actor's ID
    private Map<String, Long> cast;

}

但是正如here 所说,我认为Instead of performing many remote calls on EJBs, the idea was to encapsulate data in a value object,这种方法显然违反了规则。

在 DTO 中保存 DTO: 另一种方法是存储 Actor 的 Dto,而不是其 ID。

public class MovieDto {    

    private String name;
    private String short_info;

    private Map<String, ActorDto> cast;

}

在我看来,这种方法会更快,因为我不必在每次需要显示演员姓名时都调用数据库。

这个假设是否正确,还是只存储 ID 会更好(即使考虑到第二种方法的空间消耗)?

另外,第二种方法会导致一个实体有多个 DTO。例如,我在查看“电影页面”时不需要知道演员演过哪些电影,但在查看“演员页面”时我需要知道。

【问题讨论】:

  • 你真的需要 dtos 吗?它们通常只是重复的代码。你可以返回一个实体,它只设置了 id 字段
  • 尽管它的代码重复(最初),但随着项目的扩大,它简化了很多。简单的例子是前端取决于 UI 设计者,他们并不真正关心实体/域模型是否具有他们试图呈现的信息。所以它的后端工作是聚合信息并通过 DTO 传递给前端。

标签: java web-applications dto


【解决方案1】:

在父 DTO 中嵌入其他 DTO 实例是完全可以接受的。当然,如果对象最终变得非常大,这可能会令人望而却步。所以这是你必须做出某种权衡的地方。

解决此问题的一种方法是使用部分表示和完整表示。在不需要完整数据的情况下,可以使用部分表示。如果您确实需要完整数据,则可以使用完整表示。您甚至可以拥有它,以便完整表示将部分表示嵌入其中(组合),并简单地将调用推迟(对于部分数据)。

我之前使用的另一种方法是告诉我的映射器(将实体转换为 DTO)是否需要完整数据。这样,映射器可以决定是否需要用其他数据填充 DTO。

【讨论】:

  • 在这个例子中,如果你创建一个包含其他 DTO 的 DTO 是不是没有无限循环?创建一个MovieDTO,它有ActorDTO,每个都有MovieDTO,每个都有ActorDTO,等等……当实体相互引用时,你如何创建DTO?
  • @vivin-paliath :考虑到我们在这里传递了一个嵌入式 DTO,您能否分享一个示例,说明从多个存储库/DAO 提取数据并映射到单个 DTO 的理想方式?到目前为止,我已经看到数据映射器仅采用单个存储库/实体的示例。如果我们遇到需要从多个实体构建一个 DTO 的情况,不确定如何处理。让存储库全局化以便我们可以在映射器需要时提取它们是否公平?
  • @Ayyappa 我会问一个单独的问题。
  • @VivinPaliath:如果你能回答这个问题那就太好了 - stackoverflow.com/questions/60439844/…
  • @VivinPaliath 你看过了吗?
猜你喜欢
  • 1970-01-01
  • 2013-11-20
  • 1970-01-01
  • 1970-01-01
  • 2020-04-21
  • 1970-01-01
  • 2011-10-05
  • 2020-03-21
  • 2023-04-06
相关资源
最近更新 更多