The Active Record and Data Mappers of ORM Pattern

Because Web Applications become more and more complex and users demand more and more. So we must focus on performance. Since querying the database is a sensitive point for performance of application so the focus of this article will be the performance impact of “Active Record” and “Data Mappers”.

Before dive into the deep let’s see what is ORM ?

ORM

Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming technique for converting data between incompatible type systems using object-oriented programming languages. This creates, in effect, a “virtual object database” that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to construct their own ORM tools.

So simply we can say that ORM (Object Relational Mapper) is the layer that sits between your database and your application.

Active Record: The Web’s Favorite ORM

“The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.”

• Simple. Because of how tightly matched the records in your database and the objects in your system are conceptually, it’s really easy to pick up a project, examine its database schema, and have a strong sense of what the project is doing. What makes this great is that the ORM layers have a minimal amount of indirection. What you see in the database or objects is likely what exists in the other.
• Easy to understand. This flows directly out of the simplicity, but you’ll also probably have a pretty intuitive understanding of how you can work with this system even if you’ve never had the least exposure to an ORM before. Its simplicity is merciful and easy.

Data Mapper:

“A Data Mapper is a Data Access Layer that performs bidirectional transfers of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer. Mapper implementations vary in scope. Generic mappers will handle many different domain entity types, dedicated mappers will handle one or a few.”

The biggest difference between the data mapper pattern and the active record pattern is that the data mapper is meant to be a layer between the actual business domain of your application and the database that persists its data. Where active record seeks to invisibly bridge the gaps between the two as seamlessly as possible, the role of the data mapper is to allow you to consider the two more independently. Java’s Hibernate and PHP’s Doctrine2 are the two prototypical data mapper facilitators in my mind, though I have little doubt that there are many others.

The Good: What Data Mappers Allow

• Allows for greater flexibility between domain and database. As we mentioned above, one of the prototypical reasons that you’ll want to use a data mapper is that you as the application architect do not actually have final say on the database scheme. Where you’ve got a historical database, or a new database with an unfriendly gatekeeper, the data mapper pattern allows you to hide the ways in which you database isn’t an ideal way to think about your domain behind the whole data-mapping layer.
• Can be much more performance. Similarly, because you do have a layer of abstraction and indirection between your domain objects and your database, there’s a good possibility that you can have the data mapper make more efficient use of the database than a naive active record implementation would allow.

Conclusion :

I strongly believe that both the Active Record and the Data Mapper patterns have a place within our developer tool belts. I think it is wrong to categorically say that one pattern is better than the other. Hopefully I’ve shown in this article that each pattern has a time and a place.

Choosing the wrong pattern for an application will always be a mistake, but you can’t blame the tools at your disposal. By being aware of the different methods and ideologies of patterns such as Active Record or Data Mapper, we can make better, more informed decisions on the tools we choose for the current project.

• Use an ORM based on ActiveRecord if you do not have logic in your application.
• Use an ORM based on DataMapper for more complex models, especially if you need to abstract the domain objects from the database representation.
• When performance is needed, don’t try to optimize the ORM queries, just go back to pure SQL with a DataMapper.