[ACCEPTED]-ORM Technologies vs JDBC?-database-connection

Accepted answer
Score: 17


  1. With JDBC, developer has to write code to map an object model's data representation to a relational data model and its corresponding database schema.
  2. With JDBC, the automatic mapping of Java objects with database tables and vice versa conversion is to be taken care of by the developer manually with lines of code.
  3. JDBC supports only native Structured Query Language (SQL). Developer has to find out the efficient way to access database, i.e. to select effective query from a number of queries to perform same task.
  4. Application using JDBC to handle persistent data (database tables) having database specific code in large amount. The code written to map table data to application objects and vice versa is actually to map table fields to object properties. As table changed or database changed then it’s essential to change object structure as well as to change code written to map table-to-object/object-to-table.
  5. With JDBC, it is developer’s responsibility to handle JDBC result set and convert it to Java objects through code to use this persistent data in application. So with JDBC, mapping between Java objects and database tables is done manually.
  6. With JDBC, caching is maintained by hand-coding.
  7. In JDBC there is no check that always every user has updated data. This check has to be added by the developer.


  1. Hibernate is flexible and powerful ORM solution to map Java classes to database tables. Hibernate itself takes care of this mapping using XML files so developer does not need to write code for this.
  2. Hibernate provides transparent persistence and developer does not need to write code explicitly to map database tables tuples to application objects during interaction with RDBMS.
  3. Hibernate provides a powerful query language Hibernate Query Language (independent from type of database) that is expressed in a familiar SQL like syntax and includes full support for polymorphic queries. Hibernate also supports native SQL statements. It also selects an effective way to perform a database manipulation task for an application.
  4. Hibernate provides this mapping itself. The actual mapping between tables and application objects is done in XML files. If there is change in Database or in any table then the only need to change XML file properties.
  5. Hibernate reduces lines of code by maintaining object-table mapping itself and returns result to application in form of Java objects. It relieves programmer from manual handling of persistent data, hence reducing the development time and maintenance cost.
  6. Hibernate, with Transparent Persistence, cache is set to application work space. Relational tuples are moved to this cache as a result of query. It improves performance if client application reads same data many times for same write. Automatic Transparent Persistence allows the developer to concentrate more on business logic rather than this application code.
  7. Hibernate enables developer to define version type field to application, due to this defined field Hibernate updates version field of database table every time relational tuple is updated in form of Java class object to that table. So if two users retrieve same tuple and then modify it and one user save this modified tuple to database, version is automatically updated for this tuple by Hibernate. When other user tries to save updated tuple to database then it does not allow saving it because this user does not have updated data.


Score: 16


ORM If your application is domain 10 driven and the relationships among objects 9 is complex or you need to have this object 8 defining what the app does.

JDBC/SQL If your application 7 is simple enough as to just present data 6 directly from the database or the relationships 5 between them is simple enough.

The book 4 "Patterns of enterprise application 3 architecture" by Martin Fowler explains 2 much better the differences between these 1 two types:

See: Domain Model and Transaction Script

Score: 4

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

I would sum up by 63 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 62 Mapping" technologies is portability: you 61 ensure your application will run on most 60 of the ACID databases. Otherwise, you will 59 cope with differences between various SQL 58 dialects when you write manually the SQL 57 requests.

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

The ORM strenghs are 52 built over a session object which can act 51 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 50 are also its weaknesses:

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

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

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

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

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

The best way to explain differences 7 between FRM and ORM consists into adopting 6 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 5 put on the ORM session and relies most of 4 time on a DSL over the SQL (so portability 3 doesn't matter) But on the other hand, you 2 have to look into the transaction details, the 1 concurrency issues

List<Person> persons = queryFactory.selectFrom(person)
Score: 1

It also depends on the learning curve.

Ebean ORM has 4 a pretty low learning curve (simple API, simple 3 query language) if you are happy enough 2 with JPA annotations for mapping (@Entity, @Table, @OneToMany 1 etc).

More Related questions