Комментарии 17
"Такие пары называют условности"
Это перевод?
Получилось достаточно кратко. Не будет лишним упомянуть, хотя бы в комментариях, ORM для .NET и .NET Core без change tracking, которая отличается лучшей производительностью — linq2db. В связке с чем-нибудь наподобие FluentMigrator в некоторых случаях может заменить EntityFramework. Ещё есть Dapper, но это инструмент более низкоуровневой категории.
Incidentally, further on in the SO post, someone makes a comment about settingAutoDetectChangesEnabled
andLazyLoadingEnabled
tofalse
. This has no effect on the performance (or lack thereof, at least in EF Core.)
AsNoTracking
в EFCore выключит отслеживание изменений, но на производительность не повлияет, судя по замерам и выводам из статьи Choose Your Poison on the rPi: Entity Framework, Linq2DB, or ADO.NET. Причём в секции Querying Large Sets of Data есть ещё более интересные графики. Любопытно, как там linq2db умудряется работать быстрее, чем ADO.NET. Скорее всего, linq2db делает хитрые оптимизации, а код автора — нет.
Не все упирается в выборку, хотя тут linq2db даст фору по качеству SQL.
Например изменение записи в EF это два обращения к базе данных, и то желательно в транзакции.
- Достать обьект из базы полностью
- Изменить свойство
- SaveChanges
В linq2db это однин стейтмент и ничего на клиент тянуть не пришлось
db.Products
.Where(p => p.ProductId == dto.ProductId)
.Set(p => p.SoldDate, () => Sql.CurrentTimestamp)
.Set(p => p.IsSold, true)
.Update();
Конечно возможно приаттачить обьект к ChangeTracker, только делают это редко.
Также из примера видно что мы использовали текущую дату сервера. Что в EF проблематично.
Вот из таких кирпичиков и растет перформанс. Чем дальше мы от SQL, тем больше мы полагаемся на архитектуру всемогутора, а она не всегда эфективна.
В EF.core (насколько я помню) многие-ко-многим без ручной реализации расшивочной таблицы так и не завезли.
Традиционно, в преддверии старта курсов начинаем публиковать полезный материал.
а где, собственно, полезный материал ?
Дело не в SQL, в EF это было из коробки (на самом деле есть во многих ORM'ах).
(я понимаю что это синтаксический сахар и в SQL всё также используется расшивочная таблица)
На MSDN есть табличка с разницей между EF и EF.core https://docs.microsoft.com/ru-ru/ef/efcore-and-ef6/
Навигация "многие ко многим": EF(Да), (EF.core) Запланировано на 5.0 (#19003)
А точно в Ef.Core завезли поддержку Edmx? Вроде всегда декларировалось, что этого не будет потому, что не будет никогда....
На MSDN, говорят что не запланировано https://docs.microsoft.com/ru-ru/ef/efcore-and-ef6/
Формат модели: (EF) — EDMX (XML) Да, (EF.core) — Поддержка не запланирована (2)
2 Некоторые функции EF6 не будут реализованы в EF Core. Эти функции зависят от базовых EDM EF6 и (или) являются сложными функциями с относительно низкой рентабельностью инвестиций. Мы всегда приветствуем обратную связь, но несмотря на то, что EF Core предоставляет многие функции, недоступные в EF6, для EF Core, наоборот, невозможно поддерживать все функции EF6.
Entity Framework Core