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:
- There were complex queries having join with multiple tables. And usually these queries were tuned by DB team.
- Objects in API does not contain 1 to 1 mapping with the tables, hence no point of mapping anything.
- There was frequent change in database design.
- The schema was complex and legacy and there was a lot of cost involved aligning it for an ORM implementation
- 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:
- Your application contains very less tendency of changing DB design
- 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
- You don’t have store procedures
The decision of adopting ORM requires strict evaluation. I don’t think I touched all aspects.