Тобі вирішувати.
Більшість людей скажуть вам, що це не є хорошою практикою, але ви можете піти з нею в деяких випадках.
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, не є частиною його занепокоєння. Не повинно бути.