Здравствуйте, chaotic-kotik, Вы писали:

EP>>Дело не compile/run-time, а в отсутствии типизации.
CK>Которая тут не нужна.

Почему? Вручную выписывать индексы, структуры, кое-как склеивать текст запроса, и к тому же ручную контролировать корректность всего этого. Ради чего?

EP>>Например проверять версию схемы в runtime.
EP>>С DAL у тебя точно такие же проблемы. Точнее даже хуже — например обновил схему, типа обновил код, но ошибки типа неверных имён полей в тексте запросов и т.п. могут спокойно дожить до runtime'а.
CK>Пытаюсь тут на простую схему намекать. Представь что у тебя есть таблица с документами (куча полей), есть таблица с метаданными, в метаданных описано в какой таблице хранятся документы,

Это лишь один частный случай, в котором нужна динамика. EDSL запросов может работать в том числе и с динамикой, там где это необходимо — например как в sqlpp11.

CK>Далее, нам нужно завести новое поле — добавляем новую запись в таблицу метаданных, запускаем скрипт — скрипт делает миграцию (делает ALTER TABLE нужной таблице).
CK>При старте сервис читает метаданные и после этого может работать с новой схемой. В этой архитектуре ничего рефактрить не нужно никогда вообще.

Неверно. Не надо рефакторить только определённом наборе вариантов расширяемость которых заранее заложена в изначальную задачу. Причём в случае EDSL в этих же случаях точно также не нужно рефакторить.
Если же произошло любое изменение вне этой расширяемости (например изменилась структура метаданных) — то нужно точно также рефакторить. При этом, опять таки, на основе текстовых запросов это всё делается труднее.

То есть ты говоришь мол есть документ с произвольным набором полей описанным метаданными, и на основе того что можно в него добавлять поля без рефакторинга, ты делаешь неверное обобщение "Ну можно ведь не рефактроирть"