C'est à toi de decider.
La plupart des gens vous diront que ce n'est pas une bonne pratique mais vous pouvez vous en tirer dans certains cas.
EF n'a jamais bien joué avec DDD pour plusieurs raisons, mais deux se distinguent: vous ne pouvez pas avoir de constructeurs paramétrés sur vos entités et vous ne pouvez pas encapsuler des collections. DDD s'appuie sur cela, car le modèle de domaine doit inclure à la fois les données et le comportement.
D'une certaine manière, EF vous oblige à avoir un modèle de domaine anémique et dans ce cas, vous pouvez utiliser les entités en tant que DTO. Vous pouvez rencontrer certains problèmes si vous utilisez des propriétés de navigation, mais vous pouvez sérialiser ces entités et les envoyer par câble. Ce n'est peut-être pas pratique cependant. Vous devrez contrôler la sérialisation de chaque entité qui possède des propriétés que vous n'avez pas besoin d'envoyer. Le moyen le plus simple consiste à concevoir simplement des classes distinctes adaptées au transfert de données. Des bibliothèques comme AutoMapper sont créées à cet effet.
Par exemple: supposons que vous ayez une classe appelée Personavec la définition suivante:
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
}
En supposant que vous souhaitiez afficher une liste d'employés quelque part, il peut être pratique d'envoyer uniquement le Id, FirstNameet LastName. Mais vous devrez envoyer toutes les autres propriétés non pertinentes. Ce n'est pas un gros problème si vous ne vous souciez pas de la taille de la réponse, mais l'idée générale est d'envoyer uniquement les données pertinentes. D'un autre côté, vous pouvez concevoir une API qui renvoie une liste de personnes et, dans ce cas, l'envoi de toutes les propriétés peut être nécessaire, il est donc judicieux de sérialiser et d'envoyer les entités. Dans ce cas, la création d'une classe DTO est discutable. Certaines personnes aiment mélanger les entités et les DTO, d'autres non.
Pour répondre à votre question mise à jour, EF est un ORM. Son travail consiste à mapper des enregistrements de base de données à des objets et vice versa. Ce que vous faites avec ces objets avant et après avoir traversé EF ne fait pas partie de ses préoccupations. Cela ne devrait pas non plus.