Ich habe das folgende Domänenmodell:
%Vor%Mein Dienst hat den folgenden Code:
%Vor%Mein Dienst ruft eine Wiedergabeliste und Titel aus der Datenbank ab und löst dann für jeden Titel in der Wiedergabeliste eine Abfrage aus, um zusätzliche Übereinstimmungen aus der Datenbank (mit SQL Server-Volltextsuche) zu erhalten, die für diesen Titel spezifisch sind.
Die Daten werden dann in DTOs konvertiert, zu einem Ergebnisobjekt hinzugefügt und an den Controller zurückgegeben. Der Code sieht folgendermaßen aus:
%Vor%Das Problem:
Das PlaylistResult-Objekt hat bisher sehr gut funktioniert, aber die kürzliche Einführung von Matches hat die Dinge ein wenig komplizierter gemacht. Es sieht so aus, als hätte ich keine andere Wahl, als mein SongDTO so zu modifizieren, dass es Übereinstimmungen berücksichtigt und wie folgt aussieht:
%Vor%Aber verletzt das nicht den Zweck von DTO's? Es ist mein Verständnis, dass DTOs eine abgeflachte Darstellung von Daten sind und dieser Ansatz nicht abgeflacht ist. Auf der anderen Seite sehe ich nicht, wie ich das sonst machen könnte, da jede Übereinstimmung für jeden Song spezifisch ist.
Ich bin mir bewusst, dass ich es mir selbst leichter machen und die DTOs wegwerfen und das Domain-Modell direkt an den Controller übergeben und es einen Tag nennen könnte. Aber ich möchte das nicht tun, da der ganze Zweck darin besteht, zu lernen, wie man mit DTOs arbeitet.
Jede Eingabe wird sehr geschätzt.
DTOs sind keine abgeflachte Darstellung von Daten, obwohl sie es sein können.
Das ist die Schönheit von ihnen - Sie können sie so strukturieren, wie Sie es brauchen, im Gegensatz dazu, wie die Datenbank Dinge definiert. Sie sind auch ein Mittel, um Daten vom Verhalten zu trennen.
Ich würde keinen Verweis auf das Domain-Objekt innerhalb des DTO geben. (Sie haben es im Konstruktor) Verwenden Sie eine Factory, um die DTOs zu erstellen, sodass Ihre Clients nur die DTOs und nicht die Domain-Objekte referenzieren müssen.
%Vor%Wenn Ihre Clients auf die Domain-Objekte verweisen müssen, können sie sie auch verwenden!