1

Вот мой сценарий: У меня есть три типа существ, пользователей (идентификатор, адрес электронной почты, пароль), Доброволец (имя, дата рождения ...) и NonProfit (адрес ...) , И добровольцы, и некоммерческие пользователи.Entity Framework наследования составной ключ

Мне удалось создать три таблицы типа tbUser, tbVolunteer и tbNonProfit, где у пользователя есть первичный ключ, а волонтер и некоммерческая организация имеет первичный/внешний ключ пользователя (UserID), но я не хочу этого.

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

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

Я открыт для предложений, спасибо y'all

+0

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

ответ

1

Правильный способ реализации это не есть еще один первичный ключ. Реализация выглядит следующим образом:

public class User 
{ 
    [Key] 
    public int UserId { get; set; } 

    public string Email{ get; set; } 
    public string Password { get; set; } 
} 

[Table("Volunteer")] 
public class Volunteer : User 
{ 
    public DateTime BirthDate { get; set; } 
} 

[Table("NonProfit")] 
public class NonProfit: User 
{ 
    public string Address { get; set; } 
} 

public class MyContext: DbContext 
{ 
    public DbSet<User> Users { get; set; } 
    public DbSet<Volunteer> Volunteers { get; set; } 
    public DbSet<NonProfit> NonProfits { get; set; } 
} 

Для получения дополнительной информации, смотрите на эту статью: http://www.codeproject.com/Articles/796521/Inheritance-in-Entity-Framework-Table-Per-Type

+0

Спасибо за ответ и ссылку. Я шел по этому пути. Таким образом я могу добиться того, чего хочу, теперь понимаю, как это работает. У меня только проблема. Например, вместо создания пользователя я создаю Volunteer on NonProfit, который автоматически создаст пользователя. Проблема заключается в том, что волонтер предоставит свои личные данные позже, поэтому я должен был предоставить пустые значения, потому что требуются некоторые поля. – Murilo

+0

Как вы можете видеть в этом ответе http://stackoverflow.com/questions/3823662/changing-inherited-types-in-entity-framework это невозможно из коробки. Вы можете использовать ответ на этот вопрос. Альтернативой является добавление дополнительных дополнительных полей в объект User и просто перечисление типов вместо реального наследования. –

+0

Да, я прочитал предоставленный ответ. Они говорят об использовании композиции или хранимой процедуры. Поскольку я хочу сохранить наследование, я мог бы использовать хранимую процедуру, чтобы избежать таких работ, как установка пустых значений для Volunteer. Таким образом, пользователь «125» будет создан, затем, когда он заполнит оставшиеся данные, я создам волонтер «125» через хранимую процедуру. благодаря – Murilo

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