ORM Technologies vs JDBC?

Question

My question is regarding ORM and JDBC technologies, on what criteria would you decide to go for an ORM technology as compared to JDBC and other way round ?

Thanks.

Answer 1

I think you forgot to look at "Functional Relational Mapping"

I would sum up by saying:

• If you want to focus on the data-structures, use an ORM like JPA/Hibernate
• If you want to shed light on treatments, take a look at FRM libraries: QueryDSL or Jooq
• If you need to tune your SQL requests to specific databases, use JDBC and native SQL requests

The strengh of various "Relational Mapping" technologies is portability: you ensure your application will run on most of the ACID databases. Otherwise, you will cope with differences between various SQL dialects when you write manually the SQL requests.

Of course you can restrain yourself to the SQL92 standard (and then do some Functional Programming) or you can reuse some concepts of functionnal programming with ORM frameworks

The ORM strenghs are built over a session object which can act as a bottleneck:

1. it manages the lifecycle of the objects as long as the underlying database transaction is running.
2. it maintains a one-to-one mapping between your java objects and your database rows (and use an internal cache to avoid duplicate objects).
3. it automatically detects association updates and the orphan objects to delete
4. it handles concurrenty issues with optimistic or pessimist lock.

Nevertheless, its strengths are also its weaknesses:

1. The session must be able to compare objects so you need to implements equals/hashCode methods But Objects equality must be rooted on "Business Keys" and not database id (new transient objects have no database ID!). However, some reified concepts have no business equality (an operation for instance). A common workaround relies on GUIDs which tend to upset database administrators.

2. The session must spy relationship changes but its mapping rules push the use of collections unsuitable for the business algorithms. Sometime your would like to use an HashMap but the ORM will require the key to be another "Rich Domain Object" instead of another light one... Then you have to implement object equality on the rich domain object acting as a key... But you can't because this object has no counterpart on the business world. So you fall back to a simple list that you have to iterate on (and performance issues result from)

3. The ORM API are sometimes unsuitable for real-world use. For instance, real world web applications try to enforce session isolation by adding some "WHERE" clauses when you fetch data... Then the "Session.get(id)" doesn't suffice and you need to turn to more complex DSL (HSQL, Criteria API) or go back to native SQL

4. The database objects conflicts with other objects dedicated to other frameworks (like OXM frameworks = Object/XML Mapping). For instance, if your REST services use jackson library to serialize a business object. But this Jackson exactly maps to an Hibernate One. Then either you merge both and a strong coupling between your API and your database appears Or you must implement a translation and all the code you saved from the ORM is lost there...

On the other side, FRM is a trade-off between "Object Relational Mapping" (ORM) and native SQL queries (with JDBC)

The best way to explain differences between FRM and ORM consists into adopting a DDD approach.

• Object Relational Mapping empowers the use of "Rich Domain Object" which are Java classes whose states are mutable during the database transaction
• Functional Relational Mapping relies on "Poor Domain Objects" which are immutable (so much so you have to clone a new one each time you want to alter its content)

It releases the constraints put on the ORM session and relies most of time on a DSL over the SQL (so portability doesn't matter) But on the other hand, you have to look into the transaction details, the concurrency issues

List persons = queryFactory.selectFrom(person) .where( person.firstName.eq("John"), person.lastName.eq("Doe")) .fetch();