Dependency injection between business layer and presentation layer

Question

I am trying to follow clean architecture in my software. I have implemented 3 layers: data layer, business layer and presentation layer.

As far as I understand dependency will follow outside to inside like P->B->D.

But my question is should I do a singleton data layer executor injection into presentation? Doesn't that break this logic?

Or without DI, only create an abstraction between layers I think creates tight coupling.

So referring to some data layer dependency from inside the business layer - doesn't that make the layers tightly coupled?

public class ViewModel<T> extends GenericRouter {
 IPresentation ip = new BusinessUseCaseImpl();
public abstract class BusinessUseCase<T extends HashMap> implements IPresentation<T> {
UserRepository urepo = new UserRepository();

Answer 1

In the clean architecture, the inner layers are logic, not infrastructure.

When the business layer instantiates the data layer, it injects any infrastructure dependencies that it requires.

Similarly, when the presentation layer instantiates the business layer, it passes in any infrastructure dependencies that it requires. This is how the business layer gets the infrastructure it needs to pass to the data layer.

And initially, when the application/system instantiates the presentation layer, it passes in the infrastructure that it will need. The humble object pattern should be used to implement these dependencies, because they are the only part of the system that can't be tested independently from infrastructure.

Answer 2

It depends on what you mean by "tight coupling". Following the 3 layered architecture is ok for the data layer to be a dependency on the business layer and the business layer to be a dependency on the presentation layer.

Instead of injecting a concrete class, you can always define the dependency injection on an Interface. With this, you can always switch the implementation as long as you follow the agreed interface.

However, my experience tells me that you rarely or never do this for a basic and regular 3 layered architecture. You have always a single Service and a single Repository/DAO implementation so having an Interface for each of them is kind of redundant and useless.

I think that the most important thing when you work with 3 layered architecture is to never bypass layers. Examples:

1. You should never make the presentation layer depend directly on the data layer. Always go through the business layer.
2. The relation between the layers should be always 1:1. This means you should never make a Controller call a Service that is associated with another Controller.

Not following these rules will for sure make your code incredibly hard to read and understand. Of course, for every rule, there is an exception, but try to stick to them.

• wipesax360: yes , right now presentationlayer instanties an abstract class(implements an interface for pressntationlayer) which resides inside the business layer for example, is that wrong?,,, also presentation goes to business layer then data layer, (my question data layer has a module dependency back to businesslayer? so data layer push data back to business so its tight coupled?)
• wipesax360: public class ViewModel<T> extends GenericRouter { IPresentation ip = new BusinessUseCaseImpl(); is that wrong?
• João Dias: Well, in a project leveraging dependency injection, any instantiation of classes that should be beans is indeed wrong. You should only declare the dependency and the framework (be it JakartaEE, Spring or other) will take care of the injection.
• João Dias: Regarding "my question data layer has a module dependency back to businesslayer? so data layer push data back to business so its tight coupled?" the answer is yes that shouldn't be the case. The business layer should have the data layer as a dependency, but the data layer should not have a dependency back to the business layer. In fact, this is basically a circular dependency which is not allowed in Frameworks like Spring (baeldung.com/circular-dependencies-in-spring if you want to read more).
• wipesax360: ok so without DI, i think that relation between layer can be set up with interfaces and abstract classes.? bu please check the question i added some concrete class instatiasions inside viewmodels&businesslayer class. viewmodel creates a businessinterface and call its method, then business layer again call to datalayer within itself. this is manual dependency injection. but i think this way true. i will replace it dagger soon