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

В EF Core доступны две схемы сопоставления классов с таблицами: "таблица на иерархию" (table-per-hierarchy — ТРН) и "таблица на тип" (table-per-type — ТРТ). Сопоставление ТРН используется по умолчанию и отображает иерархию наследования на единственную таблицу. Появившееся в версии EF Core 5 сопоставление ТРТ отображает каждый класс в иерархии на собственную таблицу.

На заметку! Классы также можно отображать на представления и низкоуровневые запросы SQL. Они называются типами запросов и обсуждаются позже в главе.

Сопоставление "таблица на иерархию" (ТРН)

Рассмотрим приведенный ниже пример, в котором класс

Car

Id

TimeStamp

Car

Models

AutoLot.Samples

using System.Collections.Generic;

namespace AutoLot.Samples.Models

{

  public abstract class BaseEntity

  {

   public int Id { get; set; }

   public byte[] TimeStamp { get; set; }

  }

}

using System.Collections.Generic;

namespace AutoLot.Samples.Models

{

  public class Car : BaseEntity

  {

   public string Color { get; set; }

   public string PetName { get; set; }

   public int MakeId { get; set; }

  }

}

Чтобы уведомить EF Core о том, что сущностный класс является частью объектной модели, предусмотрите свойство

DbSet

ApplicationDbContext

using

using AutoLot.Samples.Models;

Поместите следующий код в класс

ApplicationDbContext

OnModelCreating()

public DbSet Cars { get; set; }

Обратите внимание, что базовый класс не добавляется в виде экземпляра

DbSet

Cars

AutoLot.Samples

dotnet tool install --global dotnet-ef --version 5.0.1

dotnet ef migrations add TPH

 -o Migrations

 -c AutoLot.Samples.ApplicationDbContext

dotnet ef database update TPH  -c AutoLot.Samples.ApplicationDbContext

Первая команда устанавливает инструменты командной строки EF Core как глобальные. На вашей машине это понадобится сделать только раз. Вторая команда создает в папке

Migrations

ApplicationDbContext

AutoLot.Samples

Когда EF Core используется для создания этой таблицы в базе данных, то унаследованный класс

BaseEntity

Car

