0

Consider the well known example data-model that contains courses and instructors. A course has one instructor has many courses. Suppose now we want to base this model on the ASP.NET Identity model which has users and roles. A straightforward way would be to let instructors inherit from an ASP.NET Identity user. However, let's say we want the janitor of the school to also be a user of the system. Moreover, nothing prevents an instructor from being a janitor in the afternoon.

There's no multiple inheritance, so you cannot be, say, an InstructorUser and a JanitorUser. A user has only courses if his role is that of an instructor, so it is IMO not a clean approach to have every user have a relationship to courses (he might not be an instructor after all). I'm considering to create a separate instance of InstructorRole (inheriting from IdentityRole) for each an every user, if he is an instructor.

I see that simple examples have a low number of generic roles, such as "admin" or "guest". Is it a bad practice to have at least one separate role for each user?

Daniel C. Weber
  • 1,011
  • 5
  • 12

1 Answers1

1

Problem with these roles is what you are going to do with them?

If your roles are for limiting access to controllers, then how would you define permissions on controllers for (possible) infinite number of users/roles?

I'd go back to your drawing board and re-think how your permission system works and what it is actually required.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • Purpose of these roles is to store properties/relations that a user has if and only if he assumes that role. Given that requirement, how would you model it without having an unbounded number of roles ? – Daniel C. Weber Jan 12 '15 at 10:24
  • If these are properties of a user, why not have them as actual properties on `*User` object? Identity can do that with not much effort. Alternatively if every user requires a different set of properties, store them as Claims - these require less maintenance. – trailmax Jan 12 '15 at 10:26