Why IdentityUser and IdentityRole are defined in Microsoft.AspNet.Identity.EntityFramework?

[DmitrySikorsky]

Hi guys!

Why IdentityUser and IdentityRole are both defined in Microsoft.AspNet.Identity.EntityFramework?
If User (derived from IdentityUser) is my model (I want to have and manage the list of the users in the admin section for instance), I don't want to have any links to the specific ORM in the models! It makes it impossible to have modular project with unknown ORM.

And with this new approach to the ClaimsPrincipal user it is hard to replace Identity with the custom security provider...

How can I make User and Role models ORM-independent OR how can I replace the Identity with the custom security classes? I don't want to have useless User property in the controller and create another one for me.

Thank you for you attention and for the help.

[OlegDokuka]

+1, have same issue!! Help us!

[c1rus]

+1, me too.

[jspengine]

+1, me too.
Em 12/06/2015 12:12, "Dmitry Sikorsky" notifications@github.com escreveu:

Hi guys!

Why IdentityUser and IdentityRole are both defined in
Microsoft.AspNet.Identity.EntityFramework?
If User (derived from IdentityUser) is my model (I want to have and manage
the list of the users in the admin section for instance), I don't want to
have any links to the specific ORM in the models! It makes it impossible to
have modular project with unknown ORM.

And with this new approach to the ClaimsPrincipal user it is hard to
replace Identity with the custom security provider...

How can I make User and Role models ORM-independent OR how can I replace
the Identity with the custom security classes? I don't want to have useless
User property in the controller and create another one for me.

Thank you for you attention and for the help.

—
Reply to this email directly or view it on GitHub
#489.

[divega]

I don't want to have any links to the specific ORM in the models! It makes it impossible to have modular project with unknown ORM.

Thanks for the feedback. This is intentional, and I will try to explain why:

One of the design goals of ASP.NET Identity is to be able to work with a wide range of data stores and data access technologies, i.e. not only those which support "perfect persistence ignorance" but also many that do put constraints on the types used for persistence. Trying to define IdentityRole, IdentityUser, etc. (and even your application domain objects) in a way that they are completely independent of the store or O/RM may sound like a very commendable goal but in practice it can only work (and work efficiently) with a limited set of persistence technologies that are similar enough among themselves to be able to use the same types.

Instead of trying to decouple the entity types from the store implementation, ASP.NET Identity chooses to decouple store implementations (which are considered include the entity types) from the Identity core APIs. Hence, even if the IdentityRole and IdentityUser defined in Microsoft.AspNet.Identity.EntityFramework look like POCOs they are actually optimized for the Entity Framework 7 implementation of the store.

If you want to create your application in a way that works for unknown O/RMs – or to make the problem more manageable, for a set of known O/RMs – and you need to include the persistence of ASP.NET Identity into that, my recommendation would be is to create your own implementation of an ASP.NET Identity store. It is not really that hard and it will give you much greater control over how the entities look like. You can use our source code as a starting point, if that helps.

By the way, we actually used to have the entity types defined in the core but they were just an example of entity types that you could use, and this caused confusion for people trying to write store providers. We got very sound feedback that encouraged use to move them to Microsoft.AspNet.Identity.EntityFramework: #332.