Should IdentityUser be in the EntityFramework namespace? about identity HOT 6 CLOSED

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.

from identity.

@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?

from identity.

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.

from identity.

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.

from identity.

@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?

from identity.

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

from identity.