Should I use JDBC or Hibernate when having most of the logic in Stored Procedures?

Viewed 182

I have an application with thousands of procedures and packages to implement business logic, currently, I am using JDBC to make calls to my database. Is it good to move to Hibernate for this purpose? Or should I stay with the JDBC itself as I am having a hard time whether to take hibernate or stay with the JDBC?

1 Answers

Having most of the logic in SP's in mind:

Pros of JPA:

  • Stored procedures can be stored in a centralized place and defined using the @NamedStoredProcedureQuery annotation (JPA 2.1+).
  • You get database independence. Almost, as there are some minor differences when it comes to supporting OUT params for example. But if the DB changes the amount of adaptation work needed is very little compared to plain JDBC.
  • IF some of the CRUD operations are needed to be performed in Java you have entire Hibernate on your side with its ORM / pre-compiled @NamedQueries / Caching and all the goodies available at your disposal.
  • If the team decides to implement new features mostly in Java, not in SP's, then you have a ready to go infrastructure prepared.

Pros of JDBC:

  • You are calling the database directly, without any Persistence provider on top of that so the calls should be faster.

Yes.. so basically you just get better performance out of the bat. But from my experience, you can tweak and configure JPA provider in a way that the difference is minimal. Anyway.. the decision is up to you.

Related