What is an ORM and W Should Use it
An introduction to Object-Relational-Mappers
As a relative newcomer to the programming world, terms like Object-Relational-Mapper can sound really intimidating. The nice part about ORMs, is that they actually make it easier to write code once you get the hang of them (usually).
In this post, I aim to explain what an ORM does, as well as the pros and cons of using them in your projects.
Let’s get to it!
What is an ORM?
Before we talk about what an Object-Relational-Mapper is, it might be better to talk about Object-Relational-Mapping as a concept first.
Unless you’ve worked exclusively with NoSQL databases, you’ve likely written your fair share of SQL queries. They usually look something like this:
SELECT * FROM users WHERE email = 'test@test.com';Object-relational-mapping is the idea of being able to write queries like the one above, as well as much more complicated ones, using the object-oriented paradigm of your preferred programming language.
Long story short, we are trying to interact with our database using our language of choice instead of SQL.
Here’s where the Object-relational-mapper comes in. When most people say “ORM” they are referring to a library that implements this technique. For example, the above query would now look something like this:
var orm = require('generic-orm-libarry');var user = orm("users").where({ email: 'test@test.com' });
As you can see, we are using an imaginary ORM library to execute the exact same query, except we can write it in JavaScript (or whatever language you’re using). We can use the same languages we know and love, and also abstract away some of the complexity of interfacing with a database.
As with any technique, there are tradeoffs that should be considered when using an ORM.
Let’s take a look at some of the pros and cons!
Tip: Use Bit to organize your components and make them discoverable for your team, to build new applications faster. It’s open-source, give it a try.
What are some pros of using an ORM? 👍
- You get to write in the language you are already using anyway. If we’re being honest, we probably aren’t the greatest at writing SQL statements. SQL is a ridiculously powerful language, but most of us don’t write in it often. We do, however, tend to be much more fluent in one language or another and being able to leverage that fluency is awesome!
- It abstracts away the database system so that switching from MySQL to PostgreSQL, or whatever flavor you prefer, is easy-peasy.
- Depending on the ORM you get a lot of advanced features out of the box, such as support for transactions, connection pooling, migrations, seeds, streams, and all sorts of other goodies.
- Many of the queries you write will perform better than if you wrote them yourself.
What are some cons of using an ORM? 👎
- If you are a master at SQL, you can probably get more performant queries by writing them yourself.
- There is overhead involved in learning how to use any given ORM.
- The initial configuration of an ORM can be a headache.
- As a developer, it is important to understand what is happening under the hood. Since ORMs can serve as a crutch to avoid understanding databases and SQL, it can make you a weaker developer in that portion of the stack.
What are some popular ORMs?
Wikipedia has a great list of ORMs that exist for just about any language. That list is missing JavaScript, which is my language of choice, so I will throw my hat in the ring for Knex.js.
They’re not paying me to say that, I’ve simply enjoyed working with their software and I don’t have any experience with other JavaScript ORMs. This article might provide more insightful feedback for JavaScript specifically.
Closing Thoughts.
I have greatly enjoyed using an ORM. As a full-stack developer working on small teams where we don’t have a dedicated database guru, it has greatly simplified working with the data layer.
Though some people think of the configuration process of an ORM as a pain point, I have loved the ease with which I can configure different databases for different environments using a consistent interface.
Having built-in support for migrating and seeding a database has made it much easier to prototype more quickly, which I wrote about here.
Overall, I prefer working with an ORM to not. That being said, I haven’t had to work at the scale where SQL tuning becomes more important, so I’m sure my opinion is very biased.
If you haven’t tried using one, I would suggest trying it out and seeing how it works for your development system, but ultimately somebody who is really strong with databases will always give you better performance than the best ORM system.
I hope that you have learned something new today! I would appreciate it if you could drop some 👏 or leave a comment below! Also, feel free to follow me on Twitter and Medium, and Don’t forget to follow Bits and Pieces :)
