Designing DTOs, die Listen von Objekten

Angenommen, ich habe folgende Domain-Modelle enthalten:Designing DTOs, die Listen von Objekten

Project    Task 
    - Id     - Id 
    - Name     - Name 
    - List<Task>   - Project

Projekte viele Aufgaben haben und Aufgaben haben ein Projekt.

Angenommen, ich möchte ein TodoListDTO Datenübertragungsobjekt erstellen. Mein ursprünglicher Gedanke war, dies zu tun:

TodoListDTO 
    - List<Project>

Scheint einfach. Dann habe ich Zugriff auf die Liste der Aufgaben in jedem Projekt. Dann habe ich an mehreren Stellen gelesen, dass DTOs so flach wie möglich sein sollten. Aber wie würde ich das modellieren, ohne komplexe Objekte zu verwenden?

Statt TodoListDTO, konnte ich eine ProjectDTO haben, dass etwas wie folgt aussieht:

ProjectDTO 
    - ProjectId 
    - Name 
    - List<TaskId> 
    - List<TaskName>

aber mit getrennten Listen TaskIds und TaskNames unbequem scheint, und ich sehe nicht, wie das ist besser als nur mit Listet die Eigenschaft auf dem ProjectDTO auf.

Was ist ein guter Weg, damit umzugehen?

Quelle

2016-08-26 jrsowles

So flach wie möglich verbietet es Ihnen nicht, das Problem richtig zu modellieren. Wenn ein Projekt Aufgaben und Aufgaben ein einzelnes Projekt hat, sehe ich nichts falsch mit Ihrem ursprünglichen Entwurf. – saarrrr

Ich würde die erste bevorzugen. Modular .. Denn wenn Sie versuchen, zu einem beliebigen Zeitpunkt in Ihrer Anwendung auf eine Liste von Projekten zuzugreifen, würden Sie am Ende alle Informationen zu den darunter liegenden Aufgaben abrufen. was nicht effizient ist. – Reddy

Nun ein * Daten * ** Transport ** * Objekt * wird verwendet, um Daten zu transportieren (z. B. Import/Export von Daten in ein bestimmtes JSON/XML/.. Format). Die Modelle für EF sind ebenfalls DTOs (Transportdaten von/zur Datenbank). Was ist die Absicht der DTOs in der Frage? –

Ihre vorherigen Klassen waren einfach genug und der Standard Weg, es zu tun. Sie würden eine Context-Klasse erstellen, die eine Liste von Projekten und Aufgaben enthält. Insgesamt drei Klassen.

Quelle

2016-08-26 22:39:25

Meinst du eine Context-Klasse mit zwei separaten Listen (eine für Projekte und eine für Aufgaben) oder eine einzelne Liste von Projekten, von denen jedes seine eigene Aufgabenliste hat? – jrsowles

Ja, ich meine zwei getrennte Listen. Sie können jedoch die Aufgabenliste auslassen, wenn Ihr Szenario dies zulässt. Der Standardweg besteht darin, dass der Kontext Listen aller Entitätsklassen enthält. –

Auch, wie Matthew vorgeschlagen hat, gibt es auch eine Viele-zu-Viele-Beziehung zwischen Projekten und Aufgaben. So können Sie eine assoziative Klasse entwerfen, um damit umzugehen. –

Eine andere Sache, die Sie tun können, ist eine andere Domain-Modell von

ProjectTask 
    - ProjectId 
    - ProjectName 
    - TaskId 
    - TaskName

Das mit dem (so dass auch viele-zu-viele) one-to-many schaffen könnte Beziehung helfen und Seite die verwirrende Schritt circluar projekt- > Aufgabe-> Projekt-> Aufgabenstruktur. Von hier aus können Sie Ihren API-Client alle ProjectTasks nach projectId gruppieren und so behandeln.

Dies gesagt, ich denke, Ihre ursprüngliche Art ist in Ordnung, aber hier ist eine Alternative.

Quelle

2016-08-26 23:18:46

Designing DTOs, die Listen von Objekten

Antwort

Verwandte Themen