c# - EF. Fluent API. Указание связей между таблицами


0

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

public void Configure(EntityTypeBuilder<Series> builder)
    {
        builder.ToTable("Series");
        builder.HasKey(s => s.SeriesId);

        // SERIES<->SUBSERIES: one to many
        builder.HasMany(s => s.Subseries)
               .WithOne(ss => ss.Series)
               .HasForeignKey(ss => ss.SeriesId);            
    }

и

public void Configure(EntityTypeBuilder<Subseries> builder)
    {
        builder.ToTable("Subseries");
        builder.HasKey(ss => ss.SubseriesId);

        // SUBSERIES<->SERIES: many to one
        builder.HasOne(ss => ss.Series)
               .WithMany(s => s.Subseries)
               .HasForeignKey(ss => ss.SeriesId);
    }

В таком случае мы дублируем указание внешнего ключа, также если добавить поведение по удаление - то будем дублировать и него (OnDelete(DeleteBehavior.*))

Такое описание не вызывает проблем при компиляции и выполнении,но может вызвать проблему и путаницу при несовпадении. Какая практика лучшего описания таблицы? ( я думаю, что лучше описывать внешний ключ и его поведение в таблице, где этот ключ существует, а в таблице, на которую он указывает его вообще никак не описывать; но все же я не уверен в этом)

1 ответ

0

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

Пример MS SQL 1

Metanit неплохо об EF

Честно говоря с таким подходом очень легко запутаться. Доменную логику не всегда можно так легко держать в голове, особенно если уйма таблиц. Иногда сложно понять у одного покупателя много покупок или каждая покупка имеет покупателя. Для поддержания "кода в чистоте" мне намного удобнее определять связь по какому-то более очевидному принципу. К примеру указывать связь для той таблицы, которая содержит внешний ключ. — 7 янв 20192019-01-07 07:46:32.000000
Спасибо за ответ. Да, этот подход имеет смысл. Указывать со стороны доменной логики. — 5 янв 20192019-01-05 13:09:17.000000