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.


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…

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
Intesar said…
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?
Intesar said…
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

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

public class Users implements Serializable {

    private static final long serialVersionUID = 1L;
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private List<String> certifications = new ArrayList<String>();

    public Long getId() {
        return id;

    public void setId(Long 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");

Generated Tables

Column --> ID
    Row             1


ArrayList vs LinkedList vs HashSet Performance Comparision

ConclusionsInserting & Reading sequentially from Collection prefer LinkedList/ArrayListInserting & Reading/Deleting by Search/equals from Collection prefer HashSetInserting, ArrayList & LinkedList performs best while HashSet takes double the timeReading, HashSet performs best while ArrayList & LinkedList are marginally lessDeleting, HashSet performs 10 times better than ArrayList & ArrayList performs 4 times better than LinkedList. LinkedList is slow because of sequencial search Bottom line : unless you are not going to iterate using for(Integer i : list ) then prefer HashSet
Inserting/Reading/Deleting integer's from zero till countJDK7Collectionactioncounttime msArrayListInsert1000/1LinkedListInsert1000/1HashSetInsert1000/1ArrayListInsert100005LinkedListInsert100004HashSetInsert100007ArrayListInsert10000011LinkedListInsert10000011HashSetInsert10000021ArrayListGet/Read1000LinkedListGet/Read1000HashSetGet/Read1000ArrayListGet/Read100004LinkedListGet/Read100003Has…

Validating CSV Files

What is CsvValidator ?
  A Java framework which validates any CSV files something similar to XML validation using XSD.

Why should I use this ?
  You don't have to use this and in fact its easy to write something your own and also checkout its source code for reference.

Why did I write this ?
  Some of our projects integrate with third party application which exchanges information in CSV files so I thought of writing a generic validator which can be hooked in multiple projects or can be used by QA for integration testing.

What is the license clause ?

Are there any JUnit test cases for me checkout ?
 Yes, source

How to integrate in my existing project ?

Just add the Jar which can be downloaded from here CsvValidator.jar and you are good.

Instantiate CsvValidator constructor which takes these 3 arguements

         // filename is the the file to be validated and here is a sample         // list - defines all the fields in the above csv file ( a field has index, type, isOptional, rege…