CODEWITHSUNDEEP
c#asp.net-coreasp.net-core-mvcentity-framework-coreclean-architecture
Blake Rivell
Blake Rivell

Reputation: 13885

Referencing ApplicationUser in the Infrastructure library from an entity in the ApplicationCore library using Clean Architecture

I am following the Microsoft Architecture Guide for creating an ASP.NET Core Web Application.

The guide implements the clean architecture pattern which is pretty straight forward.

If you look at the sample project which is using the clean architecture pattern you will see that there is an Infrastructure/Identity folder that contains the ApplicationUser.cs class.

My issue:
I am using Entity Framework and one of my Business Entities in the ApplicationCore class library needs to contain a list of ApplicationUser. The ApplicationCore library shouldn't be referencing any other projects. It contains all of the Interfaces and Business Entities. How can I keep the ApplicationUser class in my Infrastructure/Identity project and still use it in one of my business entities in the ApplicationCore project without breaking the rules.

I know one solution is to not store the ApplicationUser entity in my Infrastructure project. However, I feel like it should be there since it will always rely on Identity as it implements IdentityUser.

Upvotes: 14

Views: 3306

Answers (3)

Marzouk
Marzouk

Reputation: 2713

This is my own problem as well and it seems opinion based somehow. I end up that if you are depending on any package that has a DbContext specified inside it, so you will reference this package in your Core project.

For example, I am using AspCore.Identity and IdentityServer4 and I have many DbContexts for that but let's say two for now:

ConfigurationDbContext and IdentityDbContext and those two contexts control two entities (just for making things easier) Client (The OAuth2 Client) and IdentityUser So now and I already have all of that as Infrastructure but now I want to have my own Core Entities ApplicationUser and ApplcationClient so how can I put those in my Core without letting them inherited their parents so I can query against them, save them or retrieve them from any source.

I don't know exactly the perfect answer for that but I end up putting those entities in the Core and reference the NuGet packages in my core which obviously not follow the clean architecture roles but I couldn't find a better solution than that.

Upvotes: 0

Sasan
Sasan

Reputation: 4230

User is an entity and it should be in Core layer.

But you shouldn't use ApplicationUser : IdentityUser in the Core layer because it's tied up to the ASP.NET Identity. The Core layer should not know what technologies are going to implement the domain.

What if tomorrow you want to use another library for user management? That's not the Core layer's concern.

What you can do is to use an interface or base User class in the Core layer and let the Infrastructure layer be worried about the library choice decision.

Upvotes: 5

Khai Nguyen
Khai Nguyen

Reputation: 945

In Clean Architecture:

Application Core Types

• Entities (business model classes that are persisted) and Aggregates

• Interfaces

• Services

• DTOs

• Specifications

• Exceptions

Infrastructure Types

• EF Core types (DbContext, Migrations)

• Data access implementation types (Repositories)

• Infrastructure-specific services (FileLogger, SmtpNotifier, etc.)

So the ApplicationUser.cs is an entity, it shouls be in Application Core

Upvotes: 0

Related Questions