Собственно тут описана основная разница между подходами ActiveRecord и DataMapper. Гидраторы можно впихнуть туда и туда, можно мэпить на любые структуры теоритически, но основное различие в том кто отвечает за сохранение данных.
В рамках ActiveRecord мы работаем с объектами как отображением элементов нашей базы данных, как если бы у нас был прямой доступ к ним без SQL прослойки. В DataMapper мы работаем исключительно с нашими объектами, которые лежат в памяти, и просим отдельную штуку (мэппар) что бы тот синхронизировал состояние объектов в памяти и в базе (сохранил).
Это основное различие в подходах. Мэпить любую структуру на любую структуру мы можем и при том и при другом подходе, но только при варианте с ActiveRecord обычно так не делают (что бы сохранить иллюзию прямой работы с базой). Именно по этому при использовании AR обычно говорят о тестной связанности с базой, а при DM - слабой (мы вообще от нее не зависим по сути).
Остальные нюансы, вроде UnitofWork, Ideniny Map, работа со связями, ленивая инициализация связанных объектов, все это - приблизительно одинаково реализуется при обоих подходах и никакого отношения непосредственно к ActiveRecord или DataMapper не имеет. Но без этого всего эти вещи не предоставляют нам той гибкости, которую мы ожидаем получить от ORM.
Сейчас единственная полноценная ORM использующая DataMapper - Doctrine2. Реализации же ActiveRecord намного более распространены в силу упрощенной модели работы. Наиболее интересным видится вариант Propel2, в котором разработчики попытались совместить оба подхода, что закрывает нишу быстро растущих проектов, для которых важны преимущества обоих подходов. Но посмотрим что из этого выйдет.