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

class="p1">После обновления базы данных с применением миграции 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 посредством Fluent API. Ниже перечислены доступные варианты в перечислении:

• Cascade;

• ClientCascade;

• ClientNoAction (не рекомендуется к использованию);

• ClientSetNull;

• NoAction (не рекомендуется к использованию);

• SetNull;

• Restrict.

Указанное поведение в EF Core инициируется только после удаления сущности и вызова метода SaveChanges() на экземпляре класса, унаследованного от DbContext. Дополнительные сведения о том, когда EF Core взаимодействует с хранилищем данных, ищите в разделе "Выполнение запросов" далее в главе.

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

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

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

Обязательные отношения — это такие отношения, при которых зависимая сущность не может устанавливать значение или значения внешних ключей в null. Для обязательных отношений стандартным поведением является Cascade. В табл. 22.6 описано каскадное поведение с зависимыми сущностями и влияние на записи базы данных при использовании SQL Server.

Соглашения, связанные с сущностями

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

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

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

По соглашению открытые свойства для чтения и записи отображаются на столбцы с теми же самыми именами. Типы данных столбцов соответствуют эквивалентам для типов данных CLR свойств, принятым в хранилище данных. Свойства, не допускающие null, устанавливаются в хранилище данных как не null, а свойства, допускающие null, устанавливаются так, чтобы значение null было разрешено. Инфраструктура EF Core поддерживает ссылочные типы, допускающие null, которые появились в C# 8. Для поддерживающих полей EF Core ожидает их именования с применением одного из следующих соглашений (в порядке старшинства):

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

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

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

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

В случае обновления свойства Color класса Car для использования поддерживающего поля (по соглашению) оно получило бы имя _color, _Color, m_color или m_Color, как показано ниже:

private string _color = "Gold";

public string Color

{

  get => _color;

  set => _color = value;

}

Аннотации данных Entity Framework

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

В следующем коде показан класс BaseEntity с аннотацией, которая объявляет поле Id первичным ключом. Вторая аннотация свойства Id указывает, что оно является столбцом Identity в базе данных SQL Server. Свойство TimeStamp в SQL Server будет столбцом timestamp/rowversion (для проверки параллелизма, рассматриваемой позже в главе).

using System.ComponentModel.DataAnnotations;

using System.ComponentModel.DataAnnotations.Schema;

public abstract class BaseEntity