DataMapper vs ActiveRecord?

Question

Ruby on Rails

When is it better to use DM in a Rail application instead of ActiveRecord? A cursory acquaintance with datamapper.org/why.html did not convince me that it would be more convenient for AR. Maybe DM is faster? Again, from what I've read, I can't see it.
There is a project on Rails 3 with DM: does it even make sense to migrate from ROR 3 to ROR 4, given that, as I understand it, there is no DM for Rails 4, but there is ROM, or is it possible to refuse DM altogether and make it on AR?
In general, I would like to get a detailed answer on the motivation to use DM in a Rails application with a relational database.

Answer 1

I'll tell you what I know.
DataMapper is no longer being developed, the developers of this library renamed DM to ROM and are now actively sawing it https://github.com/rom-rb
Proof - https://twitter.com/datamapper/status/342595504909...
So for myself personally I decided not to use DataMapper in projects, although I really like the library in ActiveRecords comparison, since it’s more clear how it works, you can simply describe models without writing migrations and DM will build tables.
I have some inexplicable dislike for ActiveRecords. Maybe because I don't use Rails, but write in Sinatra.
I use Sequel ( sequel.jeremyavans.net). I doubted for a long time to migrate to it from DM, but I did not regret it a bit - IT'S MAGIC! Super library with tons of plugins and features, especially when using PostgreSQL. By the way, the ROM developers decided to also use Sequel when using the SQL store.
Here is a video report on Sequel in Russian - www.youtube.com/watch?v=95TflPVKSI0

Answer 2

DataMapper is not only a gem, but a design pattern that is often contrasted with the ActiveRecord pattern (see Fowler's writings). Outside the rails community, these names are known in this context.
However.
First of all, the DataMapper gem, not the best implementation of the DataMapper pattern, going somewhere at random. Secondly, it is simply no longer being developed.
The ActiveRecord gem, on the contrary, is almost the standard of universal thoughtfulness in detail, and of course (how else), ActiveRecord is being actively developed.
Joining Roman Krylov 's answer, I will say that the best way to implement DataMapper in rails is to build it around Sequel, an excellent database access library, devoid of many of the disadvantages of ActiveRecord associated with its inherent inflexibility (convention over configuration, yeah) and performance problems (sometimes loads something superfluous, rarely , but in special cases it can be important).
When to use one and when to use the other?
If you have the opportunity to design a database in accordance with Rails conventions, definitely use ActiveRecord. You will save a lot of effort and money.
If you are building a project on a ready-made database or if the structure of the database being designed is too complex - use Sequel, make data converters, build an abstract object model decoupled from the database.

Answer 3

In general, I was completely sure that the Datamapper was everything, but there are even a few commits this year. I am convinced that a project should not be tied to something that is so vaguely supported.

Answer 4

implemented DataMapper in my php code. was satisfied. Business logic separately, requests separately. Very cool. Domain object models know almost nothing about the DBMS, and mappers only do what they drive objects to the database and back.

Answer 5

When is it better to use DM in a Rail application instead of ActiveRecord?

In a service-oriented application with a budget of ten million rubles.
But I would not do such a project in Ruby: it is better to take a tool that is more suitable for such tasks: Java, PHP or .NET.
And Ruby is good for startups.