Code First POCO Design - PullRequest
Новая
       2

Code First POCO Design

2 голосов
/ 17 февраля 2012

Сначала я создаю базу данных, используя код структуры сущностей, и у меня возникают некоторые проблемы с дизайном базы данных / POCO. Моя проблема с наследованием.

В моей системе есть две основные роли пользователей: Лектор и Студент. У меня есть базовый класс User, который содержит Id, Logon, Role (определяя их как лектора или студента), Имя и Фамилия. Если пользователь является лектором, то с ним также связано свойство (отношение) тегов. Если пользователь является студентом, то у него есть год и свойство типа степени.

Оба типа пользователей могут создавать проекты. У проекта есть заявитель. То, что я хочу - это иметь возможность вернуть тип Lecturer или Student из Project.Proposer, но я не могу этого сделать. Я также не уверен, должен ли Project.Proposer иметь тип User (базовый класс) в классе проекта, могу ли я использовать интерфейс (сначала с кодом) или что.

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

Ответы [ 2 ]

2 голосов
/ 17 февраля 2012

Чтобы сделать это правильно в EF4 CodeFirst, нужно иметь в проекте свойство Proposer типа User.

После извлечения проекта Proposer будет иметь правильный тип, но значение будет помечено как User.Чтобы выяснить, какой фактический тип является фактическим, вы можете использовать ключевое слово is, например: 

// project is a Project instance    
if (project.Proposer is Lecturer)
{
   // do something
} else if (project.Proposer is Student)
{
   // do something else
}

. Это структура данных, которую я бы предложил: 

public class Tag
{
    [Key]
    public int ID { get; set; }
}

public abstract class User 
{
    [Key]
    public int ID { get; set; }
    public string Forename { get; set; }        
    public string Surename { get; set; }
}

public class Lecturer : User
{
    public IEnumerable<Tag> Forename { get; set; }
}


public class Student : User
{
    public IEnumerable<Tag> Forename { get; set; }
}

public class Project
{
    [Key]
    public int ID { get; set; }

    public User Proposer { get; set; }
}

другие способы структурирования, такие как введение иерархии проектов с использованием классов, таких как LecturerProject StudentProject и перемещение Proposer с правильным типом в эти классы, но это не рекомендуется.Так как вам всегда придется обрабатывать эти классы проекта отдельно.Например, при получении названия проекта и его автора.Так как базовый класс проекта больше не имеет свойства proposer, вам необходимо выполнить один и тот же запрос дважды.Я надеюсь, что смогу проиллюстрировать проблемы, возникающие при использовании этого подхода.

Следующий вопрос, который вам нужно задать себе: вас волнует, как данные сохраняются в БД?Так как есть 3 способа сделать это для классов с наследованием:

Одно слово совета.Если вы не планируете хранить миллионы записей, не обращайте внимания на то, как они хранятся в БД.Table per Hierarchy является самым простым в использовании, особенно в начале, также по умолчанию.

0 голосов
/ 17 февраля 2012

Если вы не хотите иметь класс User в качестве предлагающего, как насчет того, чтобы иметь свойство типа ProposedUserId , с этим идентификатором вы можете запросить класс User, проверить, какова роль пользователя, а затем получитьнеобходимые данные из таблицы лекций или учеников

...