Многосвязной объект в EF6

Question

Немного интересного здесь, с которым я не сталкивался раньше. Мы вручную создали отношения многие-ко-многим в EF6 с помощью аннотаций:

public class User 
{ 
    public int Id { get; set; } 
} 

public class School 
{ 
    public int Id { get; set; } 
} 

public class UserSchool 
{ 
    [Key] 
    [Column(Order = 1)] 
    public int UserId { get; set; } 

    [Key] 
    [Column(Order = 2)] 
    public int SchoolId { get; set; } 

    [Required] 
    public virtual User User { get; set; } 

    [Required] 
    public virtual School School { get; set; } 
} 

(Другие дополнительные свойства, опущенные для краткости - достаточно сказать, что у нас есть дополнительные свойства на столе перехода, следовательно, почему мы создали его явно)

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

Теперь мы должны присоединиться к распределительной стола (UserSchool) к другому столу, и как многие-ко-многим:

public class IPAddress 
{ 
    public int Id { get; set; } 

    public string IPAddress { get; set; } 
} 

public class UserSchoolIPAddress 
{ 
    ?? what to put in here 

    public virtual UserSchool UserSchool { get; set; } 

    public virtual IPAddress IPAddress { get; set; } 
} 

Я попытался как беглого картографированию API И указав свойства идентификатора с помощью соглашения об именах и аннотации: быстрое отображение API просто терпит неудачу, так как я думаю, что он не любит использование свойств навигационных объектов; привязка идентификатора с аннотациями просто дублирует свойства UserSchool во второй раз в схеме таблицы, что вызывает проблемы синхронизации.

Итак, кто-нибудь раньше встретил этот сценарий и нашел решение?

Answer 1

ОК, так что получается, что я идиот. Похоже, что среда WILL действительно обрабатывает мой сценарий, но я неправильно настроил типы свойств, чтобы было несоответствие, поэтому EF попытался дублировать новые свойства. Поэтому

Заполненная определение таблицы многие-к-перехода будет выглядеть следующим образом:

public class UserSchoolIPAddress 
{ 
    [Key] 
    [Column(Order = 1)] 
    public int UserSchoolUserId { get; set; } 

    [Key] 
    [Column(Order = 2)] 
    public int UserSchoolSchoolId { get; set; } //<-- I had this set to a string for some reason, which broke everything 

    [Key] 
    [Column(Order = 3)] 
    public int IPAddress IPAddressId { get; set; } 

    public virtual UserSchool UserSchool { get; set; } 

    public virtual IPAddress IPAddress { get; set; } 
} 

Так что это будет правильно создать вторую таблицу перехода, используя FK к «многие» конца (в этом случае IPAddress) и два FK на конец «соединения» (UserSchool), и объединить все три FK вместе в один комплекс PK на этом «суперпересечении». Молодцы EF!

Answer 2

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

В вашем случае у вас есть пользователь, который может иметь много школ и школу, в которой может быть много пользователей. Если вы создадите эту модель (и настроите ее на беглой apis), EF создаст для вас таблицу UserSchool, и вам не нужно ее управлять (EF будет обрабатывать ее для вас).

Об IPAddress, если я понял вашу модель, IPAddress используется одним пользователем в одной школе. Это может быть ваша модель с некоторыми свойствами навигации.

public class User 
{ 
    public int Id { get; set; } 
    public virtual ICollection<School> Schools {get; set;} 
    public virtual ICollection<IpAddress> IpAddresses {get; set;} 
} 

public class School 
{ 
    public int Id { get; set; } 
    public virtual ICollection<User> Users {get; set;} 
    public virtual ICollection<IpAddress> IpAddresses {get; set;} 
} 

public class IpAddress 
{ 
    public string Id { get; set; } 
    public virtual User User {get; set;} 
    public virtual School School {get; set;} 
}