SELECT [i].[Id], [i].[Color], [i].[IsDrivable],
[i].[MakeId], [i].[PetName], [i].[TimeStamp]
FROM [Dbo].[Inventory] AS [i]
WHERE ([i].[IsDrivable] = CAST(1 AS bit)) AND ([i].[MakeId] = 1
С игнорированием фильтров запросов при явной загрузке данных связана небольшая загвоздка. Возвращаемым типом метода Collection является CollectionEntry, который явно не реализует интерфейс IQueryable. Чтобы вызвать IgnoreQueryFilters, сначала потребуется вызвать метод Query, который возвращает экземпляр реализации IQueryable:
var make = Context.Makes.First(x => x.Id == makeId);
Context.Entry(make).Collection(c=>c.Cars).Query.IgnoreQueryFilters.Load;
Тот же процесс применяется в случае использования метода Reference для извлечения данных из навигационного свойства типа коллекции.
Иногда получить корректный оператор LINQ для компилируемого запроса сложнее, чем просто написать код SQL напрямую. К счастью, инфраструктура EF Core располагает механизмом, позволяющим выполнять низкоуровневые операторы SQL в DbSet. Методы FromSqlRaw и FromSqlRawInterpolated принимают строку, которая становится основой запроса LINQ. Такой запрос выполняется на стороне сервера.
Если низкоуровневый оператор SQL не является завершающим (скажем, хранимой процедурой, пользовательской функцией или оператором, который использует общее табличное выражение или заканчивается точкой с запятой), тогда в запрос можно добавить дополнительные операторы LINQ. Дополнительные операторы LINQ наподобие конструкций Include, OrderBy или Where будут объединены с первоначальным низкоуровневым обращением SQL и любыми глобальными фильтрами запросов, после чего весь запрос выполнится на стороне сервера.
При использовании одного из вариантов FromSql* запрос должен формироваться с использованием схемы базы данных и имени таблицы, а не имен сущностей. Метод FromSqlRaw отправит строку в том виде, в каком она записана. Метод FromSqlInterpolated применяет интерполяцию строк C# и каждая интерполированная строка транслируется в параметр SQL. В случае использования переменных вы должны использовать версию с интерполяцией для обеспечения дополнительной защиты, присущей параметризованным запросам.
Предположим, что для сущности Car установлен глобальный фильтр запросов. Тогда показанный ниже оператор LINQ получит первую запись Inventory со значением Id, равным 1, включит связанные данные Make и отфильтрует записи, касающиеся неуправляемых автомобилей:
var car = Context.Cars
.FromSqlInterpolated($"Select * from dbo.Inventory where Id = {carId}")
.Include(x => x.MakeNavigation)
.First;
Механизм трансляции LINQ to SQL объединяет низкоуровневый оператор SQL с остальными операторами LINQ и выполняют следующий запрос:
SELECT TOP(1) [c].[Id], [c].[Color], [c].[IsDrivable], [c].[MakeId],
[c].[PetName], [c].[TimeStamp],
[m].[Id], [m].[Name], [m].[TimeStamp]
FROM (Select * from dbo.Inventory where Id = 1) AS [c]
INNER JOIN [dbo].[Makes] AS [m] ON [c].[MakeId] = [m].[Id]
WHERE [c].[IsDrivable] = CAST(1 AS bit)
Имейте в виду, что есть несколько правил, которые необходимо соблюдать в случае применения низкоуровневых запросов SQL с LINQ.
• Запрос SQL должен возвращать данные для всех свойств сущностного типа.
• Имена столбцов должны совпадать с именами свойств, с которыми они сопоставляются (улучшение по сравнению с версией EF 6, где сопоставления игнорировались).
• Запрос SQL не может содержать связанные данные.
В EF Core значительно повышена производительность при сохранении изменений в базе данных за счет выполнения операторов в одном и более пакетов. В итоге объем взаимодействия между приложением и базой данных уменьшается, увеличивая производительность и потенциально сокращая затраты (скажем, для облачных баз данных, где за транзакции приходится платить).
