MVC 5: Should I inherit my User from IdentityUser

Question

I was trying to learn Asp.Net Identity and in this tutorial,

Create an Entity Framework Code First ToDo model in Models\AppModels,cs part MyUser class inherits from IdentityUser class and MyDbContext inherits from IdentityDbContext<MyUser> class. Why is that?

Lets say I have a User class that holds all the information of the user of my web application, should that class inherit from IdentityUser, and should my DbContext inherit from IdentityDbContext<User>?

Also, what are the advantages of inheritng dbcontext class from IdentityDbContext<TClass> over plain DbContext class as done in MVC 4

Answer 1

The IdentityDbContext<> class is a class that inherits from DbContext as you would usually do but provides ready DbSets for Roles and Users.

See class doc here: http://msdn.microsoft.com/en-us/library/microsoft.aspnet.identity.entityframework.identitydbcontext%28v=vs.111%29.aspx

Yes, your user dto should inherit from IdentityUser and any additional fields you want in your database associated with your user can be added to that class.

This makes it much easier to add additional fields to your database that are associated with your user and if you are using Entity Framework migrations and database initializes it means that you can now generate the entire Identity database from your DbContext.

Answer 2

ASP.Net MVC 5.0 uses OWIN implemenation for plug and play.

There are couple of interfaces designed for this

FROM Scott Allen Article

IUser

A user object must implement the IUser interface, which requires every user to have at least an ID and a name. The most notable aspect of IUser is the Id property of type string. Strings work well for GUIDs but can be a bit tricky when using integers for keys as is common with SQL Server. More details in a future post.

IUserStore

The I*Store interfaces in the Core Identity assembly are factored to offer various levels of functionality.

IUserStore defines the bare minimum functionality you’d want for users – create, retrieve, update, and delete (CRUD) functionality. If your website wants to allow users to create local accounts with passwords, you’ll want a component implementing IUserPasswordStore (which is an IUserStore). For third party logins (Twitter and Facebook, for example), add in IUserLoginStore, and for claim storage there is an IUserClaimStore. Also, not shown in the class diagram above, is a collection of interfaces for roles (IRole, IUserRoleStore, etc). Let the debate on roles versus claims begin.

UserManager

The UserManager is a concrete class and it is the UserManager that provides the domain logic for working with user information. The UserManager knows when to hash a password, when to validate a user, and how to manage claims.

There are a few extensibility points with the UserManager, for example, the manager has a number of properties you can use to set a custom user validator (any object implementing IIdentityValidator), a custom password validator, and a custom password hasher. The primary extensibility point is via the UserManager constructor, which allows you to pass in any object implementing IUserStore. If you want to use a UserManager to manage user information stored in SQL Server, we’ll look at pre-built classes to do this in a later post, but it is also easy to create an IUserStore to work with a document database or other forms of storage.

Remember an IUserStore doesn’t know how how to work with user passwords, only an IUserPasswordStore knows about passwords. The UserManager is aware of the different core interfaces and will try to work with the capabilities of the store object given in the constructor. For example, if you use FindByIdAsync the UserManager can use the user store to query for a user by ID, but if you invoke FindAsync (which takes a username and a password), and the underlying store doesn’t implement the IUserPassword store interface, the UserManager will be forced to throw an exception.

It’s tricky to use a single concrete class for everything from users to passwords to claims, and tradeoffs must be made. We’ll also look at some of the tradeoffs in upcoming posts.

EDIT: Check out Implementing ASP.Net Identity

Now ASP.Net identity supports generic IdentityUser<TKey> before it was a string,i.e UserId was a string