2

I have a site in which I have customers and operators. Both need to be registered. The customer is derived from IdentityUser and is extended with all kind of customer information fields like address and birthdate. For the operator I need completely different information, for example department.

First I had an ApplicationUser object (derived from IdentityUser), a Customer object with a reference to the ApplicationUser object (1:1 relationship, not enforced) and a Operator object also with a reference to the ApplicationUser object.

I am wondering if this is the correct way. I wondered if it is not possible to have an CustomerUser object derived from IdentityUser and a OperatorUser object also derived from IdentityUser.

Basically the question is how to handle several types of users in an MVC6 ASPNet5 application using AspNet Identity. I specifically am not looking on how to use roles as that will still does not answer on how to handle the different properties set.

Mounhim
  • 1,674
  • 1
  • 17
  • 32

1 Answers1

2

You're asking the classic question of composition versus inheritance. Usually, the best advice here is to prefer composition over inheritance. Sometimes composition can seem unintuitive... our brains tend toward the mental model of "an operator is a user" and "a customer is a user". But you can just as easily model the relationship as "a customer/operator (or other system role) that has user credentials".

It's hard to say one is more correct than the other, but using composition will fit better with EF's ORM impedance mismatch than will class hierarchies for your entity model. You just have to be more careful about modeling the relationships (directionality, cardinality, etc) and about null references when querying.

danludwig
  • 46,965
  • 25
  • 159
  • 237