Код EF Перший зовнішній ключ без властивості навігації

Скажімо, у мене є такі сутності:

public class Parent
{
    public int Id { get; set; }
}
public class Child
{
    public int Id { get; set; }
    public int ParentId { get; set; }
}

Який код першого вільного синтаксису API для забезпечення того, що ParentId створюється в базі даних із обмеженням зовнішнього ключа в таблиці батьків, без необхідності мати властивість навігації ?

Я знаю, що якщо я додаю властивість навігації Parent до Child, то я можу зробити це:

modelBuilder.Entity<Child>()
    .HasRequired<Parent>(c => c.Parent)
    .WithMany()
    .HasForeignKey(c => c.ParentId);

Але я не хочу властивість навігації в цьому конкретному випадку.

З EF Code First Fluent API це неможливо. Завжди потрібна хоча б одна властивість навігації для створення обмеження зовнішнього ключа в базі даних.

Якщо ви використовуєте перші міграції коду, у вас є можливість додати нову міграцію на основі коду на консолі менеджера пакетів ( add-migration SomeNewSchemaName). Якщо ви щось змінили зі своєю моделлю або відображенням, буде додано нову міграцію. Якщо ви нічого не змінили, змусіть нову міграцію за допомогою add-migration -IgnoreChanges SomeNewSchemaName. У цьому випадку міграція міститиме лише пусті Upта Downметоди.

Потім ви можете змінити Upметод, додавши до нього наступне:

public override void Up()
{
    // other stuff...

    AddForeignKey("ChildTableName", "ParentId", "ParentTableName", "Id",
        cascadeDelete: true); // or false
    CreateIndex("ChildTableName", "ParentId"); // if you want an index
}

Запуск цієї міграції ( update-databaseна консолі управління пакетами) запустить оператор SQL, подібний до цього (для SQL Server):

ALTER TABLE [ChildTableName] ADD CONSTRAINT [FK_SomeName]
FOREIGN KEY ([ParentId]) REFERENCES [ParentTableName] ([Id])

CREATE INDEX [IX_SomeName] ON [ChildTableName] ([ParentId])

Як варіант, без міграцій ви можете просто запустити чисту команду SQL за допомогою

context.Database.ExecuteSqlCommand(sql);

де contextє екземпляром вашого похідного класу контексту і sqlє лише наведеною вище командою SQL як рядок.

Майте на увазі, що при всьому цьому EF не має поняття, що ParentIdє зовнішнім ключем, що описує стосунки. EF розглядатиме це лише як звичайну скалярну властивість. Якось все вищезазначене є лише більш складним та повільним способом порівняно із простим відкриттям інструменту управління SQL та додаванням обмежень вручну.

Незважаючи на те, що ця публікація призначена для Entity Frameworkне Entity Framework Core, вона може бути корисною для тих, хто хоче досягти того самого, використовуючи Entity Framework Core (я використовую V1.1.2).

Мені не потрібні навігаційні властивості (хоча вони добре) , тому що я практикую DDD , і я хочу Parentі Childбути два окремих агрегатні коріння. Я хочу, щоб вони могли спілкуватися між собою за допомогою зовнішнього ключа, а не через Entity Frameworkвластивості навігації, що стосуються інфраструктури .

Все, що вам потрібно зробити, це налаштувати відносини на одній стороні, використовуючи HasOneта WithManyбез вказівки властивостей навігації (вони зрештою відсутні).

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) {}

    protected override void OnModelCreating(ModelBuilder builder)
    {
        ......

        builder.Entity<Parent>(b => {
            b.HasKey(p => p.Id);
            b.ToTable("Parent");
        });

        builder.Entity<Child>(b => {
            b.HasKey(c => c.Id);
            b.Property(c => c.ParentId).IsRequired();

            // Without referencing navigation properties (they're not there anyway)
            b.HasOne<Parent>()    // <---
                .WithMany()       // <---
                .HasForeignKey(c => c.ParentId);

            // Just for comparison, with navigation properties defined,
            // (let's say you call it Parent in the Child class and Children
            // collection in Parent class), you might have to configure them 
            // like:
            // b.HasOne(c => c.Parent)
            //     .WithMany(p => p.Children)
            //     .HasForeignKey(c => c.ParentId);

            b.ToTable("Child");
        });

        ......
    }
}

