Datenübertragungsobjekte von Entitäten mit M: N oder 1: N Beziehungen

Question

Ich habe 2 Entitäten - Film und Schauspieler - die eine M: N Beziehung haben. Wenn ich DTO-Objekte für diese Entitäten entwerfe, bin ich nicht sicher, was der richtige Weg ist.

Film

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

    private String name; 
    private String short_info;  

    @ManyToMany 
    private Map<String, Actor> cast; 

} 

Schauspieler

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

    private String name; 

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

} 

nun die DTOs über: ich auf zwei verschiedene Arten gekommen sind, wie man mit 1 beschäftigen: N und M: N-Beziehungen .

Speichern nur IDs:

public class MovieDto {  

    private String name; 
    private String short_info;  

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

} 

jedoch als here sagte ich dachte, dass Instead of performing many remote calls on EJBs, the idea was to encapsulate data in a value object, und dieser Ansatz bricht eindeutig die Regel.

Speichern von DTOs in DTOs: Ein anderer Ansatz wäre, Actors Dto statt seiner ID zu speichern.

public class MovieDto {  

    private String name; 
    private String short_info; 

    private Map<String, ActorDto> cast; 

} 

Es scheint mir, dass dieser Ansatz schneller sein würde, wie ich die Datenbank jedes Mal nicht aufrufen muss ich brauche zum Beispiel Schauspieler Namen zu zeigen.

Ist diese Annahme korrekt, oder wäre es besser, nur IDs zu speichern (selbst wenn der Platzverbrauch des zweiten Ansatzes berücksichtigt wird)?

Außerdem würde der zweite Ansatz zu einer Anzahl von DTOs für eine Entität führen. Zum Beispiel muss ich nicht wissen, in welchen Filmen Schauspieler auf einer "Filmseite" gespielt haben, aber ich muss darauf achten, wenn ich auf eine "Schauspieler-Seite" schaue.

Answer 1

Es ist vollkommen akzeptabel, andere DTO-Instanzen in einem übergeordneten DTO einzubetten. Natürlich kann dies prohibitiv werden, wenn das Objekt extrem groß wird. Also müssen Sie hier einen Kompromiss eingehen.

Eine Möglichkeit, dies zu umgehen, ist eine Teildarstellung und eine vollständige Darstellung. In Fällen, in denen Sie nicht die vollständigen Daten benötigen, können Sie die Teildarstellung verwenden. In Fällen, in denen Sie die vollständigen Daten benötigen, können Sie die vollständige Darstellung verwenden. Sie können es sogar so einrichten, dass die vollständige Darstellung die partielle Darstellung darin einbettet (Komposition) und Aufrufe an diese (für die Teildaten) einfach verzögert.

Ein anderer Ansatz, den ich zuvor verwendet habe, ist, meinem Mapper (der die Entität in den DTO konvertiert) zu sagen, ob ich die vollständigen Daten benötige. Auf diese Weise kann der Mapper entscheiden, ob das DTO mit zusätzlichen Daten gefüllt werden muss.