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

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

_>>>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1

Автор: gandjustas
Дата: 13.04.15

. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.
S>> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.

_>Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )

_>В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))
разумно предварительно скомпилировав часто используемые запросы. Не вижу проблем.
А запрос обычно выполняется значительно дольше. Даже просто перекачка данных по сети.

_>>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.
S>>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx



_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.

Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя.
Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.