We Keep Coding

Dependency injection between business layer and presentation layer

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();

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.

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:
You should never make the presentation layer depend directly on the data layer. Always go through the business layer.
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.

Spring Architecture Questions: is Service needed?

I'm new to Spring and I'm creating a REST-Service.
I wonder what the Service-Layer is for (#Service).
Currently I encapsulate my DAOs with that Layer.
So for example my PersonController receives a PUT, calls the PersonService which calls the DAO which finally saves the person in my database.
I also saw some examples in the www. (https://howtodoinjava.com/spring/spring-core/how-to-use-spring-component-repository-service-and-controller-annotations/)
I also have read this question here: Is this a good Spring Architecture (include testing)
Do I even need the Services, if it only calls the DAO like:
public void save(Person p) {
personDAO.save(p);
}
?
I don't really see what the advantage of this is. I create classes which actually do nothing... Or is it just a architecture standard because additional business logic will be in this layer too?
Also... when I have several services like personService, familyService, animalService, etc. and they all have some method signatures that are the same and some which aren't... is it useful to use Interfaces here?
When I create Interfaces like: Saveable, Loadable, Deleteable (does this even make sense?) - how do I use them correctly? Do I create a new Interface for every service that extends the Interfaces I desire? Like a PersonServiceInterface that extends Loadable and Deleteable and I implement it in my PersonService?
Thanks in advance!

If you do not feel the need for a service layer, then chances are high your controllers are performing way more business logic than they should.
adding a service layer in between allows for dedicated tests of pure frontend (controller handle request and response wiring only / services handle the business logic/ repositories persist and query the data).
so rule of thumb - it is much easier to have many services handle fractions of your logic than to stuff everything into your controllers
i am not sure what you are trying to solve with the interfaces you introduce - i do not think it makes sense to re-invent the Repository interface on top of your services. If your services only forward to repositories directly then there is no use in having them anyway.

Call repository and service from controller layer with Spring

I use Spring Boot and Spring Data.
I have no problem in my mind to separate Repository Layer and Service Layer
So I have my UserRepository with CRUD method and some Spring Data method
findAll
findByUsername
I also have UserService with business method.
checkPassword(String login,String password)
businessMethodAction(String username)
Here is my question:
In my controller I have to call method from UserService and sometime from UserRepository. For the moment, I inject both in my controller, and I call service or repository
#Inject
UserService userService;
#Inject
UserRepository userRepository;
#RequestMapping("{username}")
private void myMethod(#PathVariable String username){
return userRepository.findOne(username);
}
#RequestMapping("{username}/doBusineesAction")
private void myMethod(#PathVariable String username){
return userService.doLogicalThin(username);
}
I'm just asking because I confused to inject both and to call one or the other in the same class
On another side, this would mean to duplicate method in service layer like this
public User findOne(String username){
return userRepository.findOne(username);
}
What's your opinion?

Controller layer shouldn't ever call repository directly. You should always use the service layer because the service layer encapsulates your business logic surrounding that call. Just because currently there isn't any business logic, doesn't mean that you should skip the layer entirely.

If your controller does not require business logic or perform a single repository operation, you can use the repositories directly. Use services to implement use cases that require business logic or orchestration of repository calls.

If it's a layered CRUD app, I think it's fine for the controller to have knowledge of the repository and directly call it for simple read operations as long as the app is simple, small
Tradeoffs:
The controller calling the repo removes the layer of abstraction of the service layer
The controller and repository are now coupled
If you don't have requirements/use cases/business logic for your read op., I would suggest not rolling out a full service. YAGNI (you aren't going to need it). Meaning, it doesn't make sense to implement an extra 'pass through' service layer at this time given the business needs.
Before you choose to make your controller aware of your repository, I suggest to consider whether or not you've decoupled your repository layer from your persistence layer.
The structure of controller -> service -> repository -> persistence is not a hard and fast rule, as opposed to controller -> repository -> persistence. Your use case seems to fit the latter.

In my opinion, the service layer must implement the business logic and it must be called from controllers. In most of the cases, this layer has to perform more operations than just calling a method from a DAO object. This is probably the best solution if your application has great size. Also, you can split your logic into several parts and make it working in one transaction, that help you to save the data in the non-controversial state.

If you don't need transaction and no business logic is involved there is no need to have extra code that doesn't do anything.
There are examples in spring documentation when controller is calling repo.
Example 51 from here https://docs.spring.io/spring-data/data-commons/docs/current-SNAPSHOT/reference/html/#reference for example.

One approach is to reserve controllers are for business level concepts displayed on the views and repositories for the normalized entities in the DB. One can then define services to address the many-to-many relationship between controllers and repositories.

Firstly, you should not be using both the service and repo class within the controller class. These are some good practices while using SpringBoot:
Repo class should be injected in Service class
Service class has to be injected in the Controller class
Following this you can use it efficiently. Using both the service and repo objects within controller is like confusing the spring context which instance to be called.

The correct annotation is #Autowired, not #Inject, if you are using spring boot.

How to separate Repository and Service Layers

How should be separated Repository and Service? IMHO clients (e.g. Controller) should primaly use Service layer instead of Repository as it should be separated from persistance implementation. Single Repository should provide methods of access of only one entity, while methods of Service are able to provide more complex actions, including usage of multiple repositories.
But what to do with rich repositories, that provides not only CRUD methods but much more, like JPARepository from Spring Data? In such implementations there are so many possible methods of fetching objects that duplicating them in Service isn't cool.
So what is the solution for that problem?
A. Duplicate methods in service layer like this
#Service
class XService{
#Autowired
private XRepository repository;
public List<X> findAll(){
return repository.findAll();
}
}
B. Simply using repository in controllers (autowired or access method in service)
C. Any other good approach?

Services should implement (business) logic and possibly modify entities according to that logic. If your service layer is only a thin wrapper around repositories, i.e. only fetching entities as your description suggests, something is wrong with your design.
Often logic is spread throughout the controllers. Identify that logic, extract and encapsulate it in services and restrict Controllers to manage the application's flow, by orchestrating the appropriate services.

Using Services and DAOs in spring mvc controller

I'm building a web application that primarily constitutes of CRUD operations of data from back end/database. There are instances where in I have to write business logic(I'm sure we will have more business logic built as we go deeper in to development). Currently for each UI screen I'm creating I create a model class,Service class, DAO class, a controller(it's servlet essentially) and bunch of jsp pages. In most cases the service class just calls the methods from DAO to pass in model objects. Essentially we use model classes to map data from UI screens. Hence the controller will have the model objects populated when a form is submitted. I have started using service classes to keep a separation layer from web layer to DAO layer. But at times I feel that the service class is just adding unnecessary level of API calls, I would think that I could just inject the DAO in to Controller and complete the task faster. I want to use the service class only when there is additional business logic to be performed. If you have to design an application what factors do you consider using controller->DAO vs controller->Service->DAO control flow?