CREATE TABLE [dbo].[Cars](

  [Id] [int] IDENTITY(1,1) NOT NULL,

  [MakeId] [int] NOT NULL,

  [Color] [nvarchar](max) NULL,

  [PetName] [nvarchar](max) NULL,

  [TimeStamp] [varbinary](max) NULL,

 CONSTRAINT [PK_Cars] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON,

 ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

В предыдущем примере для создания свойств таблицы и столбцов применялись соглашения EF Core (раскрываемые вскоре).

Сопоставление "таблица на тип" (ТРТ)

Для изучения схемы сопоставления ТРТ можно использовать те же самые сущности, что и ранее, даже если базовый класс помечен как абстрактный. Поскольку схема TPH применяется по умолчанию, инфраструктуру EF Core необходимо проинструктировать для отображения каждого класса на таблицу, что можно сделать с помощью аннотаций данных или Fluent API. Добавьте в

ApplicationDbContext

protected override void OnModelCreating(ModelBuilder modelBuilder)

{

  modelBuilder.Entity().ToTable("BaseEntities");

  modelBuilder.Entity().ToTable("Cars");

  OnModelCreatingPartial(modelBuilder);

}

partial void OnModelCreatingPartial(ModelBuilder modelBuilder);

Чтобы "сбросить" базу данных и проект, удалите папку

Migrations

dotnet ef database drop -f -c AutoLot.Samples.ApplicationDbContext

Теперь создайте и примените миграцию для схемы ТРТ:

dotnet ef migrations add TPT -o Migrations -c AutoLot.Samples.ApplicationDbContext

dotnet ef database update TPT  -c AutoLot.Samples.ApplicationDbContext

При обновлении базы данных исполняющая среда EF Core создаст следующие таблицы. Индексы также показывают, что таблицы имеют сопоставление "один к одному":

CREATE TABLE [dbo].[BaseEntities](

  [Id] [int] IDENTITY(1,1) NOT NULL,

  [TimeStamp] [varbinary](max) NULL,

 CONSTRAINT [PK_BaseEntities] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

CREATE TABLE [dbo].[Inventory](

  [Id] [int] NOT NULL,

  [MakeId] [int] NOT NULL,

  [Color] [nvarchar](max) NULL,

  [PetName] [nvarchar](max) NULL,

 CONSTRAINT [PK_Inventory] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,

 ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

ALTER TABLE [dbo].[Inventory]

WITH CHECK ADD  CONSTRAINT [FK_Inventory_BaseEntities_Id] 

FOREIGN KEY([Id])

REFERENCES [dbo].[BaseEntities] ([Id])

GO

ALTER TABLE [dbo].[Inventory] CHECK CONSTRAINT [FK_Inventory_BaseEntities_Id]

GO

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

https://docs.microsoft.com/ru-ru/ef/core/performance/modeling-for-performance#inheritance-mapping

Чтобы "сбросить" базу данных и проект для подготовки к следующему набору примеров, закомментируйте код в методе

OnModelCreating()

Migrations

dotnet ef database drop -f -c AutoLot.Samples.ApplicationDbContext

Навигационные свойства представляют то, каким образом сущностные классы связаны между собой, и позволяют проходить от одного экземпляра сущности к другому. По определению навигационным является любое свойство, которое отображается на нескалярный тип, как определено поставщиком базы данных. На практике навигационное свойство сопоставляется с другой сущностью (навигационное свойство типа ссылки) или с коллекцией других сущностей (навигационное свойство типа коллекций). На стороне базы данных навигационные свойства транслируются в отношения внешнего ключа между таблицами. Инфраструктура EF Core напрямую поддерживает отношения вида "один к одному", "один ко многим" и (в версии EF Core 5) "многие ко многим". Сущностные классы также могут иметь обратные навигационные свойства с самими собой, представляя самоссылающиеся таблицы.

На заметку! Объекты с навигационными свойствами удобно рассматривать как связные списки. Если навигационные свойства являются двунаправленными, тогда объекты ведут себя подобно двусвязным спискам.

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

Отсутствие свойств для внешних ключей

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

<имя навигационного свойства><имя свойства главного ключа>

<имя главной сущности><имя свойства главного ключа>

Отношения "один ко многим"

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

Например, в базе данных, созданной в главе 21, между таблицей

Makes

Make

Inventory

Car

Car

Cars

using System.Collections.Generic;

namespace AutoLot.Samples.Models

{

   public class Make : BaseEntity

   {

    public string Name { get; set; }

    public IEnumerable Cars { get; set; } = new List();

   }

}

using System.Collections.Generic;

namespace AutoLot.Samples.Models

{

  public class Car : BaseEntity

  {

   public string Color { get; set; }

   public string PetName { get; set; }

   public int MakeId { get; set; }

   public Make MakeNavigation { get; set; }

  }

}

На заметку! При создании шаблонов для существующей базы данных исполняющая среда EF Core именует навигационные свойства типа ссылок аналогично обычным свойствам (скажем,

public Make {get; set;}

IntelliSense

Navigation

В примере

Car/Make

Car

Make

Добавьте в класс

ApplicationDbContext

DbSet

public DbSet Cars { get; set; }

public DbSet Makes { get; set; }

Затем создайте миграцию и обновите базу данных с использованием приведенных далее команд:

dotnet ef migrations add One2Many -o Migrations

 -c AutoLot.Samples.ApplicationDbContext

dotnet ef database update One2Many  -c AutoLot.Samples.ApplicationDbContext

При обновлении базы данных с применением миграции EF Core создаются следующие таблицы:

CREATE TABLE [dbo].[Makes](

  [Id] [int] IDENTITY(1,1) NOT NULL,

  [Name] [nvarchar](max) NULL,

  [TimeStamp] [varbinary](max) NULL,

 CONSTRAINT [PK_Makes] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

CREATE TABLE [dbo].[Cars](

  [Id] [int] IDENTITY(1,1) NOT NULL,

  [Color] [nvarchar](max) NULL,

  [PetName] [nvarchar](max) NULL,

  [TimeStamp] [varbinary](max) NULL,

  [MakeId] [int] NOT NULL,

 CONSTRAINT [PK_Cars] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

ALTER TABLE [dbo].[Cars]

WITH CHECK ADD  CONSTRAINT [FK_Cars_Makes_MakeId] FOREIGN 

KEY([MakeId])

REFERENCES [dbo].[Makes] ([Id])

ON DELETE CASCADE

GO

ALTER TABLE [dbo].[Cars] CHECK CONSTRAINT [FK_Cars_Makes_MakeId]

GO

Обратите внимание на ограничения внешнего ключа и проверки, созданные для зависимой таблицы (

Cars

Отношения "один к одному"

В отношениях "один к одному" обе сущности имеют навигационные свойства типа ссылок друг на друга. Хотя отношения "один к одному" четко обозначают главную и зависимую сущности, при построении таких отношений EF Core необходимо сообщить о том, какая сторона является главной, либо явно определяя внешний ключ, либо указывая главную сущность с использованием Fluent API. Если не проинформировать исполняющую среду EF Core, тогда она будет делать выбор на основе своей способности обнаруживать внешний ключ. На практике вы должны четко определять зависимую сущность, добавляя свойства внешнего ключа:

namespace AutoLot.Samples.Models

{

  public class Car : BaseEntity

  {

  public string Color { get; set; }

   public string PetName { get; set; }

   public int MakeId { get; set; }

   public Make MakeNavigation { get; set; }

   public Radio RadioNavigation { get; set; }

  }

}

namespace AutoLot.Samples.Models

{

  public class Radio : BaseEntity

  {

   public bool HasTweeters { get; set; }

   public bool HasSubWoofers { get; set; }

   public string RadioId { get; set; }

   public int CarId { get; set; }

   public Car CarNavigation { get; set; }

  }

}

Поскольку класс

Radio

Car

Radio

Car

Добавьте в класс

ApplicationDbContext

DbSet

public virtual DbSet Cars { get; set; }

public virtual DbSet Makes { get; set; }

public virtual DbSet Radios { get; set; }

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

dotnet ef migrations add One2One -o Migrations

 -c AutoLot.Samples.ApplicationDbContext

dotnet ef database update One2One  -c AutoLot.Samples.ApplicationDbContext

В результате обновления базы данных с применением миграции EF Core таблица

Cars

Radios

CREATE TABLE [dbo].[Radios](

  [Id] [int] IDENTITY(1,1) NOT NULL,

  [HasTweeters] [bit] NOT NULL,

  [HasSubWoofers] [bit] NOT NULL,

  [RadioId] [nvarchar](max) NULL,

  [TimeStamp] [varbinary](max) NULL,

  [CarId] [int] NOT NULL,

 CONSTRAINT [PK_Radios] PRIMARY KEY CLUSTERED

(

   [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

ALTER TABLE [dbo].[Radios]

WITH CHECK ADD  CONSTRAINT [FK_Radios_Cars_CarId] FOREIGN 

KEY([CarId])

REFERENCES [dbo].[Cars] ([Id])

ON DELETE CASCADE

GO

ALTER TABLE [dbo].[Radios] CHECK CONSTRAINT [FK_Radios_Cars_CarId]

GO

Обратите внимание на ограничения внешнего ключа и проверки, созданные для зависимой таблицы (

Radios

Отношения "многие ко многим" (нововведение в версии EF Core 5)

В отношении "многие ко многим" каждая сущность содержит навигационное свойство типа коллекции для другой сущности, что в хранилище данных реализуется с использованием таблицы соединения посреди двух сущностных таблиц. Такая таблица соединения именуется в соответствии с двумя таблицами в виде

<Сущность1Сущность2>

namespace AutoLot.Samples.Models

{

  public class Car : BaseEntity

  {

   public string Color { get; set; }

   public string PetName { get; set; }

   public int MakeId { get; set; }

   public Make MakeNavigation { get; set; }

   public Radio RadioNavigation { get; set; }

   public IEnumerable Drivers { get; set; } = new List();

  }

}

namespace AutoLot.Samples.Models

{

  public class Driver : BaseEntity

  {

   public string FirstName { get; set; }

   public string LastName { get; set; }

   public IEnumerable Cars { get; set; } = new List();

  }

}

Эквивалентное решение можно обеспечить путем явного создания трех таблиц и именно так приходилось поступать в версиях EF Core, предшествующих EF Core 5. Вот как выглядит сокращенный пример:

public class Driver

{

  ...

  public IEnumerable CarDrivers { get; set; }

}

public class Car

{

  ...

  public IEnumerable CarDrivers { get; set; }

}

public class CarDriver

{

  public int CarId {get;set;}

  public Car CarNavigation {get;set;}

  public int DriverId {get;set;}

  public Driver DriverNavigation {get;set;}

}

Добавьте в класс

ApplicationDbContext

DbSet

public virtual DbSet Cars { get; set; }

public virtual DbSet Makes { get; set; }

public virtual DbSet Radios { get; set; }

public virtual DbSet Drivers { get; set; }

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

dotnet ef migrations add Many2Many -o Migrations

 -c AutoLot.Samples.ApplicationDbContext

dotnet ef database update many2Many  -c AutoLot.Samples.ApplicationDbContext

После обновления базы данных с применением миграции EF Core таблица

Cars

Drivers

CarDriver

CREATE TABLE [dbo].[Drivers](

  [Id] [INT] IDENTITY(1,1) NOT NULL,

  [FirstName] [NVARCHAR](MAX) NULL,

  [LastName] [NVARCHAR](MAX) NULL,

  [TimeStamp] [VARBINARY](MAX) NULL,

 CONSTRAINT [PK_Drivers] PRIMARY KEY CLUSTERED

(

  [Id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

CREATE TABLE [dbo].[CarDriver](

  [CarsId] [int] NOT NULL,

  [DriversId] [int] NOT NULL,

 CONSTRAINT [PK_CarDriver] PRIMARY KEY CLUSTERED

(

  [CarsId] ASC,

  [DriversId] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,

 IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS 

= ON, ALLOW_PAGE_LOCKS = ON,

 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[CarDriver]

WITH CHECK ADD  CONSTRAINT [FK_CarDriver_Cars_CarsId] FOREIGN 

KEY([CarsId])

REFERENCES [dbo].[Cars] ([Id])

ON DELETE CASCADE

GO

ALTER TABLE [dbo].[CarDriver] CHECK CONSTRAINT [FK_CarDriver_Cars_CarsId]

GO

ALTER TABLE [dbo].[CarDriver]

WITH CHECK ADD  CONSTRAINT [FK_CarDriver_Drivers_DriversId]

FOREIGN KEY([DriversId])

REFERENCES [dbo].[Drivers] ([Id])

ON DELETE CASCADE

GO

ALTER TABLE [dbo].[CarDriver] CHECK CONSTRAINT [FK_CarDriver_Drivers_DriversId]

GO

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

CarDriver

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

CarDriver

https://github.com/dotnet/efcore/issues/22475

Каскадное поведение

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

• зависимые записи удаляются:

• зависимые внешние ключи устанавливаются в

null

• зависимые сущности остаются незатронутыми.

Стандартное поведение для необязательных и обязательных отношений отличается. Поведение можно установить в одно из семи значений, из которых рекомендуется использовать только пять. Поведение конфигурируется с применением перечисления

DeleteBehavior

•

Cascade

•

ClientCascade

•

ClientNoAction

•

ClientSetNull

•

NoAction

•

SetNull

•

Restrict

Указанное поведение в EF Core инициируется только после удаления сущности и вызова метода

SaveChanges()

DbContext

Необязательные отношения

Вспомните из табл. 22.4, что необязательными отношениями считаются такие, в которых зависимая сущность может устанавливать значение или значения внешних ключей в

null

ClientSetNull

Обязательные отношения

Обязательные отношения — это такие отношения, при которых зависимая сущность не может устанавливать значение или значения внешних ключей в

null

Cascade

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

Во всех предшествующих примерах навигационных свойств для построения отношений между таблицами были задействованы соглашения EF Core.

Отображение свойств на столбцы

По соглашению открытые свойства для чтения и записи отображаются на столбцы с теми же самыми именами. Типы данных столбцов соответствуют эквивалентам для типов данных CLR свойств, принятым в хранилище данных. Свойства, не допускающие

null

null

null

null

null

•

_<имя свойства в "верблюжьем" стиле>

•

_<имя свойства>

•

m_<имя свойства в "верблюжьем" стиле>

•

m_<имя свойства>

В случае обновления свойства

Color

Car

_color

_Color

m_color

m_Color

private string _color = "Gold";

public string Color

{

  get => _color;

  set => _color = value;

}

Аннотации данных — это атрибуты С#, которые применяются для дальнейшего придания формы вашим сущностям. В табл. 22.8 описаны самые часто используемые аннотации данных, предназначенные для определения деталей того, как ваши сущностные классы и свойства сопоставляются с таблицами и полями базы данных. Аннотации данных переопределяют любые конфликтующие соглашения. В оставшемся материале главы и книги вы увидите еще много аннотаций, которые можно применять для уточнения сущностей в модели.

В следующем коде показан класс

BaseEntity

Id

Id

Identity

TimeStamp

timestamp/rowversion

using System.ComponentModel.DataAnnotations;

using System.ComponentModel.DataAnnotations.Schema;

public abstract class BaseEntity

{

  [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]

  public int Id { get; set; }

  [TimeStamp]

  public byte[] TimeStamp { get; set; }

}

Вот класс

Car

using System.Collections.Generic;

using System.ComponentModel.DataAnnotations;

using System.ComponentModel.DataAnnotations.Schema;

using Microsoft.EntityFrameworkCore;

[Table("Inventory", Schema="dbo")]

[Index(nameof(MakeId), Name = "IX_Inventory_MakeId")]

public class Car : BaseEntity

{

  [Required, StringLength(50)]

  public string Color { get; set; }

  [Required, StringLength(50)]

  public string PetName { get; set; }

  public int MakeId { get; set; }

  [ForeignKey(nameof(MakeId))]

  public Make MakeNavigation { get; set; }

  [InverseProperty(nameof(Driver.Cars))]

  public IEnumerable Drivers { get; set; }

}

Атрибут

[Table]

Car

dbo

[Column]

[Index]

MakeId

[Required]

StringLength

[InverseProperty]

[ForeignKey]

Ниже перечислены отличия от соглашений EF Core:

• переименование таблицы из

Cars

Inventory

• изменение типа данных столбца

TimeStamp

varbinary(max)

timestamp

• установка типа данных и допустимости значения

null

Color

PetName

nvarchar(max)/null

nvarchar(50)/

null

• переименование индекса в

MakeId

Остальные используемые аннотации соответствуют конфигурации, определенной соглашениями EF Core.

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

timestamp

Вот как проще всего решить проблему: поместить свойство

TimeStamp

TimeStamp

Закомментируйте свойство

TimeStamp

dotnet ef migrations add RemoveTimeStamp -o Migrations

 -c AutoLot.Samples.

ApplicationDbContext

dotnet ef database update RemoveTimeStamp

 -c AutoLot.Samples.ApplicationDbContext

Уберите комментарий со свойства

TimeStamp

TimeStamp

timestamp

dotnet ef migrations add ReplaceTimeStamp -o Migrations

 -c AutoLot.Samples.

ApplicationDbContext

dotnet ef database update ReplaceTimeStamp

 -c AutoLot.Samples.ApplicationDbContext

Теперь база данных соответствует вашей модели.

Аннотации и навигационные свойства

Аннотация

ForeignKey

<ИмяТипа>Id

Свойство

InverseProperty

InverseProperty

С помощью интерфейса Fluent API сущности приложения конфигурируются посредством кода С#. Методы предоставляются экземпляром

ModelBuilder

OnModelCreating()

DbContext

Отображение классов и свойств

В следующем коде воспроизведен предыдущий пример

Car

modelBuilder.Entity(entity =>

{

  entity.ToTable("Inventory","dbo");

  entity.HasKey(e=>e.Id);

  entity.HasIndex(e => e.MakeId, "IX_Inventory_MakeId");

  entity.Property(e => e.Color)

   .IsRequired()

   .HasMaxLength(50);

  entity.Property(e => e.PetName)

   .IsRequired()

   .HasMaxLength(50);

 entity.Property(e => e.TimeStamp)

   .IsRowVersion()

   .IsConcurrencyToken();

});

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

Стандартные значения

Интерфейс Fluent API предлагает методы, позволяющие устанавливать стандартные значения для столбцов. Стандартное значение может иметь тип значения или быть строкой SQL. Например, вот как установить стандартное значение

Color

Car

Black

modelBuilder.Entity(entity =>

{

...

  entity.Property(e => e.Color)

  .HasColumnName("CarColor")

  .IsRequired()

  .HasMaxLength(50)

  .HasDefaultValue("Black");

});

Чтобы установить значение для функции базы данных (вроде

getdate()

HasDefaultValueSql()

Car

DateTime

DateBuilt

getdate()

modelBuilder.Entity(entity =>

{

  ...

  entity.Property(e => e.DateBuilt)

  .HasDefaultValueSql("getdate()");

});

Как и в случае применения SQL для вставки записи, если свойство, которое отображается на столбец со стандартным значением, имеет значение, когда EF Core вставляет запись, то вместо стандартного значения столбца будет использоваться значение свойства. Если значение свойства равно

null

Проблема возникает при наличии стандартного значения у типа данных свойства. Вспомните, что стандартное значение для числовых типов составляет

0

false

0

false

Например, добавьте в класс

Car

bool

IsDrivable

true

// Car.cs

public class Car : BaseEntity

{

  ...

  public bool IsDrivable { get; set; }

}

// ApplicationDbContext

protected override void OnModelCreating(ModelBuilder modelBuilder)

{

  modelBuilder.Entity(entity =>

  {

  ...

  entity.Property(e => e.IsDrivable).HasDefaultValue(true);

});

В случае если вы сохраните новую запись с

IsDrivable = false

false

IsDrivable

true

null

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

Если вы модифицируете

IsDrivable

null

null

null

null

false

public class Car

{

  ...

  private bool? _isDrivable;

  public bool IsDrivable

  {

   get => _isDrivable ?? true;

    set => _isDrivable = value;

  }

Для информирования EF Core о поддерживающем поле используется Fluent API:

modelBuilder.Entity(entity =>

{

  entity.Property(p => p.IsDrivable)

   .HasField("_isDrivable")

   .HasDefaultValue(true);

});

На заметку! В приведенном примере вызов метода

HasField()

Исполняющая среда EF Core транслирует поле в показанное ниже определение SQL:

CREATE TABLE [dbo].[Inventory](

...

  [IsDrivable] [BIT] NOT NULL,

...

GO

ALTER TABLE [dbo].[Inventory] ADD  DEFAULT (CONVERT([BIT],(1)))

FOR [IsDrivable]

GO

Вычисляемые столбцы

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

Inventory

PetName

Color

DisplayName

HasComputedColumnSql()

modelBuilder.Entity(entity =>

{

  entity.Property(p => p.FullName)

   .HasComputedColumnSql("[PetName] + ' (' + [Color] + ')'");

});

В версии EF Core 5 появилась возможность сохранения вычисляемых значений, так что значение вычисляется только при создании или обновлении строки. Хотя в SQL Server упомянутая возможность поддерживается, она присутствует не во всех хранилищах данных, поэтому проверяйте документацию по своему поставщику баз данных:

modelBuilder.Entity(entity =>

{

  entity.Property(p => p.FullName)

   .HasComputedColumnSql("[PetName] + ' (' + [Color] + ')'", stored:true);

});

Отношения "один ко многим"

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

modelBuilder.Entity(entity =>

{

  ...

  entity.HasOne(d => d.MakeNavigation)

   .WithMany(p => p.Cars)

   .HasForeignKey(d => d.MakeId)

   .OnDelete(DeleteBehavior.ClientSetNull)

   .HasConstraintName("FK_Inventory_Makes_MakeId");

});

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

modelBuilder.Entity(entity =>

{

  ...

  entity.HasMany(e=>e.Cars)

   .WithOne(c=>c.MakeNavigation)

   .HasForeignKey(c=>c.MakeId)

   .OnDelete(DeleteBehavior.ClientSetNull)

   .HasConstraintName("FK_Inventory_Makes_MakeId");

 });

Отношения "один к одному"

Отношения "один к одному" конфигурируются аналогично, но только вместо метода

WithMany()

WithOne()

Car

Radio

Radio

modelBuilder.Entity(entity =>

{

  entity.HasIndex(e => e.CarId, "IX_Radios_CarId")

   .IsUnique();

  entity.HasOne(d => d.CarNavigation)

   .WithOne(p => p.RadioNavigation)

   .HasForeignKey(d => d.CarId);

});

Даже если отношение определено в главной сущности, то к зависимой сущности все равно добавляется уникальный индекс. Далее приведен код установки отношения между сущностями

Car

Radio

modelBuilder.Entity(entity =>

{

  entity.HasIndex(e => e.CarId, "IX_Radios_CarId")

   .IsUnique();

});

modelBuilder.Entity(entity =>

{

  entity.HasOne(d => d.RadioNavigation)

   .WithOne(p => p.CarNavigation)

   .HasForeignKey(d => d.CarId);

});

Отношения "многие ко многим"

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

modelBuilder.Entity()

  .HasMany(p => p.Drivers)

  .WithMany(p => p.Cars)

  .UsingEntity>(

   "CarDriver",

   j => j

  .HasOne()

    .WithMany()

    .HasForeignKey("DriverId")

    .HasConstraintName("FK_CarDriver_Drivers_DriverId")

    .OnDelete(DeleteBehavior.Cascade),

   j => j

    .HasOne()

    .WithMany()

    .HasForeignKey("CarId")

    .HasConstraintName("FK_CarDriver_Cars_CarId")

    .OnDelete(DeleteBehavior.ClientCascade));