ORM — The Good and the Bad Things

Introduction

In this article, I want to share with you my idea about the usage of ORM in our projects. I don’t want to promote if the ORM usage is good or bad practice, I only want to share my opinion based on my current knowledge and my experiences working on queue projects using not an ORM.

Before proceeding I would like to provide a short description of, What an ORM is?. “Accepted description” could be like:

An ORMs (Object Relation Mapper), are pieces of software dedicated to translating between the data representations in relational databases and the representation in memory used with object-oriented programming (OOP). The ORM provides an object-oriented interface to data within the database, attempting to use familiar programming concepts and reduce the amount of boilerplate code necessary in order to speed up development.

In general, ORMs serve as an abstraction layer meant to help developers work with databases without drastically changing the object-oriented paradigm. This can be helpful by reducing the mental load of adapting to the specifics of a database’s storage format.

In My opinion, is not only applicable for object-oriented programming because at this time we could find ORM for almost all the paradigms and programming languages.

The good and the bad about the ORM usage

The good

• Helps to save time to write SQL queries
• Reduce development time
• Reduce development costs
• Adds an abstract layer for the DB repository
• Apports model migrations support
• Helps to avoid SQL injections

The bad

• Are slow to process the queries
• Sometimes if we need complex queries some of the ORM (or almost all) could be a limitation
• Loss in developer productivity whilst they learn to program with ORM
• Add more code to entities definitions
• Affect a bit with the application performance

Conclusion

If we are working on a small project/service and the SQL queries won’t be complex, then we could go ahead and implement an ORM always considering the performance and the response times will be affected a bit more than if we use a pure SQL queries.

If our project is large and is presented to have a very good performance we may be could start to think in don’t use an ORM and coding our project using a good architecture.

Another good thing to don’t use an ORM is to leave the dependency that most of the developers have on the Framework usage.

As a goodbye note, let me share with you this Robert C. Martin phrase.

“I’m a programmer. I like programming. And the best way I’ve found to have a positive impact on code is to write it.”
― Robert C. Martin, Clean Architecture

Keep learning!