Язык программирования C#9 и платформа .NET5

К счастью, многие современные СУБД оснащены инструментами, которые помогают разработчикам решать проблемы с параллелизмом. В SQL Server имеется встроенный тип данных под названием timestamp — синоним для rowversion. Если столбец определен с типом данных timestamp, то при добавлении записи в базу данных значение для этого столбца создается СУБД SQL Server, а при обновлении записи значение столбца тоже обновляется. Фактически гарантируется, что значение будет уникальным и управляться СУБД SQL Server.

В EF Core можно задействовать тип данных timestamp из SQL Server, реализуя внутри сущности свойство TimeStamp (представляемое в C# как byte[]). Свойства сущностей, определенные с применением атрибута TimeStamp либо Fluent API, предназначены для добавления в конструкцию where при обновлении или удалении записей. Вместо того чтобы просто использовать значение (значения) первичного ключа, в конструкцию where генерируемого оператора SQL добавляется значение свойства timestamp, что ограничивает результаты записями, у которых совпадают значения первичного ключа и отметки времени. Если запись была обновлена другим пользователем (или системой), тогда значения отметок времени не совпадут, так что оператор update не обновит, а оператор delete не удалит запись. Вот пример запроса обновления, в котором применяется столбец TimeStamp:

 UPDATE [Dbo].[Inventory] SET [Color] = N'Yellow'
 WHERE [Id] = 1 AND [TimeStamp] = 0x000000000000081F;

Когда хранилище сообщает о количестве затронутых записей, отличающемся от количества записей, изменения которых ожидает ChangeTracker, исполняющая среда EF Core генерирует исключение DbUpdateConcurrencyException и выполняет откат всей транзакции. Экземпляр DbUpdateConcurrencyException содержит информацию о записях, которые не были сохранены, куда входят первоначальные значения (полученные в результате загрузки из базы данных) и текущие значения (после их обновления пользователем/системой). Кроме того, существует метод для получения текущих значений в базе данных (требующий еще одного обращения к серверу). Располагая настолько большим количеством информации, разработчик затем может обработать ошибку параллелизма так, как того требует приложение. Ниже приведен пример:

 try
 {
  // Получить запись для автомобиля (неважно какую).
  var car = Context.Cars.First;
  // Обновить базу данных извне контекста.

Context.Database.ExecuteSqlInterpolated($"Update dbo.Inventory set Color='Pink' where Id = {car.Id}");

  // Обновить запись для автомобиля в ChangeTracker
  // и попробовать сохранить изменения.
  car.Color = "Yellow";
  Context.SaveChanges;
 }
 catch (DbUpdateConcurrencyException ex)
 {
  // Получить сущность, которую не удалось обновить.
  var entry = ex.Entries[0];
  /// Получить первоначальные значения (когда сущность была загружена).
  PropertyValues originalProps = entry.OriginalValues;
  // Получить текущие значения (обновленные кодом выше).
  PropertyValues currentProps = entry.CurrentValues;
  // Получить текущие значения из хранилища данных.
  // Примечание: это требует еще одного обращения к базе данных
  //PropertyValues databaseProps = entry.GetDatabaseValues;
 }

Устойчивость подключений

Кратковременные ошибки трудны в отладке и еще более трудны в воспроизведении. К счастью, многие поставщики баз данных имеют внутренний механизм повтора для сбоев в системе баз данных (проблемы с tempdb, ограничения пользователей и т.д.), который может быть задействован EF Core. Для SQL Server кратковременные ошибки (согласно определению команды разработчиков СУБД) перехватываются экземпляром класса SqlServerRetryingExecutionStrategy, и если он включен в объекте производного от DbContext класса через DbContextOptions, то EF Core автоматически повторяет операцию до тех пор, пока не достигнет максимального предела повторов.

При работе с SQL Server доступен сокращенный метод, который можно использовать для включения SqlServerRetryingExecutionStrategy со всеми стандартными параметрами. Метод, который применяется с SqlServerOptions — это EnableRetryOnFailure:

 public ApplicationDbContext CreateDbContext(string[] args)
 {
  var optionsBuilder = new DbContextOptionsBuilder<ApplicationDbContext>;
  var connectionString = @"server=.,5433;Database=AutoLot50;
  User Id=sa;Password=P@ssw0rd;";
  optionsBuilder.UseSqlServer(connectionString,
   options => options.EnableRetryOnFailure);
  return new ApplicationDbContext(optionsBuilder.Options);

Максимальное количество повторов и предельное время между повторами можно конфигурировать в зависимости от требований приложения. Если предел повторов достигается без завершения операции, тогда EF Core уведомит приложение о проблемах с подключением путем генерации RetryLimitExceededException. В случае обработки это исключение способно передавать необходимую информацию пользователю, обеспечивая лучший отклик:

 try
 {
  Context.SaveChanges;
 }
 catch (RetryLimitExceededException ex)
 {
  // Превышен предел повторов.
  // Требуется интеллектуальная обработка.
  Console.WriteLine($"Retry limit exceeded! {ex.Message}");
 }

Для поставщиков баз данных, которые не предлагают встроенной стратегии выполнения, можно создавать специальную стратегию выполнения. Дополнительные сведения ищите в документации по EF Core: https://docs.microsoft.com/ru-ru/ef/core/miscellaneous/connection-resiliency.

Связанные данные

Навигационные свойства сущности используются для загрузки связанных данных сущности. Связанные данные можно загружать энергичным образом (один оператор LINQ, один запрос SQL), энергичным образом с разделением запросов (один оператор LINQ, множество запросов SQL), явным образом (множество вызовов LINQ, множество запросов SQL) или ленивым образом (один оператор LINQ, множество запросов SQL по требованию).

Помимо возможности загрузки связанных данных с применением навигационных свойств исполняющая среда EF Core будет автоматически приводить в порядок сущности по мере их загрузки в ChangeTracker. В качестве примера предположим, что все записи Make загружаются в DbSet<Make>, после чего все записи Car загружаются в DbSet<Car>. Несмотря на то что записи загружались по отдельности, они будут доступны друг другу через навигационные свойства.

Энергичная загрузка

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