Spring data jpa repo, why need interface service and service implementation

Question

I just started work on Spring Boot, using Spring Data JPA. When I generate model from table, I create a modelRepo which extends JpaRepository<myModel, String>

public interface userRepository extends JpaRepository<User, String>{
}

Then from a controller, I can easy call userRepository.findAll() to get data.

However, when I look on some tutorials, they have extra several steps before calling findAll(). Take a look below:

public interface userService{
Iterator findAll();

}

    public class userServiceImpl implements userService{
       @Autowired
       UserRepository userRepository
       @Override
       Iterator findAll(){
        return userRepository.findAll();
       }
    }

Somethings like that, I can query the data directly from userRepository as long as @Autowired to inject userRepository.

In some example, they do same structure at above. Can anyone explain why do we need service and serviceImpl before calling data.

Answer 1

Because the so-called "service" classes ("inherited" with the N-tier architecture) are where the business logic "lives". In the end, it depends on your approach/design guidelines, the way you would like to manage transactions, structure your project, etcetera.

If you only need to make a call to the database and return that data, you can safely skip the "service" call/class. On the other hand, if you are doing something "in the real life", you will end up using those "service" classes a lot since most of the operations (read: business logic) is going to be there, so you would want to have all that behavior isolated in one place — otherwise you would be injecting beans everywhere without following any "project organization" among other things. It's a little bit tedious sometimes, but on the other hand, you know where to look for whenever you need to change something. In medium to large projects this is quite important; even more if you have several people modifying the same code base.

TIP: Keep your classes small. Injecting tons of beans (repositories, services and what not) on a "service" class is bad design and may lead you to other non-senses.

Answer 2

It's good practice to separate out the functionality of your application into separate classes. (See the single responsibility principle https://en.wikipedia.org/wiki/Single_responsibility_principle).

What I mean by this in this context is that if you needed to do some more advanced business logic between your controller and the calls to your JPA repository then this should be included in a service layer. This prevents your controller class from being polluted with business logic when it should only be concerned with handling the request and passing on responsibility to the service layer.

However, if you are just doing some simple CRUD operations then it's absolutely fine to just call the repository directly from your controller. So it depends what your application needs to do really!

Answer 3

You don't have to use a service to be able to query data. It's a better practice to write a service to prevent code repetition when you need the same functionality in another part of the application.