Best practice to organize service,service implementation and repository in a spring boot application

Question

Sample project structure that can be found in most of the appliations
In most of the spring boot applications there are JPA repository, service and service implementation. Can anybody explain the pros and cons of

1. Just using repository only when needed
   
2. Using service class and it's application.
   
3. Use service interfaces and use the implementation.

Different blog posts have different explanations. Seeking for an expert experience.

Answer 1

First of all, every design pattern is made to solve a common problem in software development. If you are sure that you won't face those problems in your specific use case, you don't need to follow these patterns.

1. You can call repositories directly from your controller or wherever you need it. Repositories should perform basic database operations and there's no problem in calling them if that's all you need.

2. But most of the time, you want some business logic to be performed before/after working with the database. That's where Service classes get involved (one of the SOLID principles is the Single Responsibility Principle - you should not have both persistence operations and business logic in the same class). For example, you call your EmployeeService.save() method to save an employee, and that method executes business logic (for example, checks that the employee's ID number is correct) and then calls the repository class (which only saves the employee in the database).

3. The interface and implementation pattern is an extension of this last one. Having an interface makes your application easier to maintain in the future if new functionalities are needed. Ideally, most of your application will call the interface, and the appropriate implementation will be provided (for example, by injection in Spring components). For example, if a year from now you need a special implementation that performs different business logic, you can just implement that interface and inject the bean as needed.

That's why most developers future-proof their applications by using the repository-interface-implementation structure. If you are sure that you'll only need basic CRUD operations, there's no need to create Services.

Answer 2

1. Just using repository only when needed-->You should create and use it only when its needed; that's fine. In general its good practice not to create something unless you really require it.

2. Use Service class and use that --> Service is just class where you are writing your business logic by fetching some data from repository classes(DAO-data access object layer); Its good practice to keep them segregated; so that any change in the DAO or service should not affect each other.

3. User service interface and Implement that and use the implementation.

In general you code in terms of interface; its good design andcoding practice; this way you create loosely couple code; so where ever you use the Service you inject it as interface type and its underlined implementation you can plug in and plug out; of Course if there are multiple implementation for your Service interface. For example-you have two different implementation for your ShapeService interface for two different client to calculate Area where one client is interested in to calculate the area of Recatangle whereas other is in Square. So in this case if you create Service interface and its Impl; you can keep the logic intact or unchanged for the class where this Service interface is going to be used. Also in future if there are many implementation for shape it will be easy to change; your code design would be open for extension but close for modification.

I would recommend if you have single implementation for service class then go directly with class instead of creating Service interface and then separate Impl class;