Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Why IdentityUser and IdentityRole are defined in Microsoft.AspNet.Identity.EntityFramework? #489
Why IdentityUser and IdentityRole are both defined in Microsoft.AspNet.Identity.EntityFramework?
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.
+1, me too.
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.