Entity Framework Code-First - Определение отношений с MembershipUser - PullRequest
Новая
       29

Entity Framework Code-First - Определение отношений с MembershipUser

6 голосов
/ 12 апреля 2011

Я пытаюсь понять, как лучше определить мои классы POCO, чтобы можно было использовать функцию кодирования в первую очередь Entity Framework.
Я хочу определить некоторые отношения внешних ключей в моих классах, между пользователем, а также междусами классы.Например, рассмотрим следующие 3 класса: 

Public class Job
{
    public int JobID {get; set;}
    public string JobTitle {get; set;}
    public virtual ICollection<Resume> Resumes {get; set;} // Is this correct at all? How to access all resumes for a certain job? (many-to-many relationship between Job and Employee)
}

Public class Resume
{
    public int EmployeeID {get; set;} // or should it be: public virtual Employee EmployeePerson?
    public int JobID {get; set;} // or should it be: public virtual Job UserJob?
    public DateTime EmploymentDate {get; set;}
}  

public class Employee
{
    public int EmployeeID {get; set;}
    public int UserID{ger; set;} // or should it be: public virtual MembershipUser User?
    public ICollection<Resume> Resumes {get; set;} // Is this correct at all? 
}

Пользователь является пользователем-участником, который находится в System.Web.Security и проходит проверку подлинности с помощью FormsAuthentication или ActiveDirectoryAuthentication.Вопросы упоминаются в коде (как комментарии).Но для пояснения:

  • Должен ли я определять объекты в отношениях и использовать .Include каждый раз, когда они мне нужны, или лучше сохранить идентификатор объектов и попытаться получить данные из этого идентификаторакаждый раз, когда мне нужно?Должен ли я использовать другой подход при работе с классом MembershipUser вместо моих определенных классов?
  • Какие еще варианты использования virtual помимо включения отложенной загрузки?Где я должен избегать этого и где я должен использовать это?

Спасибо.

ОБНОВЛЕНИЕ : Я только что проверил, чтобы определить Employee с определением ublic virtual MembershipUser User.В результате в моей таблице было добавлено 4 столбца:

  • User_Email,
  • User_Comment,
  • User_IsApproved,
  • User_LastLoginDate,
  • User_LastActivityDate

Ничего уникального для пользователя (User_Email определяется как обнуляемый).Поэтому, если вы хотите, чтобы в ваших классах был пользователь, напишите обертку для MembershipUser или просто сохраните UserID.
Спасибо, Ладислав и Серги.

Ответы [ 2 ]

5 голосов
/ 12 апреля 2011

Я бы порекомендовал объявить внешние ключи в качестве свойств навигации, чтобы вы всегда могли получить доступ к связанному свойству напрямую, без необходимости извлекать его явно из базы данных самостоятельно (оно будет загружено с отложенной загрузкой).

Итак, ваша модель будет выглядеть так: 

public class Resume
{
    public int ID {get; set;}
    // or should it be: public virtual Employee EmployeePerson? 
    // --> yep, easier for you, innit?
    public Employee Employee {get; set;} 

    // or should it be: public virtual Job UserJob? --> yep :)
    public virtual Job Job {get; set;}

    public DateTime EmploymentDate {get; set;}
}  

public class Employee
{
    public int EmployeeID {get; set;}

    // or should it be: public virtual MembershipUser User? 
    // --> yes, as an approach, but read on for clarification.
    public virtual MembershipUser User {get; set;}

    // Is this correct at all? ---> needs to be declared as virtual
    public virtual ICollection<Resume> Resumes {get; set;}
}

Ваш класс Job в порядке, насколько я могу судить.

Для ясности, он будет работать так же хорошо, как и изначально, но вам нужно явно пометить свойства ForeignKeyAttribute, что не нужно, если вы хотите отказаться от немного контроля над тем, как FK названы в вашей базе данных.

  • Одно замечание по поводу свойства навигации MembershipUser: боюсь, вам нужно написать оболочку для класса MembershipUser, поскольку, насколько я помню, у него нет стандартного конструктора и поэтому EF, вероятно, не сможет создать его для вас при отложенной загрузке.

  • О том, как пометить свойство как virtual, вы, возможно, захотите взглянуть на этот вопрос: Какой эффект могут оказать виртуальные ключевые слова в Entity Framework 4.1 POCO Code First?

3 голосов
/ 12 апреля 2011

В случае с первым кодом, я бы, вероятно, использовал это: 

public class Job
{
    public virtual int JobId {get; set;}
    public virtual string JobTitle {get; set;}
    public virtual ICollection<Resume> Resumes {get; set;} 
}

public class Resume
{
    [Key, Column(Order = 0)]
    public virtual int EmployeeId {get; set;}
    [Key, Column(Order = 1)] 
    public virtual int JobId {get; set;} 

    public virtual DateTime EmploymentDate {get; set;}
    public virtual Employee Employee {get; set;}
    public virtual Job Job {get; set;}
}  

public class Employee
{
    public virtual int EmployeeId {get; set;}
    public virtual int UserId {ger; set;} 
    public virtual User User {get;set;}
    public virtual ICollection<Resume> Resumes {get; set;} 
}

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

...