I have a ProjectName.Core
library containing all my business logic and my entities and their behaviour. There's currently no relation whatsoever to Entity Framework or any other DAL because I like to keep those things seperated. The Entity Framework configurations (using the Fluent API) reside in a ProjectName.Infrastructure
project so that takes care of pushing my entities into EF. Basically I'm going in the direction of an Onion-like architecture.
However, when adding the ASP.NET Identity framework into the mix, I have to make my ApplicationUser
entity inherit from the IdentityUser
class but my ApplicationUser
class has relations to other entities. In inheriting from IdentityUser
I'm introducing a reference to Entity Framework in my entities project, the one place where I wouldn't want to do so. Pulling the ApplicationUser
class out of the entities project and into the Infrastructure
project (since it is using an Entity Framework based identity system) will result in circular references, so that isn't the way to go either.
Is there any way around this so I can keep the clean seperation between the two layers besides not using ASP.NET Identity?
Best Answer
You can create a User class that has nothing to do with ASP.NET Identity in your core library.
If you're using Entity Framework, create a configuration class for your entities (optional).
You'd have to also create classes for Role, UserClaim, and UserLogin. You can name them whatever you choose if you don't like the above names.
In the web layer, create a class called AppUser (Or another name if you choose). This class should implement the ASP.NET Identity IUser<TKey> interface, where TKey is the data type for the primary key (Guid in the above example).
Change all references to UserManager in the web project to UserManager<AppUser, Guid>.
Finally, create your own UserStore. Essentially, the custom UserStore will take in the AppUser object, convert it to an User entity object, then persist it. An example of one of these methods is shown below:
To get a full description of a possible implementation, click here.
In the end, it's your choice. Measure the amount of effort it would take for you to maintain this implementation versus just referencing the Identity framework in your Core library. Personally, I thought of doing it the way I described above, however, I didn't because I'd potentially have to change my code every time the ASP.NET Identity framework is updated.
Hopefully this helps and answers your question!