Skip to main content

What I like about ORM vs JDBC

Remember not one tool is right for all the problems, for instance if you are building something simple as Twitter which has couple of tables, and you have never used ORM, then its waste of time to learn ORM and do things, on the other hand if you are building something complex, evolving application and need more time to spend on solving business problems and UX then you can't effort to spend extra time on just figuring out how to store and retrieve data into a DB.

And here are the few things I like about ORM
  1. Domain Model - Think data as Domain Object not as Tables and Relationships
  2. Standard Query Language - with JDBC we still get locked-in with proprietary SQL, whereas ORM provides great Query Language which is performance tuned for all supported DB's
  3. Less Code - less testing, less complexity, and less time 
  4. Concurrency and Locking - easily version data and protect data integrity in a concurrent environment
  5. Caching - Great support for standalone and distributed caching
  6. Re-Use - consider ORM as our old DAO layer, well written and fully tested so we can reuse for all future projects.
  7. Evolving - ORM's are still evolving and creating greater opportunities and innovations for Scalable, Distributed, Performance tuned applications, whereas JDBC was almost stagnate for quit some time.

And here are some ORM tools you want to consider for your next project, though they have some learning curve earlier.

My Experience with ORM
  Avexus - Aerospace maintenance Application with over 1300 tables.
  McKesson - Pharmaceutical Application with over 500 Tables
  Deployed Portal's with over 10 million active users in a clustered environment with JPA Hibernate, Solr, Distributed EhCache, Sticky Session

Part of my Job is to evaluate technologies and to pick the most suitable one depending on team skills, project scope and other factor's.

Though I personally prefer JPA 2 Hibernate Stack, and I also tested and used other frameworks and found Hibernate to be more stable then others. also another reason to stick with Hibernate is to use Hibernate Search, Hibernate Validator, EhCache support and Spring modules



I might also upload a sample project with all these technologies to github.

Comments

kovica said…
Can you provide details about the biggest application you wrote with ORM? How many tables were there in the database at the end?
How to you envision to develop and maintain an application that has over 3000 tables in the database using ORM? We have an application (ERP) that has that many tables in a database and we only employ three programmers for that.
kovica said…
The application is server/client based, has load balancing implemented, all around Java based and we typically get sub 20 ms response times (diference between client pressing a button on a Swing form and getting response back). Client is written in Swing.
waddle said…
@Kovica

From experience, I can tell that developers write much more SQL crap than ORMs. Besides that, they don't really know how to cache, optimize the fetching with code and SQL

I've written application with hundreds of tables. Having 200, 1000 or 3000 (or only 10 ?) it's the same. Just get a good developer that knows things like : caching, lazy-loading, n+1 issue, ORM session, second level cache and you'll get a better performance than with custom SQL
Few of the biggest application's I have seen using ORM
Avexus - Aerospace maintenance Application with over 1300 tables.
McKesson - Pharmaceutical Application with over 500 Tables

I Deployed Portal's with over 10 million active users in a clustered environment with
JPA Hibernate, Solr, Distributed EhCache, Sticky Session
Anonymous said…
What we have found useful is a tool (now) called MyBatis. We consider it an ORM but it is technically an Object Mapping tool which is light wieght while leveraging the best of Object Oriented languages and SQL. We have found that mapping is easier and we have more control, less issues, and faster optimization. Additionally, easier to maintain as DB and OO is handled in the domains of each. Thoughts? Do you agree?
Part of my Job is to evaluate technologies and to pick the most suitable one and it all depends on team skills, project scope and other factor's.

Though I personally prefer JPA 2 Hibernate Stack, though I also tested and used other frameworks and found few issues scaling and pushing them to the limit.

Another reason to stick with Hibernate is to use Hibernate Search, Hibernate Validator, EhCache support and Spring
Pedro Mendes said…
That sample project would be great! :)
Anonymous said…
I have to agree, MyBatis is the better way to go. Has all the features of a standard ORM without any of the problems.

As in when things go wrong you can be in a whole world of pain.

The industry is moving in that direction too as FOSS companies are now switching from ORMS like Hibernate to MyBatis. Example: Alfresco
Anonymous said…
ORM is abstracction layer of JDBC now a days use ORM s/w's like Hibernate.... good article
alberlau said…
"Deployed Portal's with over 10 million active users"

Could you provide links to those portals?

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @ElementCollection     private List<String> certifications = new ArrayList <String> ();     public Long getId() {         return id;     }     public void setId(Long id) {         this.id = id;     }     public List <String> getCertifications() {         return certifications;     }     public void setCertifications(List <String> certifications) {         this.certifications = certifications;     } .. }         Users u = new Users();         u.getCertifications().add("Sun Certified Java Programmer");         em.persist(u); Generated Tables    Users    Co

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @Column     private String firstname;     @Column     private String lastname;     @Column     private String username;     @Column     private String street;     @Column     private String city;     @Column     private String state;     @Column     private String zipc