Методы, вызываемые в лямбда-запросе, выполняются на стороне ядра. Net, а не на стороне SQL

Question

У меня есть этот лямбда-запрос.

var d = await dbset
    .Select(a => new ItemDto
    {
        Id = a.Id,
        Active = a.isActive()
    })
    .ToListAsync();

isActive определяется в объекте dbset как (State, StartDate и StopDate - все свойства объекта):

public bool isActive()
{
    return isActive(State, StartDate, StopDate);
}

public static bool isActive(State state, DateTimeOffset? startDate, DateTimeOffset? stopDate)
{
   return
     state == State.Active
     && stopDate >= DateTimeOffset.UtcNow
     && startDate <= DateTimeOffset.UtcNow;
}

В старой структуре Entity это не удалось бы из-за облака дыма и неприятной ошибки, на отслеживание которой потребовались бы годы .. в новом EF Core 3.1 это работает нормально, и я могу отлаживать isActive и пошагово через них, когда они вызываются из запроса asyn c.

Это говорит мне, что они выполняются на стороне C # /. Net, а не транслируются в SQL (что старая структура Entity пыталась бы сделать).

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

Answer 1

Если кто-то еще столкнется с этим и подумает: «Отлично, это решит все мои проблемы». Это не так.

Я сидел с SSMS и отлаживал запросы в течение последнего часа или около того, чтобы выяснить, что на самом деле отправляется на SQL. И так же, как @poke сказал в комментарии. Он обрабатывает оба случая, но когда он встречает запрос, подобный тому, который я писал выше, он получает ВСЕ. Не только дополнительные поля, которые используются в методе, но и все поля объекта. Таким образом, хотя это скрывает проблему и позволяет вам написать любой запрос, который вы хотите, как только этот запрос попадет в реальные данные, он перестанет работать.

Я думаю, что предпочитаю старый способ EF для этого (ie совсем нет), хотя было бы неплохо с лучшими сообщениями об ошибках. Или даже лучше вариант при настройке EF Core, который позволяет вам «разрешать» эти запросы или отключать их и получать сообщение об ошибке, чтобы вы не могли сделать их по ошибке.