gdyrrahitis
gdyrrahitis

Reputation: 5968

AspNet Identity ApplicationUser with subtype-specific fields

I have a ASP.NET MVC application which uses ASP.NET Identity. I have 3 roles for my application:

Those 3 profiles have various fields to persist, so Student role could have X number of fields, Author role, Y number of fields and Admin role, Z number of fields, all unrelated to each other. Problem is that I cannot think a way to make an elegant design.

Here is what I have tried/though so far:

First I though of creating 3 different classes (for each role), so essentially I'm going to have Student, Author and Admin table, which have an 1:1 relationship with ApplicationUser table, but this is not a clean solution at all.

This is what I've implemented at the moment. I have an ApplicationUser class (table) which holds all the common fields of these three roles. For each of them I have created a class (table) having a 1:1 relationship with ApplicationUser (which acts as "base" class (table))

Another solution I came up was to persist those data on a schema-less storage (for example Table Storage) with PartitionKey the ApplicationUser.Id and RowKey the RoleId, so I can CRUD each entity with ease. Although this might help, this approach could lead to maintain 2 different datasources, which is not what I am looking for.

Any suggestion on clean design for this?

UPDATE

From research I get that a model inheritance/supertype-subtype association is probably a good way to go. Especially going with the one table implementation seems good on performance also. For example:

Could lead to many null values for subtype-specific fields, but seems like a good workaround. Any other suggestion?

Upvotes: 1

Views: 146

Answers (1)

Zacharopoulos Sotiris
Zacharopoulos Sotiris

Reputation: 21

I think your approach is quite good. An alternative could be to use asp.net Identity's UserClaims like approach.

In this approach you don't need to have specific fields for each role but a table with 4 columns in which you are going to store

  • user's FK
  • attribute's data type
  • attribute's name
  • attribute's value

---------------------------------
| FK |  Type  | Name | Value    |
---------------------------------
| 1  | string | name | John Doe |
---------------------------------
| 1  |  int   | age  |    30    |
---------------------------------

Below you can see an example of what a controller's action could accept as parameter (I made the assumption that name and age is fields that you need only for a Student).

{
  id:1, 
  updatedOn : '2016-01-01 00:01', 
  role:'Student', 
  extraFields : {
                  name:'John Doe', 
                  age : 30}
}

Upvotes: 2

Related Questions