Data Transfer Objects of entities with M:N or 1:N relationships

Question

I have 2 entities - movie and actor - that have M:N relationship. When designing DTO objects for these entities I am not sure what's the correct way to go.

Movie

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

    private String name;
    private String short_info;    

    @ManyToMany
    private Map<String, Actor> cast;

}

Actor

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

    private String name;

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

}

Now concerning the DTOs: I've come across two different ways how to deal with 1:N and M:N relationships.

Saving only IDs:

public class MovieDto {    

    private String name;
    private String short_info;    

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

}

However as said here I thought that Instead of performing many remote calls on EJBs, the idea was to encapsulate data in a value object, and this approach clearly breaks the rule.

Saving DTOs in DTOs: Another approach would be to store Actor's Dto, instead of its ID.

public class MovieDto {    

    private String name;
    private String short_info;

    private Map<String, ActorDto> cast;

}

It seems to me that this approach would be faster, as I don't have to call the database everytime I need to show actor's name for example.

Is this assumption correct, or would it be better to store only IDs (even considering the space consumption of the second approach)?

Plus the second approach would result in a number of DTOs for one Entity. For instance, I don't need to know what movies has actor played in when looking at a "movie page", but I need to it when looking at an "actor page".

Answer 1

It is perfectly acceptable to embed other DTO instances inside a parent DTO. Of course, this can get prohibitive if the object ends up being extremely large. So this is where you have to make some kind of tradeoff.

One way to get around this is to have a partial representation and a full representation. In cases where you don't need the complete data, you can use the partial representation. In cases where you do need the full data, you can use the full representation. You can even have it so that the full representation embeds the partial representation inside it (composition) and simply defers calls to that (for the partial data).

Another approach I have used before is to tell my mapper (that converts the entity to the DTO) if I need the full data. This way the mapper can decide if the DTO needs to be populated with additional data.