возня с orm, часть 2

[wizzard]

оно вообще неплохо. работает. только вот мне как-то кажется, что компилить C# в AST, AST в SQL, SQL в query, query в план запроса (см. серию постов zabivator про устройство БД) - это какой-то оверкилл. просадка перформанса в дебаге оч существенная, по крайней мере.

предметная область обычно лучше мапится на динамическое ОО (спорно, конечно, но что делать, если например взяли и ввели проездные билеты на кол-во поездок, в дополнение к проездным на определенный срок)

так вот, кажется, что идеальное API для БД и для работы с файлами – это что-то вроде коллекций, которые хранятся или в памяти, или на носителе, и имеет copy-by-reference (для RAM или private storage) или copy-by-value (для сьемных носителей) семантику. ну и индексами они могут заведовать, чего уж там, это полезно :)

что-то подобное, кажется, приветствуют ребята из Фантома (dz и т.д.)

UPD: ну, не все так радужно, судя по совместному с ev_genus экспириенсу, подводных камней там тонны :) в основном потому, что если выбросить из головы процессы, файлы и потоки, то надо всё заново придумывать. как говорится, техника безопасности написана кровью.

Comments

[volodymir-k.livejournal.com]

> AST в SQL, SQL в query
> идеальное API для БД и для работы с файлами – это что-то вроде коллекций

Один из уровней ADO, который ниже ICommand -- смотрели?
Вроде как даже реализовано в MS SQL Server, не уверен, что выдано наружу.

Оно-то может и легко, только поддерживать (изменять при изменении БД, напр.) такой навигационный код... впрочем, часто не хуже, чем SQL-основанный.

Ностальгия -- писать на MS Access-подобном.

[wizzard]

> реализовано в MS SQL Server, не уверен, что выдано наружу.

У меня сейчас Mono, Linux, SQLite локально и постгрес на удаленном сервере, и есть подозрения что через неделю этим же бинарникам придется научиться работать на WinMobile. Так что секас с совместимостью еще тот.

[wizzard]

Я поэтому и полез в LINQ, что не хочется учить тучу диалектов.