EF Core 8 не объединяет объекты

Это кажется странным. На первый взгляд похоже, что вы можете столкнуться с проблемой: в первом случае, когда вы загружаете документ как часть задачи, не загружая также тип документа и компоненты, тогда, возможно, средство отслеживания изменений EF могло вернуть этот отслеживаемый документ и проигнорировать. загрузка DocumentType и компонентов в соответствии с запросом во втором запросе...

Тем не менее, я создаю тест для проверки этого конкретного сценария, и EF по-прежнему активно загружает запрошенные данные во втором запросе.

В моем тестовом примере у меня была связь «Родитель->Дети->Комментарий», в которой я сначала запрашивал конкретного родителя и его детей, не загружая комментарии, а затем загружал дочерний элемент с его комментариями, которые были загружены. Я подозревал, что EF мог предоставить отслеживаемый дочерний элемент, поскольку он был загружен из первого запроса, без дальнейшей обработки Include, однако он перезагрузил дочерний элемент и связанный с ним комментарий.

var test = context.Parents
    .Include(x => x.Children)
    .Single(x => x.ParentId == 1); // No comment loaded.
var test2 = context.Children
    .Include(x => x.Comment)
    .First(x => x.ChildId == 1); // a child from parent #1

Если все, что вам нужно, это использовать DocumentId, было бы лучше просто спроецировать его и вообще избегать загрузки каких-либо объектов в кэш отслеживания:

var documentId = await _context.Tasks
    .where(t => t.Id == taskId)
    .Select(t => t.Document.ParentDocumentId.HasValue
         ? t.Document.ParentDocumentId.Value 
         : t.Document.Id)
    .SingleAsync();

Похоже, это решит вашу проблему, но это не объясняет, почему ваш второй запрос не загружает связанные данные, если этот документ загружается с готовностью.

Если это операция только для чтения, когда вы не вносите изменения в документ, вы можете попробовать добавить .AsNoTracking() ко второму запросу с исходным первым запросом и посмотреть, изменится ли это что-нибудь. Если второй запрос работает с AsNoTracking, то ваш конкретный сценарий, похоже, сбивается с толку трекером изменений EF, и, возможно, стоит посмотреть на объявление вашей конкретной сущности на случай, если вы делаете что-то «любопытное», которое могло бы это объяснить. Если это все еще терпит неудачу с AsNoTracking, то я очень подозреваю, что в конфигурации/реализации вашего объекта есть что-то странное.

Одним из виновников, который следует проверить, является то, как объявляются ваши свойства навигации, чтобы убедиться, что они остаются простыми и понятными, без «умной» логики, особенно с коллекциями. Например:

// Document.DocumentType:

public virtual DocumentType DocumentType { get; protected set; }  

// DocumentType.Components:

public virtual ICollection<Component> Components { get; protected set; } = []; // or new List<Component>();

В идеале установщики свойств навигации должны быть защищены, если только вы не хотите разрешить изменение значений. Установщики свойств навигации по коллекции всегда должны быть защищены, поскольку код никогда не должен повторно инициализировать их после того, как EF их установит. Если у вас есть код, который использует частные члены и условную логику в методах получения/установки для свойств навигации по коллекции, это может помешать использованию EF этих свойств.