How to create different user types in ASP.NET Identity?

Question

I'm new to web development. Now I learn ASP.NET MVC 5 with ASP.NET Identity. Can you give me some advices in my situation:

In my site I want to have some types of users. For example: Buyer Seller

Each of them can login and control his part of information.(e.g. Buyer can change his info, add requests. Seller also can change his own info and add goods)

Now, i create something like that:

using Microsoft.AspNet.Identity.EntityFramework;
using System.Data.Entity;

public class ApplicationUser : IdentityUser
{
    public int? BuyerId { get; set; }
    public int? SellerId { get; set; }

    public virtual Buyer Buyer { get; set; }
    public virtual Seller Seller { get; set; }
}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection")
    {
    }

    ...

}

When we create a user he get some role and property with information(e.g. if it's buyer he will have role "Buyer" and some Buyer property(and Seller will be null).

Is it a normal approach?

UPDATE:

I think I picked a bad example(with Seller and Buyer). In my case I have something like recomendation system(another example):

1. First Type of User, who can add info about himself and find some ITEMS(e.g. Fruits)
2. Second Type of User, who add this ITEMS(with additional information) (e.g. apple, pear ,Grapes. Other(second type of user) add vegetables)
3. Last type of User, who can add some additional information(e.g Cities)

The system can determine the user's preferences (some vegetables or fruit) on the basis of additional information about the user(e.g. recent experience and etc) and items(e.g. kind, cost and etc)

Answer 1

No. That's not how you want to handle this. Users are users. If you have a true distinction in capabilities, you can use roles, but in most systems like what you're describing, being a "buyer" or a "seller" is not really a black and white thing: those who buy stuff, may eventually like to sell, and sellers may actually want to buy something. My recommendation would be to not make any distinction at all. If you want to just have some approval process or something before someone can sell, then you can, again, just use a "seller" role and only those who have been added to that role will see seller options.

If you need to store information that's unique to being a buyer or a seller, then you can also use claims, which are far more flexible than adding additional properties to your user model and definitely far more flexible that creating actual foreign key relationships to store extra data.

Answer 2

You should take a look at Membership- and RoleProviders, Microsofts standard way of dealing with this.

You can then choose one of two options.

1. If you want to take the easy way you use Microsofts standard way of storing users and roles in a SQL Database, and you get a Web User Management for that.

2. If you already have a lot of users and roles in a custom system, then you might want to look into writing custom membership- and roleproviders that can map your existing users and roles with what you want to do in your site. See an example of this here.