New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DmitrySikorsky opened this Issue Jun 12, 2015 · 4 comments

Comments

Projects
None yet
5 participants
@DmitrySikorsky

DmitrySikorsky commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@OlegDokuka

OlegDokuka Jun 12, 2015

+1, have same issue!! Help us!

OlegDokuka commented Jun 12, 2015

+1, have same issue!! Help us!

@c1rus

This comment has been minimized.

Show comment
Hide comment
@c1rus

c1rus Jun 12, 2015

+1, me too.

c1rus commented Jun 12, 2015

+1, me too.

@jspengine

This comment has been minimized.

Show comment
Hide comment
@jspengine

jspengine Jun 12, 2015

+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.

jspengine commented Jun 12, 2015

+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

This comment has been minimized.

Show comment
Hide comment
@divega

divega Jun 12, 2015

Member

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.

Member

divega commented Jun 12, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment