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

EP>>DAL как реализовывать? На каком языке/библиотеке?
CK>Я как правило предпочитаю нативную клиентскую библиотеку использовать ну и обычные текстовые запросы + prepare для некоторых.

Для большого количества сложных запросов это неудобно — нет типизации запросов и нормальных средств декомпозиции.
Если же запросов немного — то думаю не критично.

EP>>Где делать требуемые проекции, фильтрации? Всё в DAL расписывать?
CK>Да, а что такого? Вынести в отдельный модуль, чтобы все приложение работало через какой-нибудь абстрактный интерфейс и не знало вообще, с чем оно работает, с БД, или еще каким-нибудь источником данных.
CK>...
CK>И что ты понимаешь под фильтрациями? Where statement в SQL или обработку результатов запроса?

Where clause. В разных частях программы могут потребоваться разные фильтры, разный набор колонок в select.
В итоге вместо from(foo).where(foo.id > 42_i).select(foo.value, foo.id, foo.number) у тебя в DAL будут функции вида foo_where_id_gt_42_select_value_id_number на каждый чих.

CK>Тут можно свапнуть БД на другую (например в тестах использовать sqlite вместо постгреса или вообще какой-нибудь nosql).

Возможность swap'а БД может быть внутри библиотеки запросов. То есть пишешь запрос на типизированном EDSL, а выхлоп будет отличаться в зависимости от БД.

CK>и при каждом изменении схемы переписывать код

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