Using ASP.NET Identity with my own entities in MVC

Question

In my "Car Hire" solution I have a separate project that holds all my entities such as User,Role, Car, Booking etc. I am using EntityFramework Code First to generate the database. All of that is working fine. I have added a MVC project to my solution. Now I want to take full advantage of the ASP.NET Identity 2.x model. My question is: how can I incorporate the ApplicationUser that comes with the MVC project with my own User Class? My User class:

public partial class User
{
    public User()
    {
    }
    [Key]
    public int Id { get; set; }
    [StringLength(200)]
    public string FirstName { get; set; }
    [StringLength(200)]
    public string LastName { get; set; }
    [StringLength(200)]
    public string Address1 { get; set; }
    [StringLength(200)]
    public string Address2 { get; set; }
    [StringLength(200)]
    public string Address3 { get; set; }
    [StringLength(20)]
    public string ZipCode { get; set; }
    [StringLength(200)]
    public string City { get; set; }
    [StringLength(200)]
    public string Country { get; set; }
    [StringLength(200)]
    public string Phone { get; set; }
    [StringLength(200)]
    public string MobilePhone { get; set; }
    [StringLength(200)]
    public string WorkPhone { get; set; }
}

Should I move all of my User properties to the ApplicationUser class and add a foreign key to ApplicationUser in my own classes such as the Booking class ?

Answer 1

There's nothing special about ApplicationUser. It's just a default implementation of a class that inherits from IdentityUser. Even then, that inheritance is merely to bootstrap all the functionality in Identity such as roles, claims, etc.

You can either remove ApplicationUser entirely and make your user class inherit from IdentityUser or you can move the properties from your user class to ApplicationUser and remove your user class. Either way, the result will be the same.

And, yes, you want to create foreign keys between your classes that are related to a "user" and whatever class ends up being your "user" class. Again, there's nothing really special about ApplicationUser, so if you choose to stick with that, you can set it up like any other POCO in your project, creating relationships with other entities as needed.

Some have suggested inheriting your user class from ApplicationUser, but I don't think that's a great idea. There are valid reasons to inherit from the base "user" class used for Identity, but here you're not dealing with different types of users, but rather one user type that needs additional properties. Inheritance is really only an acceptable way to achieve that if you have no access to the base class to modify it. Here, you do. It's your class; the project template merely created it for you.