[Discussion] Clean Architecture - is it really?

[HydraulicCamel]

Hi everybody,

First I want to thank @jasontaylordev for his great lecture and for starting this repo. 💪🏻
I am sure it helped a lot of people as it certainly helped me.
Same goes for all the devs who invested their time contributing to this project.

Now for my trollish post about what I see as a contradiction between the concept of the Clean Architecture and its real world Implementation:

In his lecture, @jasontaylordev talks about the familiar onion drawing, representing the topography of this architecture.

The The concept of this approach is quite simple:
every layer should only consume layers that are closer to the core via abstraction/di, and (in most cases) should only reference the inner most layer - the domain/core, containing most of the abstractions and pocos (dtos, entities, models ect).

one necessary exception is the presentation layer - which is the entry point for the application. This is where the composite root is traditionally declared, which means it has to reference all other layers (or projects) in our solution in order to register all the abstractions with their implementations.

The persistent layer (containing the data access implementation and framework) is always drawn as part of the external layer (along with the presentation and infrastructure).

This contradicts the desired 'flow' of consumption that is suggested by this architecture.
The data access in the persistent is being consumed by the inner layer - the application layer, which contains the core business logic of our application.

Things get worst when using EF.
As dbContext is almost impossible to fully abstract, it must be added/referenced within the consuming layer(s).

In the NorthwindTraders solution, INorthwindDbContext interface is used as a (semi) abstraction for dbContext.
This is a leaky abstraction as it contains DbSet - which is a part of Microsoft.EntityFrameworkCore namespace.

This means we have to add EF package into multiple layers (and project in our solution):

1. The Application project/layer (where it is consumed).
2. The WebUI project/Presentation layer (for the composite root).
3. The Persistence project/persistent layer (where dbContext is configured).

I just cant see how this approach is an improvement over the N-layer architecture as some people suggests.

What am I missing?
Any input is welcomed

[andrewtsw]

Hey @HydraulicCamel
I believe that dependency from the EF Core does not equal dependency from the persistent layer.
The dependency rule works in this case: the application layer can not depend on the data access layer. But it depends (it uses) data access interfaces.
And there is no reference from the Application to Persistence.

But data access interface uses DbSet and depends on EF Core. Is it correct to add EF Core to the application layer?
I believe it is correct because you do not need a repository over DbSet.
The author of the "Entity Framework Core in Action" book suggests adding an EF Core to the Domain layer. I do not think that EF Core in the domain is a good idea. But EF Core in the application works great.
Because you do not use SQL server directly from your code.

What do you think about it?

[Oleg Varlamov]

Hi!

I think that although there is no direct dependency, the dependency on the Data Persistence framework (EF) has "leaked" into the Application layer. If (at some stage of development) it becomes necessary to change the implementation of the repositories to use NHibernate, Dapper, or pure ADO.Net, then we will face many problems. At a minimum, the current interface assumes that the repository implementation can translate Expressions into queries to the Storage, which is not always true. Moreover, the dependency on EF clearly says that you have to use a SQL-oriented database as Storage. The current limitation will not allow me to store data in files, Redis or MongoDB, which I would like to be able to do.

Again, Jason said that it is bad practice to use EF attributes in domain entities - the framework "leaks" to the domain level. So why do we agree that the leaking framework to the Application layer is acceptable?

I believe that in this case, it is worth getting rid of the dependency on EF at the Application level.

[Stan Martens]

A lot of valid points have been made in this thread, but I believe Jason has chosen this approach with EF Core for the sake of simplicity. Does this comment provide enough insight?

[Jason Taylor]

Thank you for your interest in this project. This repository has been archived and is no longer actively maintained or supported. We appreciate your understanding. Feel free to explore the codebase and adapt it to your own needs if it serves as a useful reference. If you have any further questions or concerns, please refer to the README for more information.