I'm going to be involved in a medium sized project based upon spring boot framework. This project's going to be very data centric, i.e most of the business logic will have to deal with reading and writing data in traditional relational database.One guy of my team started to extensively see JPARepository, while I would like avoid all the magic behind JPARepository and, even if using Repository pattern is a good idea, I'd prefer him to write data access logic only using Query API , Entity manager, and so on. Why ? Well in my experience, the less your core codebase - in this case, the classes accessing the dbms - is tied to a framework, the better is.. In another large project, we had about an hundred of Ejbs which business logic methods accessed directly to the database, and when we had to refactor out the business logic it was a really pain and a big headache.
On the other hand, my colleague argued that endorsing a framework and not using it through fully it's a nonsense, and honestly I admit that his point of view is reasonable.
So, I'd love to hear your opinions about.
I don't really see how having to refactor the business logic to cut out direct access to the persistence layer is related to the repository pattern. I never have my business logic use repositories directly.
Inject repositories into your controllers. Controllers retrieve entities from repositories and pass those entities to services in the business layer. When the business layer has an answer, the controller will then make the necessary changes to the repositories and return a response to the client.
There's a clear separation:
The business layer does not reach into the persistence layer. It does not access repositories. Entities it needs to work on are passed to it.
The MVC controllers do not perform business logic. They only retrieve entities from repositories, trigger the business layer, and convert business models back into responses and actions that need to be performed on the persistence layer.
The persistence layer only knows enough about the business layer that it can convert data from the database to models from the business layer.
Thanks Stephan for your answer, anyway I was more concerned on using or not JPARepository ( i.e, tiying or not to Spring, at least for database access), rather than pure design issues. This said, your approach is really appreciable, because clearly respects a separation of responsibilities among layers.
Stephan van Hulst
posted 1 month ago
Write framework agnostic interfaces for the repositories you need. You can then implement those interfaces with classes that act as a façade for JpaRepository:
Use the BookRepository interface in your controller, and have it injected with an instance of JpaBookRepository. If for some reason you no longer want to use Spring, you can just write a different implementation for you BookRepository interface, without affecting your controllers or business layer.
A wop bop a lu bob a womp bam boom. Tutti frutti ad: