Это тебе решать.
Большинство людей скажут вам, что это не очень хорошая практика, но в некоторых случаях вы можете сойти с рук.
EF никогда не играл хорошо с DDD по нескольким причинам, но выделяются две: у вас не может быть параметризованных конструкторов на ваших сущностях, и вы не можете инкапсулировать коллекции. DDD полагается на это, поскольку модель предметной области должна включать как данные, так и поведение.
В некотором смысле, EF вынуждает вас иметь анемичную модель предметной области, и в этом случае вы можете использовать сущности в качестве DTO. Вы можете столкнуться с некоторыми проблемами, если используете свойства навигации, но можете сериализовать эти объекты и отправить их по проводам. Это может быть не практично, хотя. Вам придется контролировать сериализацию для каждой сущности, свойства которой вам не нужно отправлять. Более простой способ - просто разработать отдельные классы, специально предназначенные для передачи данных. Библиотеки, такие как AutoMapper , созданы для этой цели.
Например: предположим, у вас есть класс, вызываемый Personсо следующим определением:
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
}
Предполагая, что вы хотите отобразить список сотрудников где-то, может быть целесообразно отправить только Id, FirstNameи LastName. Но вам придется отправить все остальные не относящиеся к делу свойства. Это не такая уж большая проблема, если вам не важен размер ответа, но общая идея - отправлять только соответствующие данные. С другой стороны, вы можете разработать API, который возвращает список людей, и в этом случае может потребоваться отправка всех свойств, что имеет смысл сериализовать и отправлять сущности. В этом случае создание класса DTO является дискуссионным. Некоторые люди любят смешивать сущности и DTO, некоторые нет.
Чтобы ответить на ваш обновленный вопрос, EF - ORM. Его работа заключается в сопоставлении записей базы данных с объектами и наоборот. То, что вы делаете с этими объектами до и после прохождения EF, не является частью его забот. И не должно быть.