Сейчас принято писать асинхронные методы, да и хорошая практика для сервера
Ваша абстракция понятна, только, я не помню в своем случае когда коня/ORM меняли на переправе. Будут сидеть на EF до конца. Учитывая что абстракции резко ухудшают производительность как самой программы так и программистов, я бы задумался нужны ли они в таком виде. DbContext уже сам по себе неслабый репозиторий. Пряча от разработчиков LINQ, вы просто усложняете себе жизнь. IMHO, абстракции лучше строить на уровне бизнес задач/сервисов и в крайнем случае над отдельными сущностями.
Простой пример, что вы сделаете когда надо достать Id первых 100 пользователей, у которых установлен язык английский? Что вам дадут два репозитория которые возвращают целые таблицы в память, а вам нужно достать всего сотню целых чисел из данных связанных двумя таблицами?
Тут приходит на помощь LINQ, репозитории могут возвращать IQueryable. Только зачем эти репозитории тогда, если они просто враппер над DbContext? Я, например, не вижу в них смысла, это ухудшает читабельность, нагружает контроллер дополнительными зависимостями. Если контроллер большой, в него ижектят с 20-к репозиториев, несмотря на то что в основном нужны только несколько на один запрос.
Слегка сумбурно, но это я сейчас наблюдаю во всех ASP.NET проектах в которых просят помочь разобраться с производительностью. Написано по патернам, которые я бы уже и сам назвал антипатернами.
Это было познавательно с IIListProvider. Будем знать.
А тест надо переписать чтобы забрать зависимость от этой фичи. Умом понимаешь, что ToList будет быстрее чем ToArray, а тут как обухом.
Если чесно, я думаю они правильно поступили. EF 6 настолько уныло строит SQL запросы, что слеза наворачивается и одна надежда на мозг SQL оптимизатора.
Но, также замечу, что подход с Lazy Loading, на том же проекте привнес значительные тормоза у реальных пользователей системы с большими обьемами данных.
Сам поучавствовал в этом сраче 2015 года. Яркий пример как подход к базе данных как к тупому хранилищу объектов заканчиватся плачевно.
А вы знаете отличие IQueryable от IEnumerable или просто бездумно скопировали дефиницию из стандартной библиотеки? Так вам C++ ников долго придется об стенку до полного прозрения или наоборот?
Потому EF не может. Хранимки это и есть костыли. Шаг влево, шаг вправо — FromSql или хранимки. Выигрыш использования LINQ слегка пропал. Если в инструменте сплошные ограничения, я чувствую себя как на минном поле. Но ниче, потом так и рождаются сертифицированные специалисты — они знали, они плавали.
Может еще и оконные функции вспомним? И, думаю, никогда или не очень скоро будет поддерживаться. Разрабатывают EF Core очень квалифицированные специалисты, но к реальной разработке высоконагруженных систем, имеющие далекое отношение. По этому не удивляйтесь поставленным приоритетам.
Как это не завезли??? Видать «конкуренты» до сих пор абстрактной «фигней» над абстрактным хранилищем страдают.
Для жаждущих пока только для 2.1, на след неделе докручу к 3.0, а то немножко там нарефакторили и надо легкий тюнинг — linq2db.EntityFrameworkCore
Редко меня можно удивить SQL запросом который я не могу на LINQ написать.
Уже лучше. EF Core 3.0 имеет еще более допиленный Change Tracker, Code First, и чуток лучший парсер Expression Tree, но это не значит лучший SQL. Использовать ли это в продакшине, хотя нет, использовать ли это для высоких нагрузок — решать вам.
Мой пример высосан из пальца :) Я не работал с Jsonb в Postgres, просто почитал документацию и решил что можно показать как это гибко.
Если найдете то, что мы не можем превратить в SQL — вперед, создали issue в linq2db репозитории и я лично пошаманю.
С документацией проблема, только начинаешь ее писать — бац реквест на фичу и, к сожалению, плохие мы писатели документации. Спасаеют ссылки на тесты, где человек может увидеть как это работает.
Про типы не переживайте, есть механизм перехвата создания такого экспрешина, крутим как хотим без изменения основного кода. На этом, кстати, создана поддержка оконных функций — работает как часы.
Есть тестовый проект с бенчмарками, так и не оформился в статью, возможно будет вторая реинкарнация на BenchmarkDotNet. Итог очевиден, мы быстрее EF Core, да и Dapper, несмотря на их синтетические тесты — так вот же.
Весь цирк этих тестов выбрать тривиальную вещь и замапать, и никто не ганял это в потоках, с асинками.
Библиотека заточена на самый что ни на есть перформанс, в полоть до того что инлайнить в SQL, а что параметрами прокидывать. И часто бывает, что лучше параметры выкинуть. Гонка за производительностью заставляет библиотеку быть аскетичной но предсказуемой.
Вот и можете, кстати, стать одним из тестеров зверушки, так как мы не работам с EF и поддержали только то что увидели. Но то что у нас SQL лучше и эффективней, я вам гарантирую, хотя бы по тому что библиотека развивается уже второе десятилетие людьми которые знают как готовить базы данных.
Ну что же. Добавьте в свой велосипед еще скорости FastExpressionCompiler .
И все-таки странно что Automapper слил, есть им еще куда стремиться, хотя думал по той тропинке столько зверей потопталось, что дальше уже некуда.
Скажем так, в linq2db такие экстеншины пишутся с полпинка
public static class Jsonb
{
[Sql.Expression("{0}->>{1}", ServerSideOnly = true, InlinePrameters = true)]
public static T Value<T>(object field, string propName)
{
throw new NotImplementedException();
}
}
А зверушка позволяет перенаправлять дерево выражений на наш Linq парсер. Да и по ссылке просто почитайте BulkCopy, Delete From, Update From, Insert From.
То что EF от вас спрятал и заставил писать на хранимках или Dapper, вполне себе легко пишется на linq.
Вот вполне себе может понадобиться апдейтнуть одно поле в Jsonb:
ctx.SomeItems
.Where(e => Jsonb.Value<string>(e.Field, "SomeValue") == "Old Value")
.Set(e => e.Field, e => Jsonb.Set(e.Field, "SomeValue", "New Value"))
.Update();
Для этого конечно же надо добавить экстеншин
public static class Jsonb
{
[Sql.Expression("jsonb_set({0}, {1}, {2})", ServerSideOnly = true, InlinePrameters = true)]
public static T Set<T>(T field, string path, string newValue)
{
throw new NotImplementedException();
}
}
Вот так, в обход ChangeTracker, мы изменили поле в нескольких записях не потянув ни одной записи.
А есть, те кому удалось переслать свою игрушку для MK-61 в «Техника молодежи» с публикацией?
Эх были времена, я парочку послал, но так и не дошло и я расстроился кажется, совсем маленький был ;)
Огромный челенж был вписаться в 105, когда на листочке получалось 160 шагов программы.
Думаю вам надо было сразу смотреть в исходники Npgsql.EntityFrameworkCore, где они добавляли поддержку Range.
Очень надеюсь что это все не поломается в 3.0, кстати проверьте.
Если станет совсем не в моготу запустить нужную выборку — попробуйте нашу зверушку (ну так как-то называем) linq2db.EntityFrameworkCore. Легким тюнингом, можно Json и в linq ганять, например при использовании LATERAL и jsonb_to_recordset.
Опять же, вы написали типичный CROSS JOIN. from + from ничего другог не родит, если у ORM нету дополнительных мозгов по анализу запроса.
И да вы правы, то что сейчас предлагает LINQ, немножко путает. Я краем глаза видел что у Microsoft есть планы по его расширению, но когда это будет — мне не известно.
Offtop
Я тоже как то задумался над этой неоднозначностью и пришла идея просто добавить еще парочку функций и унифицировать синтаксис. Предупреждаю, что сие работает только для linq2db
from t in mainTable
from st in subTable.InerJoin(st => st.Id == t.Id)
from lt in subTable.LeftJoin(lt => lt.Id == t.Id)
from rt in subTable.RightJoin(rt => rt.Id == t.Id)
from ft in subTable.FullJoin(ft => ft.Id == t.Id)
select new
{
t,
st,
lt,
rt,
ft
}
Как оказалось, это намного удобней и пересталять джоины местами, и менять LEFT на INNER и наоборот намного проще.
Вы столкнулись всего лишь с ограниченностью EF в плане выборок. Я пишу такие выборки что переплюнуть чистым сиквелом сложно.
Есть кейсы, когда SQL оптимизатору сносит крышу и ничего вменяемого он соорудить не может, вот и идут в ход временные таблицы.
Как там в EF со временными таблицами? Сори гипотетический вопрос.
Редкий но распространенный кейс, отфильтровать данные по 10000 записей. В IN это не влазит, что будем делать? Какую сторед процедуру будем писать?
Ваша абстракция понятна, только, я не помню в своем случае когда коня/ORM меняли на переправе. Будут сидеть на EF до конца. Учитывая что абстракции резко ухудшают производительность как самой программы так и программистов, я бы задумался нужны ли они в таком виде. DbContext уже сам по себе неслабый репозиторий. Пряча от разработчиков LINQ, вы просто усложняете себе жизнь. IMHO, абстракции лучше строить на уровне бизнес задач/сервисов и в крайнем случае над отдельными сущностями.
Простой пример, что вы сделаете когда надо достать Id первых 100 пользователей, у которых установлен язык английский? Что вам дадут два репозитория которые возвращают целые таблицы в память, а вам нужно достать всего сотню целых чисел из данных связанных двумя таблицами?
Тут приходит на помощь LINQ, репозитории могут возвращать IQueryable. Только зачем эти репозитории тогда, если они просто враппер над DbContext? Я, например, не вижу в них смысла, это ухудшает читабельность, нагружает контроллер дополнительными зависимостями. Если контроллер большой, в него ижектят с 20-к репозиториев, несмотря на то что в основном нужны только несколько на один запрос.
Слегка сумбурно, но это я сейчас наблюдаю во всех ASP.NET проектах в которых просят помочь разобраться с производительностью. Написано по патернам, которые я бы уже и сам назвал антипатернами.
А тест надо переписать чтобы забрать зависимость от этой фичи. Умом понимаешь, что ToList будет быстрее чем ToArray, а тут как обухом.
Но, также замечу, что подход с Lazy Loading, на том же проекте привнес значительные тормоза у реальных пользователей системы с большими обьемами данных.
Сам поучавствовал в этом сраче 2015 года. Яркий пример как подход к базе данных как к тупому хранилищу объектов заканчиватся плачевно.
FastReport прекрасно заменяется этим DevExpress XtraReports
Для жаждущих пока только для 2.1, на след неделе докручу к 3.0, а то немножко там нарефакторили и надо легкий тюнинг — linq2db.EntityFrameworkCore
Редко меня можно удивить SQL запросом который я не могу на LINQ написать.
www.smashcompany.com/technology/docker-is-a-dangerous-gamble-which-we-will-regret
www.nuget.org/packages/System.Text.Json
Если найдете то, что мы не можем превратить в SQL — вперед, создали issue в linq2db репозитории и я лично пошаманю.
С документацией проблема, только начинаешь ее писать — бац реквест на фичу и, к сожалению, плохие мы писатели документации. Спасаеют ссылки на тесты, где человек может увидеть как это работает.
Про типы не переживайте, есть механизм перехвата создания такого экспрешина, крутим как хотим без изменения основного кода. На этом, кстати, создана поддержка оконных функций — работает как часы.
Есть тестовый проект с бенчмарками, так и не оформился в статью, возможно будет вторая реинкарнация на BenchmarkDotNet. Итог очевиден, мы быстрее EF Core, да и Dapper, несмотря на их синтетические тесты — так вот же.
Весь цирк этих тестов выбрать тривиальную вещь и замапать, и никто не ганял это в потоках, с асинками.
Библиотека заточена на самый что ни на есть перформанс, в полоть до того что инлайнить в SQL, а что параметрами прокидывать. И часто бывает, что лучше параметры выкинуть. Гонка за производительностью заставляет библиотеку быть аскетичной но предсказуемой.
Вот и можете, кстати, стать одним из тестеров зверушки, так как мы не работам с EF и поддержали только то что увидели. Но то что у нас SQL лучше и эффективней, я вам гарантирую, хотя бы по тому что библиотека развивается уже второе десятилетие людьми которые знают как готовить базы данных.
И все-таки странно что Automapper слил, есть им еще куда стремиться, хотя думал по той тропинке столько зверей потопталось, что дальше уже некуда.
А зверушка позволяет перенаправлять дерево выражений на наш Linq парсер. Да и по ссылке просто почитайте BulkCopy, Delete From, Update From, Insert From.
То что EF от вас спрятал и заставил писать на хранимках или Dapper, вполне себе легко пишется на linq.
Вот вполне себе может понадобиться апдейтнуть одно поле в Jsonb:
Для этого конечно же надо добавить экстеншин
Вот так, в обход ChangeTracker, мы изменили поле в нескольких записях не потянув ни одной записи.
Эх были времена, я парочку послал, но так и не дошло и я расстроился кажется, совсем маленький был ;)
Огромный челенж был вписаться в 105, когда на листочке получалось 160 шагов программы.
Очень надеюсь что это все не поломается в 3.0, кстати проверьте.
Если станет совсем не в моготу запустить нужную выборку — попробуйте нашу зверушку (ну так как-то называем) linq2db.EntityFrameworkCore. Легким тюнингом, можно Json и в linq ганять, например при использовании LATERAL и
jsonb_to_recordset.И да вы правы, то что сейчас предлагает LINQ, немножко путает. Я краем глаза видел что у Microsoft есть планы по его расширению, но когда это будет — мне не известно.
Offtop
Я тоже как то задумался над этой неоднозначностью и пришла идея просто добавить еще парочку функций и унифицировать синтаксис. Предупреждаю, что сие работает только для linq2db
Как оказалось, это намного удобней и пересталять джоины местами, и менять LEFT на INNER и наоборот намного проще.
Есть кейсы, когда SQL оптимизатору сносит крышу и ничего вменяемого он соорудить не может, вот и идут в ход временные таблицы.
Как там в EF со временными таблицами? Сори гипотетический вопрос.
Редкий но распространенный кейс, отфильтровать данные по 10000 записей. В IN это не влазит, что будем делать? Какую сторед процедуру будем писать?