1

Here's my scenario: I have three entities types, User(id, email, password), Volunteer(name, birthdate...) and NonProfit(address...). Both Volunteer and NonProfit are User.

I was able to create three tables like tbUser, tbVolunteer and tbNonProfit, where user has a primary key, and volunteer and nonprofit has primary/foreign key of user(UserID), but I don't want this.

My user is not an abstract class. First I will create an user, for example Mary, and I will say that Mary is of type Volunteer. In a next moment, Mary will log in and complete the registration, so I will create a volunteer row on database.

In short, I would like that the volunteer table had UserID as foreign key and VolunteerID(primary key) in order to keep it equals my engineering diagrams, where volunteer and nonprofit are users. I don't want an aggretation or composition because in my UML volunteer inherits from user.

I'm open for suggestions, thank y'all

SteveC
  • 15,808
  • 23
  • 102
  • 173
Murilo
  • 1,112
  • 1
  • 18
  • 33
  • Having a separate foreign and primary key on your `Volunteer` table will effectively make it a one-to-many relationship, (a user could be many different volunteers). I'm not sure you can achieve this using inheritance. – user2697817 Jun 10 '15 at 12:57

1 Answers1

2

The correct way to implement this is to not have another primary key. The implementation looks like this:

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; }
}

For more information, have a look at this article: http://www.codeproject.com/Articles/796521/Inheritance-in-Entity-Framework-Table-Per-Type

Rob Tillie
  • 1,137
  • 8
  • 30
  • Thanks for the answer and link. I was going in this path. In this way I can achieve what I want, now I understand how it works. I only have a problem. For example instead of create an User, I create an Volunteer on NonProfit, that will create the user automatically. The problem is the volunteer will provide his personal data later, so I had to provide empty values because some fields are required. – Murilo Jun 10 '15 at 13:39
  • As you can see in this answer http://stackoverflow.com/questions/3823662/changing-inherited-types-in-entity-framework this is not possible out of the box. You can use the answer to that question. An alternative is to make all the additional fields optional in the User entity, and just have a type enumeration instead of real inheritance. – Rob Tillie Jun 11 '15 at 08:52
  • Yeah I read the provided answer. They talk about using composition or a stored procedure. As I want to keep the inheritance I might be using a stored procedure to avoid works around such as setting empty values for Volunteer. So User "125" will be created, then when he fills out the remaining data, I will create the Volunteer "125" through stored procedure. Thanks – Murilo Jun 11 '15 at 14:03