jasontaylordev / RapidBlazor

Clean Architecture Solution Template for Blazor WebAssembly .NET 7
MIT License
291 stars 53 forks source link

Dependency Inversion #5

Open vcifello opened 1 year ago

vcifello commented 1 year ago

Thank you for your ongoing efforts with clean architecture and this template especially. I hope you can take a moment to clarify.

You have clearly explained that Dependencies should flow towards the core with the only caveat being references in startup.cs to enable dependency injection from another layer.

Therefore, IIdentityService is defined in Application, but the implementation is defined in Infrastructure. This allows dependency injection of this implementation without a dependency going outward to Infrastructure. I think this is a correct understanding.

However, WebUI defines the ViewModels/DTOs that the Application and infrastructure layers use. This results in dependencies on WebUI (Shared) in Application and Infrastructure.

For example, https://github.com/jasontaylordev/RapidBlazor/blob/main/src/Infrastructure/Identity/IdentityService.cs

using RapidBlazor.WebUI.Shared.AccessControl; using RapidBlazor.WebUI.Shared.Authorization; using RapidBlazor.WebUI.Shared.Common;

This seems to violate dependency inversion as Application and Infrastructure must now depend on WebUI.Shared. The above case uses UserDto.

It seems that an object that is used in all layers should be in core. Then the consumers of the core would be responsible for mapping domain defined objects to their preferred format (ViewModel/DTO). Otherwise, the outer layer projects force the Core and Infrastructure to use objects defined elsewhere resulting in outward flowing dependency. This violates dependency inversion principle and makes Infrastructure and Application layers unusable without the WebUI reference.

I apologize if I have completely missed something obvious, but I really would like to fully understand this architecture,

Thanks in advance for clarifying this.

achmstein commented 1 year ago

Hi, I do think that there's no problem in this approach because we're not referencing the WebUI itself. We're referencing the Shared project that's a plain class library. Suppose that we have a "Common" class lib project and then we defined AccessControl, Authorization and Requests/Dtos inside it, then we can reference it from WebUI and Application layer without violating dependency inversion, Correct? @jasontaylordev