You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2018. It is now read-only.
Would it be possible to make the IdentityUser class implement an IIdentityUser interface, and for the other ASP .NET Identity classes to expose and reference instances of the IIdentityUser interface instead of the IdentityUser class?
The way it is now, my ApplicationUser class lives in my Persistence namespace because it inherits IdentityUser, which resides in Entity Framework. I need to reference the ApplicationUser class in controllers such as AccountsController and ManageController, which means that now my controllers are tightly coupled to Entity Framework too. I would prefer to make my controllers dependent on my Core library, and be persistence ignorant.
I love Entity Framework and ASP .NET Core Identity and want to use both, but I also want to be loosely coupled to them so that I can, if I want, remove Entity Framework but still use ASP .NET Core Identity.
Microsoft.AspNetCore.Identity.IIdentityUser
where TKey : IEquatable
...so that my ApplicationUser class can continue to inherit from Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityUser....
....but my controllers can instead reference any implentation of Microsoft.AspNetCore.Identity.IIdentityUser
...then they can reference only MyProject.Core and not have to reference MyProject.Persistence.
Please could anybody advise if this is a good idea. If not, why not, and what's the alternative way?
Many thanks for your consideration
Benjamin
The text was updated successfully, but these errors were encountered:
BenjaminCharlton
changed the title
ake the IdentityUser class implement an IIdentityUser interface
Make the IdentityUser class implement an IIdentityUser interface
Apr 27, 2017
This is the issue we are using to track some refactoring we will do. We aren't going to be adding an interface, as we like the ability to work with any kind of POCO.
That said, we will probably be moving IdentityUser to some kind of base common Provider package that the EF package will derive from, so you won't be forced to pull in EF just to have access to IdentityUser
I read about #883 and other related issues with great interest. Is there a way I can receive a notification when this is addressed so I can try out the new version and see if it solves my problem? Advice would be appreciated.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Would it be possible to make the IdentityUser class implement an IIdentityUser interface, and for the other ASP .NET Identity classes to expose and reference instances of the IIdentityUser interface instead of the IdentityUser class?
The way it is now, my ApplicationUser class lives in my Persistence namespace because it inherits IdentityUser, which resides in Entity Framework. I need to reference the ApplicationUser class in controllers such as AccountsController and ManageController, which means that now my controllers are tightly coupled to Entity Framework too. I would prefer to make my controllers dependent on my Core library, and be persistence ignorant.
I love Entity Framework and ASP .NET Core Identity and want to use both, but I also want to be loosely coupled to them so that I can, if I want, remove Entity Framework but still use ASP .NET Core Identity.
How about....
Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityUser
...implements...
Microsoft.AspNetCore.Identity.IIdentityUser
where TKey : IEquatable
...so that my ApplicationUser class can continue to inherit from Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityUser....
....but my controllers can instead reference any implentation of Microsoft.AspNetCore.Identity.IIdentityUser
...then they can reference only MyProject.Core and not have to reference MyProject.Persistence.
Please could anybody advise if this is a good idea. If not, why not, and what's the alternative way?
Many thanks for your consideration
Benjamin
The text was updated successfully, but these errors were encountered: