Active Record против Data Mapper-а для сохранения данных

Спасибо, но у меня этого нет, наверное потому что пост перекочевал из песочницы.
Да я то с вами согласен, я вообще против фанатизма любого рода, надо как-то больше на задачи ориентироваться, — где-то data mapper, где-то active record использовать, а где-то и вообще PDO и SQL хватит и не нужно усложнять.

Здесь не вопрос Модно-Немодно.
Выбор конкретного подхода Active Record vs Data Mappers + Repository должен вытекать из бизнес задач.
Дело в том, что Active Record является фактический неотъемлемой частью RAD (rapid application development), и цель его быстро развернуть уровень доменных моделей (читай бизнес логики) по существующей схеме базы (как правило, небольшой). Фактически все RAD проекты строятся по принципу «Database First» — т.е. мы вначале проектируем схему БД, как-то ее декларируем (Json, Yaml, SQL, ini) и через эту декларацию фреймворк генерирует нам доменные модели с уже реализованым CRUD функционалом через механизм scaffolding-a.
Это хорошо работает на маленьких-средних проектах с небольшими зависимостями. Если же проект большой и людей, которые работают на нем много, и чтобы поддерживать все в рабочем состоянии эти люди хотят покрывать код тестами, то тут начинаются проблемы…
Поэтому в последнее время такую большую популярность и обрел DDD (Domain driven design), который декларирует одним из своих основных принципов persistence ignorance и «Code First». При этому мы получаем все те плюшки, которые автор описал в статье (SOLID, доменные модели не знают вообще, что их куда-то сохраняют, поэтому становятся тонкими и содержат только бизнес логику). Развивая идею дальше мы приходим к тому, что в таком виде можно легко реализовать Unit of Work паттерн, и разгрузить слой приложения (читай контроллеров) от обязанностей сохранять и контролировать что модели сохраняются и обновляются корректно. А эта обязанность переходит в инфраструктурный уровень. Но при этом, да, сложность проекта становится выше.

Уровень абстракции повышается, сложность стало быть. Но это больше разработчиков касается конечно, чем пользователей.

А в чем проблема инжектить в AR-сущность кешер и загружать из кеша?

В Yii в Active Record есть метод, возвращающий имя таблицы, и при желании можно указать префикс, обозначающий коннект, который обеспечивает доступ к источнику

class User {
    function table() { return 'db1.user'; }
}

«table» не сериализуется, он же метод
При восстановлении объекта коннект восстанавливается лениво через локатор Yii::app()->db1 только при чтении или записи объекта

При тестировании в локатор можно подсунуть настройки тестовой базы или мок

Я думаю, это достаточно гибко

В ООП вы управляете объектами. Представим что вы — объект, человек. От того что я у вас номер на машине поменял — у вас машина тут же не обновилась до соответсвующего номера? Более того невозможно проверить существует ли машина с таким номером без запроса в базу.
ID — это то, что связывает сущность внутри приложения с строкой в таблице в базе. Это нельзя менять вот так вот просто

Парадигма ООП не вводит понятие аспекта.
В данном случае вы пытаетесь ввести аспект связей(древовидной) объектов и сохранить его целостность.
А это, увы, уже задача бизнес-логики.

public function setParent($parent)
{
    $this->parent->removeChild($this);
    $parent->addChild($this);
    $this->parent = $parent;
}

А у вас не ООП, а каша. С таким уровнем «магии» ваш проект уже завтра станет неподдериваемой шляпой.

На мой взгляд в статье лишь сравниваются два подхода. Не стояла задача полностью рассказать о каком либо из них.