Should You Use an Object Relational Mapper in your App?


When you write applications that communicate with a relational database, your design needs to solve a fundamental problem.   In most cases, we create systems using relational databases.  (i.e. MySQL, Oracle, MSSQL, etc.)   Similarly, we probably write our web or smart client applications using an object oriented programming language like C#, Java, Ruby, JavaScript, or Python.   The data access layer that you write needs to connect the relational database world with the world of “objects/methods/properties.”   In this post, I will review some of the benefits and challenges of using an object relational mapper, common set of tools and framework patterns to solve this mapping problem.


In my professional experience, I have found ORM’s helpful.   The problem of converting database rows into objects is not a very interesting task.   I personally enjoy focusing my attention on the business logic, game logic, or control logic code.

Benefits of an ORM:

1)      Most ORM tools provide a method of mapping database table to your application objects.   For some ORM’s, the database tables are generated from application objects that you define.  You can also find ORM’s that create application objects based on database tables. (Many ORM frameworks support both styles)

2)      As mentioned before, an ORM creates a way for you to access your database tables using application classes that you didn’t have to write by hand.   Some frameworks automate the process of creating your classes from database structure.   If you’re coding in a static language like C# and Java, your compiler can help you manage data model changes in your application over time.

3)      Some have noted that ORM’s help reduce defects in the data access layer. Why? Since the mapping process between database tables and application classes has been code generated or automated, a human being can inject fewer mistakes.

4)      I really admire the Ruby Active Record technology.  In their ORM technology, they have created a cool system for changing the database model and the application model.The “Ruby on Rails” migrations feature giving developers a clean system for making edits to production or test code branches.

How do I find an ORM for my language?

What are some reasons to not use an ORM?

ORM’s will not work for every project.

1)      If your current code base has complex hand coded SQL in the data access layer, it may be hard to introduce an ORM into that culture.   It really depends on the situation.   If you’re starting a new module, you might consider testing an ORM in the bounds of that module.

2)      ORM’s have a bad reputation for configuration bloat.  An ORM has to solve the fundamental problem of mapping your database tables to your application objects. Some ORM’s are very verbose.  (I tend to avoid these)   ORM’s that use conventions are often concise.    I encourage you to write small apps to test if an ORM is the correct choice for your team.

3)      I’m a big fan of loose coupling.   When I design systems, I want to make sure I can test my business objects in isolation of data access.As you consider a specific ORM,  consider how much tight coupling the tool introduces between your business logic code and the data access layer.

I hope I have given you a balanced review of the benefits and costs of using ORM’s as you start your career.    Here are a few links that I used to research this post.   I hope you find them helpful.  I have also included a link to OpenBarter, an open source barter system written in C# using Entity Framework.  Entity framework is one popular ORM option for the Microsoft .NET framework.


We love to hear from our readers.   What are your thoughts?  Are you working on any fun software development projects?


Join the Spark Macon Maker Space Community on Facebook

Posts From InspiredToEducate.NET

This entry was posted in agile, open source, programming, technology. Bookmark the permalink.