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

S>Нет. Основная проблема с производительностью в ОRM — в том, что вместо уместных запросов (типа select sum(orderdetail.total) as order total from orderdetail where orderid = @orderId) они провоцирут писать навигационный код в стиле var orderTotal = 0.0; foreach (orderDetail in order.Details) orderTotal += orderDetail.total;

Ты из какого года пишешь? ))
Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое.
То бишь, параллелят, если данные уже в памяти.


S>Всё остальное — уже последствия.

Это последствия устаревших технологий и устаревших же рассуждений.


T>>Бизнес логика, да, может меняться независимо от БД, поэтому, повторюсь нельзя помещать логику в объекты, отображением которых в БД занимается ORM. А лучше вообще не показывать эти объекты коду, который занимается бизнес-логикой. Данные в базе это данность, но вот структура БД может и будет меняться так же, как и бизнес логика. И очень удобно, когда можно менять одно независимо от другого.
S>Для этого пригодна только анемичная модель и light-wight ORM, которые не предлагают ни lazy load, ни unit of work.

Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву.

Но уже относительно давно есть успешно используемые компиллируемые технологии, на которых обработка данных не отделена от их объявления/типизации (иначе компиллируемости не будет). Причём, некоторые из этих технологий основаны на очень даже неплохих "полноценных движках БД" унутре, не уступающих MS SQL (если у того убрать SQL и всё вокруг него, а оставить только подсистему хранения/выборки данных с учётом транзакций, индексов и т.д.).