Я наводжу приклади, як також налаштувати властивості сутності, але найважливішим тут є HasOne<>, WithMany()і HasForeignKey().

Сподіваюся, це допоможе.

Невелика підказка для тих, хто хоче використовувати DataAnotations і не хоче виставляти властивість навігації - використовувати protected

public class Parent
{
    public int Id { get; set; }
}
public class Child
{
    public int Id { get; set; }
    public int ParentId { get; set; }

    protected virtual Parent Parent { get; set; }
}

Ось і все - буде створений зовнішній ключ з cascade:trueпісля Add-Migration.

У випадку з EF Core вам не обов'язково потрібно надавати властивість навігації. Ви можете просто надати зовнішній ключ на одній стороні відносин. Простий приклад з Fluent API:

using Microsoft.EntityFrameworkCore;
using System.Collections.Generic;

namespace EFModeling.Configuring.FluentAPI.Samples.Relationships.NoNavigation
{
    class MyContext : DbContext
    {
        public DbSet<Blog> Blogs { get; set; }
        public DbSet<Post> Posts { get; set; }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
             modelBuilder.Entity<Post>()
                .HasOne<Blog>()
                .WithMany()
                .HasForeignKey(p => p.BlogId);
        }
    }

    public class Blog
    {
         public int BlogId { get; set; }
         public string Url { get; set; }
    }

    public class Post
    {
         public int PostId { get; set; }
         public string Title { get; set; }
         public string Content { get; set; }

        public int BlogId { get; set; }
    }
}

Я використовую .Net Core 3.1, EntityFramework 3.1.3. Я шукав навколо, і Рішення, яке я придумав, використовувало загальну версію HasForeginKey<DependantEntityType>(e => e.ForeginKeyProperty). Ви можете створити відношення один до одного приблизно так:

builder.entity<Parent>()
.HasOne<Child>()
.WithOne<>()
.HasForeginKey<Child>(c => c.ParentId);

builder.entity<Child>()
    .Property(c => c.ParentId).IsRequired();

Сподіваюся, це допомагає або принаймні дає деякі інші ідеї щодо використання HasForeginKeyметоду.

Моя причина НЕ з допомогою навігаційних властивостей є залежностями класу. Я розділив свої моделі на декілька збірок, які можна використовувати або не використовувати в різних проектах у будь-яких комбінаціях. Отже, якщо у мене є сутність, яка має властивість нагівації до класу з іншої збірки, мені потрібно зробити посилання на цю збірку, якої я хочу уникати (або будь-який проект, який використовує частину цієї повної моделі даних, буде нести все з собою).

І у мене є окрема програма міграції, яка використовується для міграцій (я використовую автоматичну міграцію) та початкового створення БД. Цей проект посилається на все з очевидних причин.

Рішення у стилі С:

• "скопіювати" файл із цільовим класом до проекту міграції за посиланням (перетягування та падіння за допомогою altключа в VS)
• вимкнути властивість нагівації (і атрибут FK) через #if _MIGRATION
• встановіть це визначення препроцесора в програмі міграції, а не встановлюйте в проекті моделі, тому він не буде посилатися ні на що (не посилайтеся на збірку з Contactкласом у прикладі).

Зразок:

    public int? ContactId { get; set; }

#if _MIGRATION
    [ForeignKey(nameof(ContactId))]
    public Contact Contact { get; set; }
#endif

Звичайно, слід таким же чином відключити usingдирективу та змінити простір імен.

Після цього всі споживачі можуть використовувати це властивість як звичайне поле БД (і не посилатися на додаткові збірки, якщо вони не потрібні), але сервер БД буде знати, що він є FK, і може використовувати каскад. Дуже брудне рішення. Але працює.