Datenübertragungen zwischen Ebenen im domänenbasierten Design
Domänenschichten kommunizieren die anderen Schichten über Datenübertragungsobjekte (DTOs). Ich habe über DTOs verwirrt.
DTO 1 befindet sich zwischen Domäne und Präsentationsschicht.
DTO 2 befindet sich zwischen der Domäne und der Datenschicht.
Soll ich zwei verschiedene DTO-Objekte zwischen Ebenen oder nur einem DTO erstellen? Welches ist der professionelle Weg?
4 Antworten
Lassen Sie uns alle Ihre Ebenen durchgehen:
- Datenzugriffsebene (DAL) . Es wird verwendet, um Daten aus der Datenbank (DB) zu erhalten.
Normalerweise kennt es Domain Entities und Domain Layer.
Die DAL kann entweder Domain Entities oder DTOs (DB oriented data structures) zurückgeben. Diese DTOs oder Domain-Entities können verwendet werden, um DTOs der Präsentationsschicht ( view models ) zu erstellen, wenn sie benötigt werden.
Domain Entities sind in der Regel schwer und erfordern Data Mapper oder ein beliebiges ORM. Ich arbeite lieber mit Domain Entities , mappe sie und vermeide andere DTOs. Ansonsten sollten DTOs auch gemappt werden.
- Domänenebene (Domänenmodell) Es wird verwendet, um Business-Entitäten und deren Verhalten, Geschäftsregeln, reine Geschäftslogik darzustellen.
Domain Layer sollte nichts über die Art und Weise wissen, wie die Entitäten irgendwo gespeichert sind (z.B. in DB). Es kann seine eigenen DTOs haben, die Ergebnisse der Refactoring Einführung von Parameter-Objekt sein können.
- Präsentationsschicht (UI) Es wird verwendet, um Benutzern die Benutzeroberfläche zu präsentieren.
Es sollte über Data Access Layer wissen, um Daten aus der DB zu laden, und über Domain Layer , um auf seine Geschäftslogik zugreifen zu können.
Es kann eigene DTOs - View-Modelle haben, die eine benutzeroberflächenfreundliche Darstellung von Domain-Entities oder DB-freundlichen DTOs darstellen. Es ist Aufgabe der Präsentationsschicht, über view models zu wissen.
Wenn Sie nur eine Präsentation haben möchten, kann Ihre Anwendungsinfrastruktur auch als Teil der Präsentationsschicht implementiert werden, aber normalerweise ist dies eine separate Anwendungsschicht.
Es hängt wirklich von Ihren speziellen Bedürfnissen ab.
Im Allgemeinen sollten Sie zwei Sätze von DTOs erstellen. Dies ermöglicht eine bessere Entkopplung verschiedener Schichten und macht die Architektur Ihres Systems flexibler. Die spezifischen Gründe oder Fälle, in denen es benötigt wird, sind zum Beispiel:
- Das Teilen von DTOs ist möglicherweise nicht möglich, z. weil es Unterschiede in den verwendeten Technologien gibt, z. Ein Webservice und eine Datenschicht werden in C # geschrieben und die Präsentationsebene wird in Java geschrieben.
- DTOs sind nicht notwendigerweise die gleichen, d. h. Ihr DTO für die Interaktion mit der Datenbankschicht kann der Datenbankstruktur nachempfunden sein, aber Sie können es anders als die Präsentationsebene verfügbar machen.
Nachdem Sie gesagt haben, dass Sie mit den Einschränkungen eines DTO-Satzes leben können, können Sie sie teilen, wenn es Ihren Anforderungen entspricht, da weniger Code zum Schreiben und Verwalten produziert wird.
Ihr Bild zeigt zwei DTO-Objekte namens DTO1 und DTO2.
DTO1 teilt Daten zwischen Präsentations- und Domian-Layer. Sie können sie als ViewModel -Klassen bezeichnen.
DTO2 teilt Daten zwischen Domäne und Datenebene. Sie können sie als Datenübertragungsobjekte ( DTOs ) aufrufen.
Sie können also zwei verschiedene Transferobjekte verwenden.
Wenn wir davon ausgehen, dass Sie zwei getrennte DTOs (DTO1 und DTO2) verwenden,
Antwort ist einfach:
Sie müssen in diesem Fall zwei separate DTO erstellen: DTO1 und DTO2.
Auch wenn sie identisch sind, sollten sie als getrennte Klassen implementiert werden.
Dies liegt daran, dass DTO1 in der Domänenebene erstellt wird, DTO2 jedoch in der Datenschicht (gemäß Ihrem Bild) erstellt wird.
Beachten Sie, dass in einigen Lösungen zwei DTOs nicht verwendet werden - manchmal gibt es nur ein DTO.
Tags und Links java c# architecture domain-driven-design dto