MikroORM for Enterprise-Grade Applications
Developing enterprise applications with Typescript on Node.js can be quite a challenge due to the lack of enterprise-grade libraries and frameworks. And in a case like this, a solid ORM is not just a time-saver for large applications, but also a lifesaver!
MikroORM is an excellent, solid ORM for Typescript. It’s based on patterns like Unit of Work, Identity Map, and Data Mapper which are elaborately described by Martin Fowler in his book, Patterns of Enterprise Application Architecture (P of EAA).
Unit of Work
Enterprise applications consist of a heavy set of models and business logic. And business logic creates lots of changes on models and persists these changes to the database. The Unit of Work pattern tracks every single change that’s ever been done on models during business logic and persists modifications to the database in a single transaction at the end of the logic.
In his book, P of EAA, Martin Fowler describes the function of “Unit of Work” in a simpler way:
“[It] maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.”
Calling the database for every change that’s been performed on models in a single request would be incredibly insufficient. And in case any unforeseen errors occur during these changes, you might need to roll back previous successful changes to return to the working state. But, the Unit of Work pattern solves these problems by retaining each model change.
Another pattern that’s frequently used with Unit of Work is Identity Map. This pattern holds models on a map by their IDs. This way, the models are loaded from the database during the business transaction. As a result, this significantly reduces database calls and improves performance. And it also leads all changes to happen on the same model object, which prevents the existence of the same model with different states.
Touching upon this matter in his book, P of EAA, Martin Fowler mentions a beautiful proverb:
“A man with two watches never knows what time it is.”
Business models tend to be quite complex. Because they might have an inheritance or a relation with models. And these types of model structures don’t match the database schema.
ORM’s Data Mapper helps to separate business models from databases (Persistence Ignorance). It handles the complexity between the model and database data. This way, your models don’t possess any knowledge about the database and vice versa.
Moreover, MikroORM has built-in mappers in database drivers to support different databases. It contains decorators to define data types to be used in Data Mappers. And it also offers customer mapper support for more complex data.
Although the patterns we’ve mentioned above are usually the main ones, there are many more patterns used in MikroORM. Therefore, ORM is highly appropriate for large and complex business applications. And even though MikroORM is inspired by Doctrine, there’s a great number of ORMs that are similarly based on these patterns in various other programming languages.