Связанные подэлементы в коде Entity Framework сначала

Question

Довольно простой сценарий, но есть так много перестановок примеров EF вокруг, что трудно найти то, что вам нужно. У меня есть таблица User, которая содержит основную информацию пользователя, но затем я хочу, чтобы вспомогательные таблицы для связанной информации, такие как одна для профиля пользователей, одна для критериев поиска пользователей, одна для их местоположения. Например, у меня есть следующие таблицы

пользователя UserProfile UserSearchCriteria

Я хочу, чтобы пользовательский объект содержит другие объекты и извлекать их при извлечении объекта пользователя, поэтому из кода я мог бы сказать User.Profile .MainText или User.Location.Postcode, например. Таблица User должна генерировать основной ключ UserId, и это должен быть ключ, используемый для UserProfile, UserSearch.

Итак, после ввода моего объекта пользователя, который содержит вложенные объекты userprofile и usersearch, у меня должна быть запись в таблице User с новой идентификационной вставкой UserId, а также строка в каждой из двух других таблиц с тем же вставленным ключом как UserId.

С моим кодом до сих пор он делает это, но единственная нежелательная вещь - я получаю дополнительные столбцы в таблице User, повторяя UserId для каждой ассоциации внешних ключей. Я вставлю свой класс код класса User и один из вложенных классов, так что вы получите представление

[Table("User")] 
    public class DbUser 
    { 
     [Key] 
     [DatabaseGenerated(DatabaseGeneratedOption.Identity)] 
     public int UserId { get; set; } 

     [Required] 
     [MaxLength(80)] 
     public string FirstName { get; set; } 

     [Required] 
     [MaxLength(80)] 
     public string LastName { get; set; } 

     [Required] 
     [MaxLength(80)] 
     public string EmailAddress { get; set; } 

     [Required] 
     public DateTime DateOfBirth { get; set; } 

     [Required] 
     [MaxLength(1)] 
     public string Gender { get; set; } 

     [Required] 
     public virtual DbGeographicalArea Location { get; set; } 

     [Required] 
     [MaxLength(80)] 
     public string Profession { get; set; } 

     [Required] 
     public DateTime DateJoined { get; set; } 

     [Required] 
     public DateTime LastLoggedOn { get; set; } 

     [Required] 
     [MaxLength(1)] 
     public string Status { get; set; } 

     [MaxLength(500)] 
     public string StatusNotes { get; set; } 

     public virtual DbUserMatchCriteria UserMatchCriteria { get; set; } 

     public virtual DbUserMatchLifestyle UserMatchLifestyle { get; set; } 

     public virtual DbUserProfile Profile { get; set; } 

     public virtual DbUserPassword Password { get; set; } 

     public virtual ICollection<DbUserPhoto> Photos { get; set; } 
    } 

[Table("UserMatchCriteria")] 
    public class DbUserMatchCriteria 
    { 
     [Key] 
     public int UserId { get; set; } 


    } 
} 

Таблица Пользователь имеет все необходимые столбцы генерироваться при сохранении объекта с помощью EF кода первого и таблицы UserMatchCriteria создает прекрасную, но единственная проблема заключается в конце столбцов таблицы User, у меня есть лишний нежелательный столбец UserMatchCriteria_UserId, который просто содержит тот же идентификатор, что и основной UserId, так что это похоже на двухстороннюю связь между этими двумя таблицами, когда Мне нужна только одна ассоциация.

Является ли мой подход или неправильно? Я полагаю, что если БД моделирует код именно тогда, ВЫ ДОЛЖНЫ иметь этот столбец, как в коде, объект User знает об объекте UserMatchCriteria, но с моей историей реляционных баз данных мне кажется, что в SQL мне не хватает лишних повторяющихся столбцов в конце.

Answer 1

Это собственное поведение Code-First с отношениями 1-1. Использование ORM предназначено для абстрагирования этих деталей реализации.

Кроме того, вы можете захотеть удалить аннотацию Key от DbUserMatchCriteria, которая сделала бы это Complex Type и встроенным.

ОБНОВЛЕНИЕ: Компромисс заключается в том, что вы можете получить довольно широкие ряды. Это может вызвать дополнительный пейджинг. Но для двух таблиц требуется соединение или потенциальная другая поездка в базу данных. Но эти различия могут быть тривиальными относительно таких вещей, как латентность сети.

Так что, как и все проблемы с производительностью, это зависит от множества факторов, и единственный способ действительно знать - это измерить.