Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен
[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 — главной сущностью. Исполняющая среда EF Core неявно создает обязательный уникальный индекс на свойстве внешнего ключа в зависимой сущности. Если вы хотите изменить имя индекса, тогда можете воспользоваться аннотациями данных или Fluent API.
Добавьте в класс ApplicationDbContext экземпляр DbSet<Radio>:
public virtual DbSet<Car> Cars { get; set; }
public virtual DbSet<Make> Makes { get; set; }
public virtual DbSet<Radio> 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>. Имя можно изменить в коде через Fluent API. Таблица соединения имеет отношения "один ко многим" с каждой сущностной таблицей:
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<Driver> Drivers { get; set; } = new List<Driver>();
}
}
namespace AutoLot.Samples.Models
{
public class Driver : BaseEntity
{
public string FirstName { get; set; }
public string LastName { get; set; }
public IEnumerable<Car> Cars { get; set; } = new List<Car>();
}
}
Эквивалентное решение можно обеспечить путем явного создания трех таблиц и именно так приходилось поступать в версиях EF Core, предшествующих EF Core 5. Вот как выглядит сокращенный пример:
public class Driver
{
...
public IEnumerable<CarDriver> CarDrivers { get; set; }
}
public class Car
{
...
public IEnumerable<CarDriver> 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<Driver>:
public virtual DbSet<Car> Cars { get; set; }
public virtual DbSet<Make> Makes { get; set; }
public virtual DbSet<Radio> Radios { get; set; }
public virtual DbSet<Driver> Drivers { get; set; }
Создайте миграцию и обновите базу данных с помощью следующих команд:
dotnet ef migrations add Many2Many -o Migrations
-c AutoLot.Samples.ApplicationDbContext
dotnet ef database update many2Many -c AutoLot.Samples.ApplicationDbContext
