Entity Framework и производительность, попытка вторая

[SVVer]

Хотелось бы понять, что заставляет Вас использовать EF, раз уже так много всего написано для ускорения? Это legacy code? Или есть еще какие-то объективные причины? Ведь в комментариях к первой статье уже предлагали linq2db, например.

[VladVR]

Из всего этого, linq2db предлагает лишь одну операцию, что у меня под номером 1, и она с оговорками, операция считай такая же неюзабельная, как и OracleBulkCopy. Т.е. все эти операции придется реализовать для linq2db в той же мере, что и для EF. Второй, небольшой минус — цитата из readme «Now let's create a POCO class», EF предлагает всю схему сгенерировать с базы данных. Использование t4 templates неплохо бы улучшило эту разработку. А linq2entities провайдер там достаточно продвинут, я такого не ожидал.
А так, основная причина использовать EF(как и например AngularJs) это заказчики и архитекторы. Т.к. их волнует больше поддерживаемость компонентов и коммюнити вокруг них. Эти два аспекта решают насколько легко будет вводить новых разработчиков в проект, и насколько вероятно будет наткнуться на проблему, для которой нельзя будет быстро найти решение в интернетах.

[VladVR]

Поизучал еще немного, оказалось там есть набор t4 для генерации. Странно что информации об этом нет в readme на главной их странице, а есть лишь в другом репозитории, в тестовом проекте.

[Kefir]

При добавлении nuget пакета linq2db добавляются все T4-шаблоны, причем генерацию классов можно легко кастомизировать. Все инструкции лежат в ридми-файле, который ставится вместе с пакетом. Стоило все-таки попробовать.

[RouR]

На 100 вставок EF посылает в базу 100 запросов на вставку, никак не пытаясь их сгруппировать

Install-Package EFUtilities

public void InsertAsync(IEnumerable<T> entities, int batchSize = 1000)
{...
  using (var db = (DbContext) Activator.CreateInstance(name))
  {
     EFBatchOperation.For(db, db.Set<T>()).InsertAll(entities);
     db.SaveChangesAsync();
  }

github.com/MikaelEliasson/EntityFramework.Utilities

[ilya-chumakov]

Вот только EntityFramework.Utilities также использует SqlBulkCopy для множественной вставки:
github.com/MikaelEliasson/EntityFramework.Utilities/blob/master/EntityFramework.Utilities/EntityFramework.Utilities/SqlQueryProvider.cs

Генерацию INSERT-инструкций в EF, а также как самостоятельно использовать SqlBulkCopy, я подробно рассматривал тут, если интересно: habrahabr.ru/post/251397

[VladVR]

Да, похожий аналог, дающий несколько меньше функций, чем есть у меня. В частности они никак не работают ни с Identity, ни c Sequence. По крайней мере не нашел. Сценарий достаточно распространен, если модели хоть сколь нибудь комплексные — вставить записи в одну таблицу, затем полученные ключи использовать для foreign-key полей при вставке во вторую таблицу.
Я пару часов ломал голову, не мог понять почему там производительность BulkInsert операции выше, профилировал, в упор не видел. Оказалось, что они используют настройки по умолчанию, а у меня опции включают CheckConstraints, на таблице есть foreign-key constraint. Соответственно мой метод упадет если попытаться вставить невалидные данные, а их метод позволит вставить невалидные данные. Отключил для теста у себя опции — скорость стала 1 в 1.

[ilya-chumakov]

Почему поддерживается только Database-first?
Развивать и держать на плаву планируете?

Интерес у меня отнюдь не праздный — обдумываю, стоит ли публиковать собственный похожий проект.

[VladVR]

В качестве источника используется edmx схема, которой для случая Code-first просто нет. Соответственно в сторону поддержки Code-first развивать не планирую.
Опять же, все проекты, в которых я участвовал база данных была первостепенна. Соответственно компонент прошел испытания на них. Для code-first пришлось бы делать какой нибудь проект «для себя», иначе сколь нибудь реальных жизненных испытаний он бы был лишен.
У меня сейчас более интересная задумка в работе в этом же направлении. Более высокоуровневая.