Здравствуйте, Evgeny.Panasyuk, Вы писали:

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

Что есть "нормальные средства декомпозиции"? Как это должно выглядеть в коде?

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

Ясно. Думаю что код на таком уровне не должен работать. Это чревато ошибками и (что намного хуже) проблемами с производительностью. Так как where clauses у тебя разбросаны по всему коду и чтобы понять, какие индексы нужно создавать, придется собирать статистику с работающего приложения, профилировать и тд. Ну а потом кто-нибудь добавить еще один фильтр и придется все начинать сначала.

Когда же у тебя есть DAL, ты будешь работать через него и все эти where можно просто проскроллить и глазами посмотреть в одном месте. И выглядит это обычно не так как ты описал а как-то так:

auto publisher = DAL.get_publisher(id);  // executes `SELECT * FROM "Publishers" WHERE id = 42`
...
Filter flt;
flt.include_if(Placement.Fields.RECT, Filter.GT, BoundingRectangle(100, 200));
auto placements_list = publisher.get_placements(filter);  // executes `SELECT * FROM "Placements" WHERE id = 42 and (width > 200 and height > 100)`

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

DAL можно вынести в отдельный модуль, второе предложение — не понял как это, честно говоря, тебе что так что так нужен слой, который бы абстрагировал работу с БД, чтобы код приложения работал с объектами в памяти а не генерировал (пусть и через хитрый EDSL) запросы к БД, так что я вижу только увеличение сложности и уровня абстракции

Здравствуйте, Evgeny.Panasyuk, Вы писали:

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

Что есть "нормальные средства декомпозиции"? Как это должно выглядеть в коде?

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

Ясно. Думаю что код на таком уровне не должен работать (он не должен знать что у тебя есть табличка foo и поле id, не важно как, в виде EDSL или части имени метода). Это чревато ошибками и (что намного хуже) проблемами с производительностью. Так как where clauses у тебя разбросаны по всему коду и чтобы понять, какие индексы нужно создавать, придется собирать статистику с работающего приложения, профилировать и тд. Ну а потом кто-нибудь добавить еще один фильтр и придется все начинать сначала.

Когда же у тебя есть DAL, ты будешь работать через него и все эти where можно просто проскроллить и глазами посмотреть в одном месте. И выглядит это обычно не так как ты описал а как-то так:

auto publisher = DAL.get_publisher(id);  // executes `SELECT * FROM "Publishers" WHERE id = 42`
...
Filter flt;
flt.include_if(Placement.Fields.RECT, Filter.GT, BoundingRectangle(100, 200));
auto placements_list = publisher.get_placements(filter);  // executes `SELECT * FROM "Placements" WHERE id = 42 and (width > 200 and height > 100)`

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

DAL можно вынести в отдельный модуль, второе предложение — не понял как это, честно говоря, тебе что так что так нужен слой, который бы абстрагировал работу с БД, чтобы код приложения работал с объектами в памяти а не генерировал (пусть и через хитрый EDSL) запросы к БД, так что я вижу только увеличение сложности и уровня абстракции