Question

i examine lots of samples but i didn’t find an adequate solution for this.
Some documents say “Ideally your business logic layer shouldn’t know there is a database. It shouldn’t know about connection strings or SQL.”

I found some samples which locate the business logic to @Service annotated classes but they use SQL/HQL in @Service methods.

What should be the ideal usage? If we want to change database or persistence technology should we change only @Repository annotated classes or both of them?

Answer 1

I prefer putting all persistence-related stuff (i.e. queries, and everything dealing with JDBC, JPA or Hibernate) in a DAO layer, and have the service layer rely on this DAO layer for persistence-related stuff.

But the main goal is not to be able to change the persistence technology without affecting the service layer. Although that could be possible if you switch from Hibernate to JPA, for example, it wouldn’t be if you switch from JPA to JDBC, for example. The reasons are that

• JPA automatically persists all the changes made to entities without any need for update database queries , whereas JDBC doesn’t, and thus needs additional update queries
• JPA lazy-loads association between entities, whereas JDBC doesn’t
• …

So changing the persistence technology will affect the service layer, even if all the persistence stuff is isolated in DAOs.

The main advantages of this decoupling, IMHO are

• clearer responsibilities for each class. It avois mixing persistence-related code with business logic code.
• testability: you can easily test your service layer by mocking the DAO layer. You can easily test the DAO layer because all it does is executing queries over the database.