ORMs role in Microservices age!
Recently I saw some discussions on Twitter people arguing about necessity of existence of ORMs (Object-relational mapping) at this age and the others are even waiting to have Entity Framework as a binging in Azure Functions. That made me as a person who have been working with ORMs from the early days and with different types of data driven applications, to write my two cents about the topic.
First, why would ever people think they do not need an ORM? Several points come to my mind in this regard:
- Movement towards NoSQL databases in the past few years.
- Offering everything as a service by third-party company/components resulted in having an API in some cases to perform CRUD operations rather than dealing directly with relational databases.
- Movement towards Microservices architecture and having tiny data access layers makes people feel less need of adopting a full fledge ORM.
I will continue by answering some questions from my point of view.
1. Do we still need full-fledge ORMs?
We definitely do. Well, generally people tend to think if they do not need something, no one ever dose! Basically, as long as you need to perform CRUD operations over relational databases, you need to have an ORM of a kind.
2. Why not writing our own data access layer using low level data access API?
For small use cases, it could perfectly work but keep this in mind that like any other parts if the software, if you write code, you also write bug! You also need to probably write test for your code and it means spending time and effort.
As the size of the software grows, you will be tempted to write a code generator to generate data access layer boiler plate code for you and finally you will ended up writing your own ORM! That means reinventing the wheel!
Writing a good ORM is a very difficult task. There is a reason, dedicated teams work for years to build tools like Entity Framework. Going beyond basic CRUD operations and trying to implement feature like connection management/pooling, managing transactions, change tracking, caching, keeping track of database migrations and so on, could be extremely challenging. I am talking out of experience!
3. Why not going with Micro ORMS?
Well, if Micro ORMs fulfill all your requirements, then go with them. Do not forget the fact that there is a reason for having Micro in the name. They do not offer all the features of a full-fledge ORM. If your software may need the missing features, then you will again need to reinvent the wheel!
I would assume that using an ORM or handling data access layer in general, is one of the early decisions needed to be made by an Architect. So somehow an Architect should foresee all the requirements to make the best decision. Despite the fact the data access layer related code in most types of architectures is encapsulated inside Repository classes and is supposed to be replicable easily but I would have to say easily does not always necessarily mean quickly or even without a cost!
4. Is that right to use ORMs in Microservices?
Yes! ORMs nowadays are much faster than a few years ago and have much smaller foot prints. Feel free to use them.
5. What about having and Entity framework binding for Azure Functions?
They are most welcome.
6. Any reason to avoid ORMs?
Well, as I mentioned earlier, choosing an ORM is an architectural decision and when it comes to Architecture, there is no absolute right or wrong decision. Under different circumstances, you may need to make different decisions.
If you need to meet a very tide SLA to perform a transaction in which even milliseconds matter, then you may need to use even low-level API and perform CRUD. Writing a fast middleware for mission critical applications could also be another candidate.
7. What is the best ORM?
If you have several options, the best thing to do is to test different aspects of the ORMs. Performance, features, programming model, memory foot print etc. Then compare the results and make the best decision.
Long story short, use ORMs unless you have a good reason to not to.