Ядро EF - ошибка нескольких каскадных путей при использовании аннотаций данных и дублирующих ключей при использовании плавных API

Question

Мои модели без аннотаций внешнего ключа:

Division {
    [Key]
    public int Id { get; set; }

    public ICollection<Rooms> DivisionRooms { get; set; }
    public ICollection<Desks> DivisionDesks { get; set; }
}

//------------------------------------------
Rooms {
    [Key]
    public int Id { get; set; }

    public int DivisionId { get; set; }
    public Division Division { get; set; }

    public ICollection<Desks> DivisionDesks { get; set; }
}   
//------------------------------------------
Desks {
    [Key]
    public int Id { get; set; }

    public int DivisionId { get; set; }
    public Division Division { get; set; }

    public int RoomId { get; set; }
    public Room Room { get; set; }

}

С помощью свободно работающих API я создаю индексы и т. Д. c ... Если я добавлю миграцию для этого, код автоматически автоматически выберет внешние ключи и Код миграции все в порядке. Но при создании базы данных с помощью команды Update-Database она говорит:

Introducing FOREIGN KEY constraint etc..etc.. may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.

Теперь, чтобы добавить каскадные ограничения, Если я добавлю определения внешнего ключа через свободный API (например: - Для сущности Desk)

builder.HasOne<Room>()
       .WithMany()
       .HasForeignKey(e => e.RoomId)
       .OnDelete(DeleteBehavior.Restrict);

Генерирует скрипт миграции, имеющий дублированные внешние ключи. Но Update-Database работает и создает базу данных с сущностью Room с дублированными внешними ключами для двух других сущностей.

В общем, если я использую аннотации данных; при запуске update-database он жалуется на проблемы с каскадом, а если я использую беглый apis и ограничиваю каскады, он создает дубликаты внешних ключей.

Так как же мне правильно определить эту модель с включенной навигацией?

Answer 1

builder.Entity<Division>()
       .HasMany(x=>x.DivisionDesks)
       .WithOne()
       .OnDelete(DeleteBehavior.Restrict);

builder.Entity<Division>()
       .HasMany(x=>x.DivisionRooms)
       .WithOne()
       .OnDelete(DeleteBehavior.Restrict);

builder.Entity<Room>()
       .HasMany(x=>x.DivisionDesks)
       .WithOne()
       .OnDelete(DeleteBehavior.Restrict);

Я думаю, что ваша проблема была в том, как вы обработали HasForeignKey, это не способ на самом деле реализовать отношение один ко многим в EF Core. Также вы не используете аннотации Flunter ИЛИ . Оба работают вместе. Вы используете аннотацию для создания некоторых базовых c отношений, а затем используете свободный для построения более сложных данных.

Использование HasForeignKey - это то, что создает дубликат, поскольку он уже определен вашим классом в соответствии с соглашением об именах.

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