.HasColumnType("nvarchar(50)");

      pd.Property(p => p.FullName)

           .HasColumnName(nameof(Person.FullName))

           .HasComputedColumnSql("[LastName] + ', ' + [FirstName]");

    });

});

Сущность Customer

Следующим обновляется блок для сущности Customer. Здесь удаляется код для TimeStamp и конфигурируются свойства принадлежащего сущностного класса:

modelBuilder.Entity(entity =>

{

  entity.OwnsOne(o => o.PersonalInformation,

 pd =>

  {

    pd.Property(p => p.FirstName).HasColumnName(nameof(Person.FirstName));

    pd.Property(p => p.LastName).HasColumnName(nameof(Person.LastName));

    pd.Property(p => p.FullName)

      .HasColumnName(nameof(Person.FullName))

      .HasComputedColumnSql("[LastName] + ', ' + [FirstName]");

   });

});

Сущность Make

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

modelBuilder.Entity(entity =>

{

  entity.HasMany(e => e.Cars)

      .WithOne(c => c.MakeNavigation!)

      .HasForeignKey(k => k.MakeId)

      .OnDelete(DeleteBehavior.Restrict)

      .HasConstraintName("FK_Make_Inventory");

});

Сущность Order

Для сущности Order обновите имена навигационных свойств и добавьте утверждение, что обратные навигационные свойства не равны null. Вместо ограничения удалений отношение Customer с Order настраивается на каскадное удаление:

modelBuilder.Entity(entity =>

{

  entity.HasOne(d => d.CarNavigation)

     .WithMany(p => p!.Orders)

     .HasForeignKey(d => d.CarId)

     .OnDelete(DeleteBehavior.ClientSetNull)

     .HasConstraintName("FK_Orders_Inventory");

  entity.HasOne(d => d.CustomerNavigation)

     .WithMany(p => p!.Orders)

     .HasForeignKey(d => d.CustomerId)

     .OnDelete(DeleteBehavior.Cascade)

     .HasConstraintName("FK_Orders_Customers");

});

Настройте фильтр для свойства CarNavigation сущности Order, чтобы отфильтровывать неуправляемые автомобили. Обратите внимание, что этот код находится не в том же блоке, где был предыдущий код. Никаких формальных причин разносить код не существует; просто здесь демонстрируется альтернативный синтаксис для конфигурирования в отдельных блоках:

modelBuilder.Entity.HasQueryFilter(e => e.CarNavigation!.IsDrivable);

Сущность Car

Шаблонный класс содержит конфигурацию для класса Inventory, который понадобится изменить на Car. Свойство TimeStamp нужно удалить, а в конфигурации навигационных свойств изменить имена свойств на MakeNavigation и Cars. Сущность получает фильтр запросов для отображения по умолчанию только управляемых автомобилей и устанавливает стандартное значение свойства IsDrivable в true. Код должен иметь следующий вид:

modelBuilder.Entity(entity =>

{

  entity.HasQueryFilter(c => c.IsDrivable);

  entity.Property(p

    => p.IsDrivable).HasField("_isDrivable").HasDefaultValue(true);

  entity.HasOne(d => d.MakeNavigation)

    .WithMany(p => p.Cars)

    .HasForeignKey(d => d.MakeId)

    .OnDelete(DeleteBehavior.ClientSetNull)

    .HasConstraintName("FK_Make_Inventory");

});

Специальные исключения

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