Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

наиболее мощным является Fluent API, но код скрыт в классе DbContext. Независимо от того, используете вы аннотации данных или Fluent API, имейте в виду, что аннотации данных переопределяют встроенные соглашения, а методы Fluent API переопределяют вообще все.

Выполнение запросов

Запросы на извлечение данных создаются посредством запросов LINQ в отношении свойств DbSet<T>. На стороне сервера механизм трансляции LINQ поставщика баз данных видоизменяет запрос LINQ с учетом специфичного для базы данных языка (скажем, Т-SQL). Запросы LINQ, охватывающие (или потенциально охватывающие) множество записей, не выполняются до тех пор, пока не начнется проход по результатам запросов (например, с применением foreach) или не произойдет привязка к элементу управления для их отображения (наподобие визуальной сетки данных). Такое отложенное выполнение позволяет строить запросы в коде, не испытывая проблем с производительностью из-за частого взаимодействия с базой данных.

Скажем, чтобы извлечь из базы данных все записи об автомобилях желтого цвета, запустите следующий запрос:

var cars = Context.Cars.Where(x=>x.Color == "Yellow");

Благодаря отложенному выполнению база данных фактически не запрашивается до тех пор, пока не начнется проход по результатам. Чтобы выполнить запрос немедленно, используйте ToList():

var cars = Context.Cars.Where(x=>x.Color == "Yellow").ToList();

Поскольку запросы не выполняются до их запуска, их можно строить в нескольких строках кода. Показанный ниже пример кода делает то же самое, что и предыдущий пример:

var query = Context.Cars.AsQueryable();

query = query.Where(x=>x.Color == "Yellow");

var cars = query.ToList();

Запросы с одной записью (как в случае применения First()/FirstOrDefault()) выполняются немедленно при вызове действия (такого как FirstOrDefault()), а операторы создания, обновления и удаления выполняются немедленно, когда запускается метод DbContext.SaveChanges().

Смешанное выполнение на клиентской и серверной сторонах

В предшествующих версиях EF Core была введена возможность смешивания выполнения на стороне сервера и на стороне клиента. Это означало, что где-то в середине оператора LINQ можно было бы вызвать функцию C# и по существу свести на нет все преимущества, описанные в предыдущем разделе. Часть до вызова функции C# выполнится на стороне сервера, но затем все результаты (в данной точке запроса) доставляются на сторону клиента и остаток запроса будет выполнен как LINQ to Objects. В итоге возможность смешанного выполнения привнесла больше проблем, нежели решила, и в выпуске EF Core 3.1 такая функциональность была изменена. Теперь выполнять на стороне клиента можно только последний узел оператора LINQ.

Сравнение отслеживаемых и неотслеживаемых запросов

При чтении информации из базы данных в экземпляр DbSet<T> сущности (по умолчанию) отслеживаются компонентом ChangeTracker, что обычно и требуется в приложении. Как только начинается отслеживание экземпляра компонентом ChangeTracker, любые последующие обращения к базе данных за тем же самым элементом (на основе первичного ключа) будут приводить к обновлению элемента, а не к его дублированию.

Однако временами из базы данных необходимо получать данные, отслеживать которые с помощью ChangeTracker нежелательно. Причина может быть связана с производительностью (отслеживание первоначальных и текущих значений для крупных наборов записей увеличивает нагрузку на память) либо же с тем фактом, что извлекаемые записи никогда не будут изменяться частью приложения, которая нуждается в этих данных.

Чтобы загрузить экземпляр DbSet<T>, не помещая данные в ChangeTracker, добавьте к оператору LINQ вызов AsNoTracking(), который указывает EF Core о необходимости извлечения данных без их помещения в ChangeTracker. Например, для загрузки записи Car без ее добавления в ChangeTracker введите следующий код:

public virtual Car? FindAsNoTracking(int id)

  => Table.AsNoTracking().FirstOrDefault(x => x.Id == id);

Преимущество показанного кода в том, что он не увеличивает нагрузку на память, но с ним связан и недостаток: дополнительные вызовы для извлечения той же самой записи Car создадут ее добавочные копии. За счет потребления большего объема памяти и чуть более длительного выполнения запрос можно модифицировать, чтобы гарантировать наличие только одного экземпляра несопоставленной сущности Car:

public virtual Car? FindAsNoTracking(int id)

  => Table.AsNoTrackingWithIdentityResolution().FirstOrDefault(x => x.Id == id);

Важные функциональные средства EF Core

Многие функциональные средства из EF 6 были воспроизведены в EF Core, а с каждым выпуском добавляются новые возможности. Множество средств в EF Core усовершенствовано как с точки зрения функциональности, так и в плане производительности. В дополнение к средствам, воспроизведенным из EF 6, инфраструктура EF Core располагает многочисленными новыми возможностями, которые в предыдущей версии отсутствовали. Ниже приведены наиболее важные функциональные средства инфраструктуры EF Core (в произвольном порядке).

На заметку! Фрагменты кода в текущем разделе взяты прямо из завершенной библиотеки доступа к данным AutoLot, которая будет построена в следующей главе.

Обработка значений, генерируемых базой данных

Помимо отслеживания изменений и генерации запросов SQL из LINQ существенным преимуществом использования EF Core по сравнению с низкоуровневой инфраструктурой ADO.NET является гладкая обработка значений, генерируемых базой данных. После добавления или обновления сущности исполняющая среда EF Core запрашивает любые данные, генерируемые базой, и автоматически обновляет сущность с применением корректных значений. При работе с низкоуровневой инфраструктурой ADO.NET это пришлось бы делать самостоятельно.

Например, таблица Inventory имеет целочисленный первичный ключ, который определяется в SQL Server как столбец Identity. Столбцы Identity заполняются СУБД SQL Server уникальными числами (из последовательности) при добавлении записи и не могут обновляться во время обычных обновлений (исключая особый случай IDENTITY_INSERT). Кроме того, таблица Inventory содержит столбец TimeStamp для проверки параллелизма. Проверка параллелизма рассматривается далее, а пока достаточно знать, что столбец TimeStamp поддерживается SQL Server и обновляется при любом действии добавления или редактирования.

В качестве примера возьмем добавление новой записи Car в таблицу Inventory. В приведенном ниже коде создается новый экземпляр Car, который добавляется к экземпляру DbSet<Car> класса, производного от DbContext, и вызывается метод SaveChanges() для сохранения данных:

var car = new Car

{

  Color = "Yellow",

  MakeId = 1,

  PetName = "Herbie"

};

Context.Cars.Add(car);

Context.SaveChanges();

При выполнении метода SaveChanges() в таблицу вставляется новая запись, после чего исполняющей среде EF Core возвращаются значения Id и TimeStamp из таблицы, причем свойства сущности обновляются надлежащим образом:

INSERT INTO [Dbo].[Inventory] ([Color], [MakeId],