• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

When NOT to use Spring framework facilities.

 
Bartender
Posts: 1166
38
IBM DB2 Netbeans IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 10524
224
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
  •  
    Claude Moore
    Bartender
    Posts: 1166
    38
    IBM DB2 Netbeans IDE Spring Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Saloon Keeper
    Posts: 10524
    224
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!