Is Data Mapper a more modern trend than Active Record

Question

I've come across a couple of ORMs that recently announced they are planning to move their implementation from Active Record to Data Mapper. My knowledge of this subject is very limited. So a question for those who know better, is Data Mapper newer than Active Record? Was it around when the Active Record movement started? How do the two relate together?

Lastly since I'm not a database person and know little about this subject, should I follow an ORM that's moving to the Data Mapper implementation, as in what's in it for me as someone writing software (not a data person)?

Valenciavalenciennes

Answer 1

The DataMapper is not more modern or newer, but just more suited for an ORM.

The main reason people change is because ActiveRecord does not make for a good ORM. An AR wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. So by definition, an AR is a 1:1 representation of a database record, which makes it particularly suited for simple CRUD.

Some ARs added fetching of related data, which made people believe AR is an ORM. It is not. The point of an ORM is to tackle the object relational impedance mismatch between your database structure and your domain objects. When using AR, you don't solve this impedance mismatch because your AR represents a database row and not a proper OO design. You are tieing your db layout to your objects. Some of the object-relational behavioral patterns can still be applied though (for instance lazy loading).

Another reason why AR is often criticised is because it intermingles two concerns: business logic and db access logic. This leads to unwanted coupling and can result in less maintainability and flexibility in larger applications. There is no isolation between the two layers. Coupling always leads to less flexibility.

A DataMapper on the other hand moves data between objects and a database while keeping them independent of each other and the mapper itself. While more difficult to implement, it allows for much more flexible design in your application. Your domain objects no longer have to match the db structure. DAL and Domain layer are decoupled.

Kibitz

Answer 2

Even though the post is 8 years old, the question is still valid in 2018.

Active record is Anti pattern beware of that. It creates a very tight coupling between code and database. It might not be a problem for small simple projects. However, I would strongly recommend to avoid using it in anything bigger.

A good OOP design is done in layers. Input layer, service layer, repository layer, data mapper and DB - just a simple example. You should not mix Input layer with the DB. How this can be done? For example, in Laravel, you can use a Validator rule like this:

'email' => 'exists:staff,email'

It checks whether the email exists in the table staff. This is a complete OOP non-sense. It tights your top layer with the DB column name. I cannot imagine any better example of a bad OOP design.

The bottom line - if you are creating a simple site with 2-3 tables, like a blog, Active record might not be a problem. For anything bigger, go for Data Mapper and be careful about OOP principles such as IoC, SoC, etc.

Forepeak

I strongly disagree with Active Record being an Antipattern. In the end, it all comes down to developer productivity over extended periods of time. I have worked with SQLAlchemy (a Data Mapper ORM) and Django ORM (an Active Record ORM). I am WAY more productive with Django ORM, although I have less experience with it. I typically don't need to write complex logic, but only simple CRUD queries. Django ORM makes this trivial and easy to read. Also, Django is not small. Together with Flask, it's the most used web framework in Python. So I'm likely not the only one who feels like this. – Cyclopean

Well, implementing shortcuts and antipatterns always begins with "it will be simpler in this case" and then it backfires as the app growths. Laravel's active record is wrong on so many levels .. – Forepeak

From my experince, Active Record is way more efficient. I'm working on a 100 or so table database. Sometimes you just don't need that much of decoupling, because in the end all of your tables are interconnected in one way or another, there's usually no way to use a small amount of features without exposing features from other part of the app. In this case overengineering seems to be a more anti pattern thing. And it greatly reduces productivity. – Deaver