What's the significant difference between active record and data mapper based ORMs?

Question

Like doctrine(active record) and Xyster(data mapper),what's the difference?

Answer 1

The difference is in how separate your domain objects are from the data access layer. With ActiveRecord, its all one object, which makes it very simple. Especially if your classes map one to one to your database. Data mapper is more flexible, and easily allows your domain to be tested independent of any data access infrastructure code. But complexity comes at a price.

Answer 2

I have to admit that I don't know doctrine or Xyster but I can at least give some insight into the difference between Active Records as implemented in Ruby versus ORMs such as SubSonic, Linq to SQL, nHibernate and Telerik. Hopefully, it will at least give you something to explore further.

Ruby's Active Record is its native data access library - it is not a mapping from an existing SQL interface library (e.g. .NET SqlDataTables) into the constructs of the language - it is the interface library. This gave the designers more latitude to build the library in a more integrated manner but it also required that they implement a broad range of SQL tools that you won't typically find in an ORM (e.g. DDL commands are a part of Ruby's Active Record interface).

ORMs are mapped to the underlying database structure using a manual step in which a code generator will open a database and scan through it - building objects corresponding to the tables (and stored procedures) that it finds. These objects are constructed using the low-level SQL programming constructs offered as part of the language (e.g. the .NET System.Data.Sql and SqlClient libraries). The objective here is to give record-oriented, relational databases a smoother, more fluent interface while you are programming: to reduce the "impedence mismatch" between the relational model and object-oriented programming.

As a side note, MS has taken a very "Active Record-like" step in building native language constructs into C# via Linq to SQL and Linq to Entities.

Hope this helps!

Answer 3

The main difference is that in DataMapper the model is defined in the ruby class itself:

class Post
  include DataMapper::Resource

  property :id,         Serial
  property :title,      String
  property :body,       Text
  property :created_at, DateTime
end

While in ActiveRecord the class is mostly an empty class and the framwork scans the database. This means you need either a pre-defined database or use something like migrations to generate the schema, this keeps the data model separated from the ORM.

DataMapper.auto_migrate!

would generate the schema for you.

ActiveRecord is different in this regard:

class Post < ActiveRecord::Base
end

In DataMapper there is no need for migrations, as automigrations can generate the schema or look the differences between the model and the database and migrate for you. There is also support for manual migration you can use for non-trivial cases.

Also DataMapper is much more "ruby" syntax friendy, and features like lazy loading when doing chainable conditions (like ActiveRecord in Rails 3) are there from the beginning.

Datamapper also has a feature that every record in the database maps to one ruby object, which is not true for ActiveRecord. So if you know that the database records are the same, you know that two references to the ruby object will point to the same object too.

On the counter side, while Rails 3 may promise you exchangeable frameworks, the Datamapper railtie (dm-rails) is not production ready and many features may not work.

See this page for more information.