CODEWITHSUNDEEP
hibernatejpaormjdbc
Bino Manjasseril
Bino Manjasseril

Reputation: 112

Do you recommend JDBC or JPA for large applications?

To give some background,

  1. We have fairly large schema consisting of hundreds of tables with complex relationships.
  2. Data volumne is huge as well and the nature of data is relatively sensitive (financial)
  3. Current architecture is - Java EE: Session Beans, DAOs (JDBC) calling Stored procedures.
  4. On the database level we have some replication mechanisms to keep data in sych with front-end and back-end databases (hosted on different boxes). So the application will have a need to look for (read) data from front-end database and if not available look in back-end DB. So, in JPA terms, we probably need two different instances of EntityManagers.

Scalability and performance are the biggest concerns as the system is still growing.

With the above information, does anyone has any input on how feasible it is to migrate the application to use a persistence framework such as JPA? What are some of the challenges of a persistence framework in the above mentioned situation?

Upvotes: 1

Views: 2345

Answers (3)

Amir Pashazadeh
Amir Pashazadeh

Reputation: 7282

You mentioned you have stored procedures, then there will be a question, you want to reimplement most of you project or not.

If you don't want that, then forget about JPA or Hibernate, and in that case I recommend your to use MyBatis (or iBatis).

Upvotes: 1

jpkroehling
jpkroehling

Reputation: 14061

I agree with @SJuan76 that you sould get someone to take a deep look into your architecture to provide a better advice. But in any case, here are some tips:

1) Start with the mapping. Map your entities the "right OOP way", and try to reach the same schema you have by tweaking the mapping. If the relationships are that complex, you may face some blocker, and it's better to deal with it during the mapping phase (instead of mapping just a small part, for PoC).

2) Don't worry about Hibernate's performance. Hibernate will probably be faster than any in-house JDBC framework. But do take a look at the performance changes if you decide to move the business logic from the stored procedures to your Java code. You'll probably have to switch your way of thinking when converting them, as working with a big set of data inside a SP is usually faster than transfering this big set of data to the app layer and working on it there.

3) Do spend some time reading Hibernate books and documentation. Really. Most of the time that people complain about Hibernate, it's because they don't really know what's going on behind the scenes.

Good luck :-)

Upvotes: 5

Robert
Robert

Reputation: 2471

My experience is that once you get past a few pages then you end up with some sort of framework. This can be something as simple as exchanging Maps of data, but with Java the desire to use type safety will probably lead to some form of mapping framework. Hibernate, by way of its JPA annotations is by far the most well known in the Java universe, but of course there are other implementations. I have also had an excellent experience with Grails, which actually used Hibernate (by default) under the hood, but of course that's a complete stack.

I recommend your senior team take some time to work some examples from at least a few of the most promising alternatives before you do anything else.

Upvotes: 1

Related Questions