When you should not use an ORM?

In design circles the importance of ORM is too much discussed. And different ORM implementations are compared with respect to their robustness. Last place where I worked, there was no ORM. Every developer was writing it’s JDBC DAO layer. This thing came in debate many times that why not to use an ORM like popular Hibernate. But the decision was not taken company wide and they stick with writing JDBC code.

I was thinking why they don’t opt an ORM and start considering the points. That could be following:

  1. There were complex queries having join with multiple tables. And usually these queries were tuned by DB team.
  2. Objects in API does not contain 1 to 1 mapping with the tables, hence no point of mapping anything.
  3. There was frequent change in database design.
  4. The schema was complex and legacy and there was a lot of cost involved aligning it for an ORM implementation
  5. The DB design was hard to translate in objects.

It’s not a matter of choice that you like it so you should have it. If your application is pretty simple and there are some simple and clean queries. JDBC is best choice.

ORM will be helpful when:

  1. Your application contains very less tendency of changing DB design
  2. You have solid object model and while designing the system you have thought you relational model in objects and build relationships 1:1, 1:m and m:n
  3. You don’t have store procedures

The decision of adopting ORM requires strict evaluation. I don’t think I touched all aspects.

Related Posts Plugin for WordPress, Blogger...

2 thoughts on “When you should not use an ORM?

  1. I think the possible reasons you mentioned not to use ORM is, apparently, because the DB is not OLTP but OLAP.. It’s just for reporting and analysis that’s why we have missing relations, constraints, mappings etc. in it. I agree not use ORM in that case, However if you are unable to handle a complex query in ORM like Hibernate, it lets you write a Native Query for that.
    I’m strongly in favor of using an ORM because not only it reduces the development cost in terms of efforts, increase productivity and maintainability but one of the ‘Under The Table’ advantage is that it will make you keep your DB design perfectly aligned and more sensible.

    • I agree with the idea of making DB design and to use ORM over it. That will help to keep it align with design rules and development will be easy to manage. And for small speed boats, native JDBC can do the charm.

Leave a Reply

Your email address will not be published. Required fields are marked *