I am creating an ASP.Net MVC application related to design, buildings and etc. I need to have two types of users - Normal People and Companies. Here I read how I can do it. I have created basic class ApplicationUser. The classes PersonUser and CompanyUser inherit this class and have some more properties. I am using MSSQL Database. I have thee following questions:

• (My main question) Should I create DbSet<PersonUser> and DbSet<CompanyUser> or I should create DbSet<ApplicationUser>?
• When I create database connections should the foreign key point to PersonUser and CompanyUser or to ApplicationUser?
• In controllers when I user UserManager<TUser> or SignInManager<TUser> depending on the user I need to use different properties. Do I have to have two UserManagers or I should parse like that every time var user = (PersonUser) await this.userManager.GetUserAsync(this.User);?

Here are my classes:

public class ApplicationUser : IdentityUser, IAuditInfo, IDeletableEntity
{
    public ApplicationUser()
    {
        this.Id = Guid.NewGuid().ToString();
        this.Roles = new HashSet<IdentityUserRole<string>>();
        this.Claims = new HashSet<IdentityUserClaim<string>>();
        this.Logins = new HashSet<IdentityUserLogin<string>>();

        this.Notifications = new HashSet<Notification>();
    }

    // Audit info
    public DateTime CreatedOn { get; set; }

    public DateTime? ModifiedOn { get; set; }

    // Deletable entity
    public bool IsDeleted { get; set; }

    public DateTime? DeletedOn { get; set; }

    public virtual ICollection<IdentityUserRole<string>> Roles { get; set; }

    public virtual ICollection<IdentityUserClaim<string>> Claims { get; set; }

    public virtual ICollection<IdentityUserLogin<string>> Logins { get; set; }

    [Required]
    public string Password { get; set; }

    public UserType UserType { get; set; }

    public virtual ICollection<Notification> Notifications { get; set; }
}

public class PersonUser : ApplicationUser
{
    public PersonUser() : base()
    {
        this.Bids = new HashSet<Bid>();
        this.Buildings = new HashSet<Building>();
    }

    [Required]
    public string FirstName { get; set; }

    [Required]
    public string LastName { get; set; }

    public DesignerType DesignerType { get; set; }

    public virtual ICollection<Bid> Bids { get; set; }

    public virtual ICollection<Building> Buildings { get; set; }
}

public class CompanyUser : ApplicationUser
{
    public CompanyUser() : base()
    {
    }

    [Required]
    public string CompanyName { get; set; }

    // That is like Id of the company
    [Required]
    public string Bulstat { get; set; }
}

CodePudding user response：

There's two different scopes of problems related to having different "Types" of users in your application.

Permissions / Authorization

This is the scope for what different types of Users are allowed to do. What endpoints are they allowed to call? What are they allowed to acces?

For this problem scope you want to use IdentityRoles in order to distinguish said users

Database Relationships

This is the scope when the different types of Users will have genuinely distinct links in the database to different tables. For example for your SchoolDatabase, you may have TeacherUsers which have One to Many relationship with StudentUsers, and vise versa, but both types of users can login.

In this case you actually want to have different classes to distinguish them that inherit from a base User class.

Table links both types of users share, for example perhaps both a Teacher and a Student have a Classroom they belong to, you would put on the base class. Also chances are things like Password, Login, UserName, Email, etc would all go on the BaseUser class since everyone has such things.

Table links that are *uniqueto one type of user would go on that users table. So if Teachers have aCurriculum` then you would add a link between Teacher<->Curriculum, not BaseUser<->Curriculum, and if Students have Homework (but Teachers dont), then that link would be to the Student table specifically.