EF5 Многие из многих присоединяются к текущему API-интерфейсу

Question

Нужно ли мне создавать класс POCO для представления таблицы соединений в отношениях многих-многих?

Это мой сценарий:

public class Event 
{ 
    public int EventId { get; set; } 
    public int OrganizerId { get; set; } 
} 

public class Person 
{ 
    public int PersonId { get; set; } 
    ICollection<Event> Events { get; set; } 
} 

public class Company 
{ 
    public int CompanyId { get; set; } 
    ICollection<Event> Events { get; set; } 
} 

Как человек или компания может организовать мероприятие, я думал, чтобы создать таблицы объединения как

Table Events_People 
PersonId 
OrganizerId 


Table Events_Companies 
CompanyId 
OrganizerId 

Я знаю, что должен легко сделать, если Я создаю два Pocos классы, как

public class EventPerson 
{ 
    public int EventId { get; set; } 
    public Person PersonId { get; set; } 
} 

чем с Fluent API что-то вроде

modelBuilder.Entity<Person>() 
// PK 
.HasKey(e => e.PersonId) 
// FK 
.HasMany(e => e.Events) 
.WithRequired(e => e.PersonId); 

Есть ли способ избежать двух POCO и напрямую сообщить API для создания таблицы соединений? Спасибо

Answer 1

Вы можете сделать много для многих с EF да. Большой вопрос в том, что хорошая идея. Например, вы можете обнаружить, что у вас есть проблемы с удалением каскада, если вы это делаете, и вам это нужно или нужно. Если у вас есть 2 требуемые отношения к одному и тому же объекту (не обязательно ваш конкретный пример кода), но более общий в соответствии с вашим вопросом, тогда вы можете получить ошибки компиляции/выполнения EF, если вы не используете WillCascadeOnDelete (false). На всякий случай люди думают, поэтому вы можете это сделать. Becareful. :-)

Но вы спросили вы можете сказать EF, чтобы создать Регистрация

Вы не видите таблицу присоединиться, порожденную EF? Я бы ожидал этого. Мне любопытно, почему бы и нет.

Вы можете явно управлять:

HasMany(t => t.NavigationProperty1) 
.WithMany(a => a.ReverseNavigationProperty) 
.Map(c => c.ToTable("TheJoinTable")); 



// rename keys as required, may not be required... 
c.MapLeftKey("ColumnKeyName"); 
c.MapRightKey("ABetterName2"); 

BTW пример вы предлагаете именно шаблон, который требуется, чтобы обойти некоторые проблемы CascadeOnDelete.