20 таблиц это не так страшно, многие из них в запросе повторяются (там же локализация, а в TYPO3 локализованные записи и оригинальные находятся в одной таблице, поэтому когда выводится не основной язык, то таблицы в запрос включаются дважды).
Я сделал не ORM, а некоторое свое решение, я затрудняюсь его классифицировать.
В общем есть 1) описание модели, я его делаю своим синтаксисом в typoscript (я добавляю свой TLO DBVIEW) там описано какие таблицы как соединяются, какие условия объедения итп. это описание находится в статичном TS шаблоне, который я подключаю на странице вставки плагина. 2) Далее поверх этого статичного шаблона накладывается TS шаблон страницы плагина, в котором описаны уже какие сущности модели надо вывести на странице, идет список нужных полей (чтобы не таскать из базы лишнее), описывается форматирование полей, тут уже именно шаблон для вывода html, там много работы со stdWrap, склейка списков через ->split итп, вообщем тут обычные TS объекты работают на полную, так как данные в шаблон передаются через загрузку cObj->data и их можно обрабатывать средствами TS как вздумается.
Имея эти шаблоны моя библиотека парсит шаблон модели, составляет один большой SQL запрос, получив ответ она уже парсит шаблон вывода и на выходе получается html.
То есть ORM'ом тут и не пахнет
зато работает быстро и модель и шаблонизация более-менее разделены.
На ORM'е у меня не получилось сделать быстрый вывод, дело в том, что у меня в анкетах юзеров много вложенных сущностей - анкеты состоят из блоков, каждый блок может быть отключен юзером / запрещен модератором, в каждом блоке набор атрибутов, значения которых выбираются из готового списка, эти списки могут быть выбраны с одним значением, также есть списки где можно выбрать несколько значений (причем список значений отличаются в зависимости от пола юзера), далее в анкете есть и текстовые поля - просто строка и RTE, итд... В целом это почти точное воспроизведение анкет, как они строятся на mamba.ru, все элементы, которые есть у них, у меня тоже присутствуют, только у меня таких анкет несколько типов (в зависимости от профессии юзера) и у некоторых юзеров сразу несколько типов анкет.
Если перед выводом строить всю объектную модель анкеты в деталях, со всеми этими вложенными сущностями, потом загружать в нее данные из БД, а потом только пускать в шаблонизатор, как это должно делаться в DDD, то все это займет кучу времени, мне это не подошло. У меня шаблонизатор работает напрямую с БД, и я один раз описав модель, больше не думаю о ней, а только указываю, что именно сейчас мне надо вывести.
Плюс этого подхода, что рендеринг работает быстро, минус, что модель размазана - в одном месте модель описана для рендеринга, в другом месте модель для бизнес логики - отправка посланий, редактирование анкет итп.