Why do we need to call Service layer using Interface instead of direct service class from controller in spring

Question

When spring was introduced its advice to use an interface between different layers like Controller,Service,DAO instead of directly calling them using actual class reference.

In new age of Spring 5.x and Spring Boot 2.x do we need to still use interface between Controller and Service class. In my case I am developing a REST application with single GET method which call DB and do some business logic. So In my service I have only one method in this case still I do need to use ServiceInterface to call my actual ServiceImpl? what is best practice and is there any specific advantage of using ServiceInterface in this scenario?

Below is Sample code without ServiceInterface

public class MyTestController{

 private MyTestServiceImpl myTestServiceImpl;

public MyTestController(MyTestServiceImpl myTestServiceImpl){
      this.myTestServiceImpl = myTestServiceImpl;
}

@GetMapping("/test")
public String getTestString(){
     myTestServiceImpl.getTestString();
}
}


@Service
public class MyTestServiceImpl(){

 private MyTestRepository myTestRepository;

//constructor

//Service method impl
}

question from:https://stackoverflow.com/questions/65944372/why-do-we-need-to-call-service-layer-using-interface-instead-of-direct-service-c

Answer 1

In very small applications, it doesn't really matter, because it is still very easy to keep track of all the classes and what classes do what. In a large scale enterprise application it can quickly become a cluttered mess. For example, if you have a rest endpoint/controller that has 100 methods, and it in turn calls 50 methods in your DAO. If you at some point decide to change the DAO methods, you will now have to change all 100 methods in the controller/endpoint. Whereas if you have a service layer in between to bridge the DAO and rest controller you only have to change the service methods.

Another point as @p.streef has mentioned is the seperation of classes and their functions. You can have a modular application wherein the service layer handles all the business logic and rules, the DAO is only responsible for database operations and the controller's only job is to send and receive data. The S in S.O.L.I.D stands for Single responsibility principle, so instead of the service layer is supposed to handle only receiving and transmitting data, and not business logic.

However, if you are building a very very small application then it shouldn't matter.