2015-03-28 4 views
0

Я использую первый подход EF. У меня есть следующие три класса:EF отношение один ко многим

public class Inquiry 
{ 
    public Guid Id { get; set; } 
    public string Title { get; set; } 
    public string Description { get; set; } 
    public virtual ApplicationUser CreatedBy { get; set; } 
    public virtual Contractor Contractor { get; set; } 
    public IList<ApplicationUser> InquiryUsers { get; set; } 
    public IList<InquiryComment> Comments { get; set; } 
    public IList<HydroTechEmail> Emails { get; set; } 
    public InquiryState State { get; set; } 
    public List<string> Attachments { get; set; } 
    public DateTime? TimeOfCreation { get; set; } 
    public DateTime? TimeOfModification { get; set; } 
} 

public class HydroTechEmail  
{ 
    public Guid Id { get; set; } 
    public string Subject { get; set; } 
    public string Content { get; set; } 
    public string FromDisplayName { get; set; } 
    public string FromAddress { get; set; } 
    public List<string> ToDisplayName { get; set; } 
    public List<string> ToAddress { get; set; } 
    public HydroTechEmailState State { get; set; } 
    public DateTime? ReceivedTime { get; set; } 
    public virtual List<HydroTechEmailAttachment> Attachments { get; set; } 
    public virtual ApplicationUser ApplicationUser { get; set; } 
} 

public class ApplicationUser 
{ 
    public Guid Id {get;set;} 
    public string Firstname {get;set;} 
    public string Lastname {get;set;} 
} 

Я думал, что EF будет генерировать некоторые промежуточные классы для отношения Запроса -> Много сообщений электронной почты и запрос -> Многих приложений пользователи. Вместо этого он создавал внешние ключи в классах ApplicationUser и HydroTechEmail для класса «Запрос». Как мне создать это для многих отношений? Странно, что для комментариев он создал промежуточную таблицу с именем InquiryComments.

ответ

0

Entity Framework будет генерировать только промежуточные таблицы для отношений «многие ко многим».

Для отношений «один ко многим» промежуточные таблицы не создаются, потому что это необязательно.

+0

Конечно .. это должно быть много для многих отношений –

+0

, но это не имеет смысла ... у одного запроса может быть много пользователей, но у меня нет таблицы Inquiry_Users в базе данных. Вместо этого у меня есть внешний ключ в таблице Users (Fk_Inquiry_Id) для запроса справки. Поэтому это неверно, потому что в этом случае это может быть только взаимно однозначное отношение. –

+0

Решение заключалось в том, чтобы добавить свойства Запросы на классы ApplicationUser и HydroTechEmail и украсить их с помощью атрибута [InverseProperty ("SpecificProperty_In_Inquiry_Class") –

Смежные вопросы