Should IdentityUser be in the EntityFramework namespace?

[yetanotherchris]

https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.entityframeworkcore.identityuser?view=aspnetcore-1.1

I'm looking through various implementations from the readme and I've noticed they all use IdentityUser for their concrete type to pass to UserManager, or have had to craft a custom type to be able to have a contract between the database and the .NET AspNetIdentity implentation they've written (see the DynamoDB library).

I've had to do this too for the Marten implementation I've written, and the reason is, a TUser that your UserStore takes, should really be an interface - it will always have an email, most likely an Id of some sort, firstname, lastname and then a bag of properties.

Things become even more abstract when dealing with claims.

If everyone is using IdentityUser or their own custom TUser doesn't this defeat the purpose of AspnetIdentity - which is to be able to switch and change implementations easily? That isn't possible if your consumer is tightly coupled with a TUser implementation of the library.

Example TUser implementations

• MongoIdentityUser
• DynamoIdentityUser
• Redis uses IdentityUser<string>

[blowdart]

The purpose of ASP.NET identity was to be a starting point, changing implementations wasn't even on the board, especially as there only was one implementation to begin with. ApplicationUser was a class in the templates folks could edit to their hearts content, laying an interface on top of that, when the only really commonality would be an id (some people don't use emails) was adding complexity for no real gain.

[yetanotherchris]

@blowdart As the library deals with TUsers I'd say you can be fairly confident they'll have a first and last name (culture dependent), an email, a username, id, and then other attributes.

The contract of the UserManager implies this by the methods, such as the find ones.

But is the advice therefore to use EF with the library? Is that the assumed usage?

[blowdart]

Believe it or not email address isn't a requirement, even though we assume it. We've had issues about everything keying off email address when some users want phone number as the unique identifier instead (mainly from China).

We assume EF for our stores, those not wanting to use EF we advise to implement the store interfaces.

[HaoK]

Just to clarify things, we did do some work in 2.0 to enable non EF based stores to use our POCOs.

We moved the pocos into a standalone Stores package which also has some base implementations that are not EF specific but tied to our POCO classes: https://github.com/aspnet/Identity/tree/master/src/Stores

Our EF based stores derive from the store base classes and implement the abstract methods using EF. So there's something in between implementing the interfaces yourself, and always using EF as of 2.0.

Identity pre core had a IUser interface and one of the big changes moving to core was to eliminate that interface to allow identity to work with arbitrary POCO user types.

[yetanotherchris]

@HaoK and @blowdart I'm writing a user and role manager for Roadkill but wanted to make it more generic - so my intention is write a general user manager as a Razor class library.

Without knowing about a basic TUser this isn't really feasible is it? Should I abandon the hope of making it generic and instead focus on a specialised user and role object?

[blowdart]

Honestly I'd abandon all hope here, it's one of the reasons we don't write a user manager, as soon as people customise it's an exercise in frustration