Es liegt an dir.
Die meisten Leute werden Ihnen sagen, dass es keine gute Praxis ist, aber Sie können in einigen Fällen damit durchkommen.
EF hat aus mehreren Gründen nie gut mit DDD gespielt, aber zwei stechen heraus: Sie können keine parametrisierten Konstruktoren für Ihre Entitäten haben und Sie können keine Sammlungen einkapseln. DDD stützt sich darauf, da das Domänenmodell sowohl Daten als auch Verhalten enthalten sollte.
In gewisser Weise zwingt EF Sie zu einem anämischen Domänenmodell, und in diesem Fall können Sie die Entitäten als DTOs verwenden. Einige Probleme können auftreten, wenn Sie Navigationseigenschaften verwenden, aber Sie können diese Entitäten serialisieren und über das Netzwerk senden. Es kann jedoch nicht praktisch sein. Sie müssen die Serialisierung für jede Entität steuern, die Eigenschaften hat, die Sie nicht senden müssen. Der einfachere Weg besteht darin, separate Klassen zu entwerfen, die auf die Datenübertragung zugeschnitten sind. Zu diesem Zweck werden Bibliotheken wie AutoMapper erstellt.
Beispiel: Angenommen, Sie haben eine Klasse Personmit der folgenden Definition aufgerufen :
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime DateOfBirth { get; get; }
// plus a bunch of other properties relevant about a person
}
Angenommen, Sie möchten irgendwo eine Liste der Mitarbeiter anzeigen, ist es möglicherweise sinnvoll, nur die Zeichen Id, FirstNameund zu senden LastName. Aber Sie müssen alle anderen irrelevanten Eigenschaften übermitteln. Es ist kein so großes Problem, wenn Sie sich nicht für die Größe der Antwort interessieren, aber die allgemeine Idee ist, nur die relevanten Daten zu senden. Auf der anderen Seite können Sie eine API entwerfen, die eine Liste von Personen zurückgibt. In diesem Fall ist möglicherweise das Senden aller Eigenschaften erforderlich. Daher ist es sinnvoll, die Entitäten zu serialisieren und zu senden. In diesem Fall ist das Erstellen einer DTO-Klasse umstritten. Manche Leute mögen es, Entities und DTOs zu verwechseln, andere nicht.
Um Ihre aktualisierte Frage zu beantworten, ist EF ein ORM. Seine Aufgabe besteht darin, Datenbankdatensätze Objekten zuzuordnen und umgekehrt. Was Sie mit diesen Objekten vor und nach dem Durchlaufen von EF tun, gehört nicht zu ihren Anliegen. Das sollte es auch nicht sein.