Adding ApplicationUser as Navigation Property to entities

[pashaie]

Hi,
In Onion Architecture we are supposed to put entities in Domain layer. But ApplicationUser is on Infrastructure layer and that prevents us from adding ApplicationUser as Navigation Property to entities. Is there any best practice for doing it?

[iammukeshm]

Hi,

ApplicationUser inherits from IdentityUser, which again has a dependency on Microsoft.AspNetCore.Identity package. If we were to add the ApplicationUser to Domain / Core Projects, this would add an additional dependency to the Core Layer which is not desirable. Here, ApplicationUser cannot be treated as an entity.

Instead, we have an adapted class / dto named as UserDetailsDto.

ApplicationUser is more of a secured model and should not be used as Navigation Property.

[pashaie]

Thanks,
I'm aware of additional dependency that it will add to Core Layer, and I'm not suggesting to do that.
But, we have entities that have relationship with user table, for enabling foreign key we can use EF model builder, but that doesn't help with joined queries.
One solution that comes to mind is to create views in DB and using dapper we can have our data.
But I was wondering if there is any other solution or best practice for such scenarios

[dotnetshadow]

I think perhaps having an example in the project, where you have the products / brands createdby returning with the username would clear up this question (which comes up very often). I can see many applications having a need to show the username who created / edited the resource.

[justSteve]

@pashaie I'd second the notion that the db include artifacts that extend (support?) Table-based objects. Not just Views but Sprocs as well. These are 1st class db citizens and any production db would employ them. Usage should be presumed.