JDBC VS Hibernate [closed]

Question

We have been using JDBC for a very long time in our web applications. The main reason we used it is because we have 100% control over the code, sql and fix things by our hands. Apart from that we used triggers inside the database, and the database is developed separately by DB experts.

However many now recommend using Hibernate so we also thought about using it. But, we found the below issues.

1. Hibernate cannot connect with an "Existing" database. It always try to create a one of its own.

2. Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.

3. We never like to give the "table creating work" to the java code. We create tables manually, always.

4. We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.

5. Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.

6. We always use MySQL. Never use any other DB.

7. The application we create require max security, related to medical. If at least one data record is leaked, we are done.

8. There are lot of foreign keys, Primary Keys, Composite Keys, Unique Keys etc etc in database. In forums, some complained that Hibernate messed with those.

9. We decided to try hibernate because some people claims, "Are you Software Engineers? You are using already dead JDBC !!. "

Considering these, please let me know whether the above points are actually true (as I said, I got to know them via googling, discussion etc) or not. And, what are the pros and cons of Hibernate VS Java JDBC?

Answer 1

Answering issues listed above:

1. Hibernate cannot connect with an "Existing" database. It always try to create a one of its own.

This is wrong. Hibernate can connect to an existing database, and it doesn't always try to recreate it. You just should turn of parameter like hbm2ddl. auto.

2. Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.

Hibernate has an adjustable cache, so this is also not a problem.

3. We never like to give the "table creating work" to the java code. We create tables manually, always.

No problem. See p.1 above. Furthemore there are several convinient libraries for indirect table creation and update (e.g. liquibase) which can be used in couple with hibernate perfectly.

4. We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.

You can always use direct JDBC calls and invoke native SQL queries via hibernate, if it is neeeded.

5. Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.

Again, if you have to invoke some logic complicated SQL code instead of hibernate auto-generated - you can do it.

6. We always use MySQL. Never use any other DB.

Not a problem at all. Hibernate has special MySQL dialect support: org.hibernate.dialect.MySQLDialect.

7. The application we create require max security, related to medical. If at least one data record is leaked, we are done.

Security issues aren't related to ORM techniques. Hibernate is just logical and convinient object-oriented layer between pure database JDBC calls and programmers tools. It doesn't influence somehow on common net security.

Answer 2

Hibernate is a great tool and you'll find plenty of documentation, books, and blog articles about it.

I will address all your concerns:

Hibernate cannot connect with an "Existing" database. It always tries to create one of its own.

Hibernate should use a separate database schema management procedure even for integration testing. You should use an incremental versioning tool like FlywayDB to manage your schema changes.

Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.

You don't have to use the 2nd level cache, which uses 3rd party caching implementations. All caching solutions may break transactional consistency. The first level cache guarantees session-level repeatable reads and with the optimistic locking in place you can prevent lost updates.

We never like to give the "table creating work" to the java code. We create tables manually, always.

The DB should be separated from your ORM tool. That's a best practice anyway.

We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.

Hibernate is great for write operations and for concurrency control. You still need to use native SQL for advanced queries (window functions, CTE). But Hibernate allows you to run native queries.

Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.

You don't need and you shouldn't probably use the hbmdll utility anyway.

We always use MySQL. Never use any other DB.

That's even better. You can therefore use advance native queries without caring for database portability issues.

The application we create require max security, related to medical. If at least one data record is leaked, we are done.

Hibernate doesn't prevent you from securing your database or the data access code. You can still use database security measures with Hibernate too. You can even use Jasypt to enable all sorts of security-related features:

• advanced password hashing
• two-way encryption

There are lot of foreign keys, Primary Keys, Composite Keys, Unique Keys etc etc in database. In forums, some complained that Hibernate messed with those.

All of those are supported by Hibernate. Aside from the JPA conventions, Hibernate also offers particular mapping for any exotic mapping.

We decided to try hibernate because some people claims, "Are you Software Engineers? You are using already dead JDBC !!. "

That's not the right argument for switching from a library you already master. If you think you can benefit from using Hibernate then that's the only compelling reason for switching from JDBC.