Most software projects need to talk to a database at some point – they usually do GET queries for data, update a field or create a record. In the past, people would write raw code that communicated with the database and built an object or some code representation of the data that they would manipulate. This lead to an incredible amount of duplicated code for every project that usually had some subtle bug that was present in all libraries.
ORM stands for Object Relational Mapping. It’s a bit of an abstract concept – but basically it’s a technique that allows us to query and change data from the database in an object oriented way. I think it’s fair to say that whenever somebody uses the acronym ORM they mean a library that abstracts away all of the code required to get the data and be able to manipulate it. Basically, you shouldn’t need to write raw SQL anymore – the library will get it.
Benefits of ORM
As a software developer, I’ve worked on a lot of projects where ORM hasn’t been used and I’ve also worked on a lot of projects where it has been used. I believe there’s an incredible amount of benefits to using it. In most languages, doing raw SQL queries results in some sort of unsafe map / array like structure that isn’t type safe, that then requires you to have a series of getter / setters.
Typically Much Cleaner Code
Most ORM libraries are pretty opinionated and will force you to work in an MVC style which usually results in a lot of cleaner and easier to follow code. Object Oriented concepts like inheritance can be implemented with very few hassles.
Less Duplicated Code
As software developers, we all know that we need to try and avoid duplicate code. Duplicated code is harder to update, maintain, and reuse. I suggest reading my book review Clean Code for some ideas of why. Another huge benefit is that most ORMs are already doing a lot of things automatically like Internationalization (I18N). Here in Canada, the official languages are English and French.
Usually Save a Lot of Time
As you become more experienced as a developer, you typically realize that the less code you write the less chance of there being bugs. A lot of plumbing code isn’t required – which means you don’t usually need to have generic methods you write that open a connection to the database, get data, update data, etc.
ORMs are usually far more flexible than writing your own code because they abstract away a lot of the databases whether they be MySQL, MS SQL, Oracle or something else. If you implement the ORM behind a service it might be possible to completely change out the library or database without changing any of the underlying code at all.
Consequences of ORM
Typically, there’s two types of ORM libraries one is incredibly complex and enterprise like and the other is more of a data mapper. Configuring the enterprise like one can be incredibly difficult as it will typically use a lot of features you may not need or want. For example, high level caching of queries might actually be really bad for your system if it’s using streaming events or has an incredible amount of read / write traffic for each user.
I believe a simple data mapper library will always win compared to doing all of the trivial plumbing code. Using an ORM with a functional language or style is probably not going to work out all that well either.
Pretty much all ORM libraries implement the same principles, the deciding factor is usually the environment and languages you will be using for your project.
Author: Brian Cline