DAOs are more granular and deal with one specific entity. Services provide macro level functionalities and can end up using more than one DAO. Typically, Services are used for defining transaction boundaries to gain atomicity. In other words, if you end up updating multiple tables using multiple DAOs, defining transaction boundary at service will help in either committing or rollbacking all the changes done to DB.
In your design, since you are primarily doing CRUD for various entities, it may seem that services are not adding much value. However, think of web-based front end as one way of updating data. Usage of services will allow you to expose same capabilities as a web-service later to other forms of client like third party integrators, etc.
So, in summary, your design seems to be in line with conventional practices. If you feel that you can combine multiple services into one based on some common theme such that it can reduce the overhead of code, then, you should go ahead and do it. At the end of day, ultimate goal is to create maintainable code which no one is afraid to change when need arises.

In Pro-Spring-3 book they mentioned below line, for controller with JPA2
Once the EntityManagerFactory had been properly configured, injecting it into your service layer
classes is very simple.
and they are using the same class as service and repository as in below:
package com.apress.prospring3.ch10.service.jpa;
// Import statements omitted
#Service("jpaContactService")
#Repository
#Transactional
public class ContactServiceImpl implements ContactService {
private Log log = LogFactory.getLog(ContactServiceImpl.class);
#PersistenceContext
private EntityManager em;
// Other code omitted
}
but in case you are going to use spring-data CRUDRepository or JPARepository then your DAO will be Interface and you have to make service layer to handle your code

I'd reference my answer here
The long and short of it is the advantage of using a Service layer is it gives you room to move in the future if you want to do anything with Spring Security and roles etc. It allows you to handle transactions more atomically and Spring itself has really nice annotations for this.

Use a service class when dealing with more than one aggregate root.
Inject repositories (aka a dao that returns a collection) or dao's directly into controller, no need for an extra layer/class to do a basic get.
Only use service classes where necessary, otherwise you have twice as much code as required.
You can make repository generic, and annoatoate with #Transactional(propagation = Propagation.REQUIRED) which enforces a transaction is present, but won't create a new one if already present. So if you later use multple repositoes in one service class method, you will only have the one transaction.