.HasConstraintName("FK_CarDriver_Drivers_DriverId")

      .OnDelete(DeleteBehavior.Cascade),

    j => j

      .HasOne

      .WithMany

      .HasForeignKey("CarId")

      .HasConstraintName("FK_CarDriver_Cars_CarId")

      .OnDelete(DeleteBehavior.ClientCascade));

Соглашения, аннотации данных и Fluent API — что выбрать?

В настоящий момент вас может интересовать, какой из вариантов следует выбирать для формирования ваших сущностей, а также их связей друг с другом и с хранилищем данных? Ответ: все три. Соглашения активны всегда (если только вы не переопределите их посредством аннотаций данных или Fluent API). С помощью аннотаций данных можно делать почти все то, на что способны методы Fluent API, и хранить информацию в самом сущностном классе, повышая в ряде случаев читабельность кода и удобство его сопровождения. Из трех вариантов наиболее мощным является Fluent API, но код скрыт в классе DbContext. Независимо от того, используете вы аннотации данных или Fluent API, имейте в виду, что аннотации данных переопределяют встроенные соглашения, а методы Fluent API переопределяют вообще все.

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

Запросы на извлечение данных создаются посредством запросов LINQ в отношении свойств DbSet. На стороне сервера механизм трансляции 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 сущности (по умолчанию) отслеживаются компонентом ChangeTracker, что обычно и требуется в приложении. Как только начинается отслеживание экземпляра компонентом ChangeTracker, любые последующие обращения к базе данных за тем же самым элементом (на основе первичного ключа) будут приводить к обновлению элемента, а не к его дублированию.