Understanding Asp.Net Identity Interface Design Strategy

Question

All I*Store<TUser> interfaces provided in Asp.net Identity Framework are inheriting from IUserStore<TUser>. This force the implementation of every interface to implement User related methods or have single class inherit them all.

• IUserClaimStore<TUser>
• IUserPasswordStore<TUser>
• IUserLoginStore<TUser>
• IUserSecurityStampStore<TUser>

If I need to provide different storage for Logins or Passwords or Claims or SecurityStamps, say an Xml storage instead of EF or any DB, I need to implement User related methods too (User: CreateAsync, UpdateAsync, DeleteAsync, FindByIdAsync, FindByNameAsync).

So, what can be the strategy behind providing this architecture?

Answer 1

IUserStore<> defines CRUD operations:

public interface IUser
{
   string Id { get; }
   string UserName { get; set; }
}

public interface IUserStore<TUser> : IDisposable where TUser : IUser
{
   Task CreateAsync(TUser user);
   Task DeleteAsync(TUser user);
   Task<TUser> FindByIdAsync(string userId);
   Task<TUser> FindByNameAsync(string userName);
   Task UpdateAsync(TUser user);
}

As each I*Store<TUser> has to offer the full set of CRUD methods (after all what use would something like a IUserPasswordStore<TUser> be if you couldn't Find or Update an entry?) so they each implement IUserStore.

You can implement these interfaces and control how the account data is stored. You can customise the user account data, e.g. if you want more data associated with your user you add it to your custom user class that implements IUser and the extra data can be stored by your implementation of IUserStore.