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

EP>>Все поля (даже одного типа данных) не всегда нужны. И поэтому либо функция на каждую проекцию, либо тормоза.
CK>Их можно как-инбудь передать в функцию. Ты же тоже их по сути явно передаешь через свой `select`.

В итоге у тебя будет и EDSL для передачи фильтров, и EDSL для передачи списка полей, плюс приложение будет знать о конкретных полях. Так в чём в итоге профит, если вся абстракция уже протекла?

EP>>[/q]
EP>>Вот только эту функцию (recent_customers) и придётся менять.
EP>>А в случае DAL и простых строковых запросов у тебя внутри DAL нужно будет менять много мест, так как нет нормальных средств декомпозиции.
CK>Если они не в compile-time это не значит что они плохие.

Дело не compile/run-time, а в отсутствии типизации.

CK>Кстати, как ты планируешь гарантировать существование нужных таблиц и полей в БД? Тот случай когда в коде все ок и все компилируется, но схема изменилась.

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

EP>>Нет, я говорю что легче рефакторить код, имея типизацию. Обновил схему в коде из БД — все ошибки вылезли во время компиляции.
CK>Ну можно ведь не рефактроирть.

Так ведь DAL всё равно придётся рефакторить.

CK>Не обязательно приложению заранее знать какие там у объекта поля в БД есть.

Выше, для проекций, ты именно предлагаешь вынести знание о полях в приложение.