Ну что ж поделать. Простым всегда кажется не то, что проще по объективным причинам (всяким там метрикам), а то, что знакомо, для чего не требуется усваивать какие-то новые концепции. Когда-то мы все писали ужасный спагетти-код, а всякие там разделения на слои понять было сложно. Сейчас же, если откопать свой код столетней давности, окажется, что разобраться в нем и внести даже небольшие изменения - сложно.
Полагаю, так сделано из других соображений: в первой же строке вводной части документации говорится: designed to safely work in classic and daemonized PHP applications.
Может изначально и из-за этого, но в доке где-то было зачем может понадобиться и как создавать кучу. Лично для меня это добавляет явности при работе со сложными write моделями, не надо думать что где-то что-то закешировалось. Изменение данных всегда предсказуемо. Лучше еще раз дернуть из базы новые данные (которые могут уже быть совсем другие, а не те что в кеше орма), чем потом разгребать баги связанные с параллельным обновлением данных.
Самый простой способ не думать о том, что где-то что-то закэшировалось - не кэшировать. Часто кэшируют не потому что измерили и нашли bottleneck, а на всякий случай.
многие ормы кешируют by default, во избежание дополнительных запросов на чтение (тот же cycle, но там легко управлять используя отдельные кучи)
Из-за базового предположения, что 1 класс мапится на 1 таблицу (и, как следствие, связи между классами однозначно мапятся на тот или иной вид реляционного отношения), нет способа описать маппинг, пересекающий эти границы.
Круто. Это мне как-то в голову не пришло. Получается, именно это является характеристическим свойством AR.
Это смотря что считать ActiveRecord-ом. Если RoR-овский и его клоны, то конечно. А если взять обобщенное определение Фаулера - там таких ограничений не накладывается.
Дык, я с того и начал, что если вместо domain models писать банальные persistence models, чем, по сути, сводя всю бизнес-логику к процедурному стилю, то обсуждать преимущества или недостатки Data Mapper vs Active Record несколько бессмысленно.
Погоди, откуда взять? Я процитированный кусок взял отсюда: https://www.martinfowler.com/eaaCatalog/activeRecord.html
Блин, я настолько был уверен, что помню написанное в книге, что даже не перечитал. Вот идиот-то!
НУ ЩАСможно было бы тупо ссылок накидать вместо простыни.
У нас Вурдалак любил приводить в пример игры. Я взял на вооружение игру Монополия. Представь себе ее модель. Это будет один агрегат огромный Игра. Там будут Игроки, Поле и т.д. Когда один игрок ходит, то бросается кубик, фишка игрока сдвигается на какой-то поле и в зависимости от того, какое это поле происходят различные события. Собственность чужого игрока - надо заплатить. Есть деньги - платишь. Нет - придется что-то делать. И вот такой огромный агрегат, когда думаешь как его смоделировать, мысль о том, как всё хранить, возникает далеко не в первую очередь. В таких примерах сразу становится очевидным верховенство правильной объектной модели над строками в базе данных.
Вот да. Забавно, что я на это не обратил внимание сколько-то там лет назад, сконцентрировавшись в основном на примере кода на Java (в котором, в общем-то, никакой строгой привязки к таблице нет, никто не мешает написать "ручной маппинг" как угодно).
