Уже к .NET 5 EF стал достаточно умен. Можно тонко настроить LINQ-запросы, ChangeTracker (когда следить\не следить), транзакции и т.д. В целом использую EF в 90% случаев, ибо быстро и удобно.
Все неплохо, но забыли еще о главной вещи рассказать. О IQueryable и IEnumerable. Что например если есть фильтрация 'Where' и привести в .ToList() (Ienumerable) сразу, то под капотом выберутся все записи в память, а только потом фильтрация пойдет.
Здраствуйте. Очевидно что лучше сохранять список объектов в таблицу за один раз, чем 100 раз добавлять по одному. У меня есть транзакции которые приходят по времени хаотично. Как мне лучше всего сделать их сохранение? Я думаю лучше использовать промежуточное хранилище, чтобы всём скопом сохранять в бд. Пытался сделать через Apache Kafka, но сообщения там приходят по одному вместо группы. Есть ли у Вас мысли как лучше?
Привет. пару «замечаний» индексы ускоряют выборку множества где этот индекс применим. Инмемори не всегда на 100% = тому что произойдет на реальной бд, особенно, если будет бд не поддерживающая этот режим, например тот же postgresql. И в начале ролика было сказано про альтернативы, и я похоже не правильно понял, потому что подумал будет еще сравнение с ними, их плюсы и минусы. И для новичков entity делает миграции - много раз видел как бд ломают самописными запросами на обновление, а тут меньше человеческого фактора ( знаю что в ролике упоминалось, но очень вскользь)
Всегда использую EntityFrameworkCore как самую популярную ОRM или EntityFramework, но часто вижу требования на позицию джуна знания Dapper, NHibernate, хотелось бы узнать основные отличия м/у этими ORM, что они такое предоставляют что неспоcобен EntityFramework
Первый критерий, который вы услышите - производительность. Но в версии EntityFramework Core 6 почти сравняется с Dapper. То есть, если все отключить у EntityFramework, он будет такой же как Dapper
Не согласен с вердиктом "против", что это "ещё одна прослойка". Просто потому, что - эта прослойка в ЛЮБОМ СЛУЧАЕ появится. Чтобы оперировать данными на уровне приложения - надо как то данные из БД превратить в классы, объекты и т.д. А будет ли это череp EF или какой-то другой враппер - разница объективно невелика. В конце то концов тот же DataReader - "банально и неудобно". Опять же BigData - что не так с ними? Ну как-то прийдётся с ними общаться и опять же лопатить - почему не через EF? Делаем Paging output, задействум пул обработанных данных, потоки и прочие весёлые вещи.
@@SergeiCalabonga вы объяснить можете почему так делать не надо? var blogs = context.Blogs.Include(p => p.Posts).ToList() foreach(var blog in blogs) { foreach(var post in blogs.Posts) { Console.WriteLine(post.Name); } }};
"lazy loading плохо так как если вы начинаете сериализовать объекты так все грузится" просто не сериализуйте никогда модели БД, они не для этого, используйте DTO
Спасибо за видео)) как всегда, интересно и полезно)
Спасибо за высокую оценку.
Спасибо! Много хороших видео выходит у Вас на канале)
Спасибо, приятно слышать
Только начал смотреть, но коммент все равно нужен для продвижения ))
Спасибо! Очень нужен!
Спасибо, Сергей! было очень структурированно и полезно. хотелось бы посмотреть про фишки EF 6
С EntityFramework 6 всё очень похоже, хотя есть некоторые нюансы.
Отлично! Можно ещё видос с примерами запросов, чтобы с несколькими таблицами и закрученными условиями.
Можно как практическое занятие если поделитесь реальным проектом, чтобы было приближено к реальности.
Как всегда на высоте)
спасибо)
Спасибо
Уже к .NET 5 EF стал достаточно умен. Можно тонко настроить LINQ-запросы, ChangeTracker (когда следить\не следить), транзакции и т.д. В целом использую EF в 90% случаев, ибо быстро и удобно.
Согласен
Огонь!
🕺
Отличное видео, спасибо!
Спасибо за комментарий. Я старался.
Все неплохо, но забыли еще о главной вещи рассказать. О IQueryable и IEnumerable. Что например если есть фильтрация 'Where' и привести в .ToList() (Ienumerable) сразу, то под капотом выберутся все записи в память, а только потом фильтрация пойдет.
Хорошее замечание, правильное. Спасибо.
Здраствуйте. Очевидно что лучше сохранять список объектов в таблицу за один раз, чем 100 раз добавлять по одному. У меня есть транзакции которые приходят по времени хаотично. Как мне лучше всего сделать их сохранение? Я думаю лучше использовать промежуточное хранилище, чтобы всём скопом сохранять в бд. Пытался сделать через Apache Kafka, но сообщения там приходят по одному вместо группы. Есть ли у Вас мысли как лучше?
Я бы использовал MongoDb, если бы возникла подобная ситуация. Отдельно - накопление, отдельно - сохранение в БД.
@@SergeiCalabonga спасибо
Привет. пару «замечаний» индексы ускоряют выборку множества где этот индекс применим. Инмемори не всегда на 100% = тому что произойдет на реальной бд, особенно, если будет бд не поддерживающая этот режим, например тот же postgresql.
И в начале ролика было сказано про альтернативы, и я похоже не правильно понял, потому что подумал будет еще сравнение с ними, их плюсы и минусы. И для новичков entity делает миграции - много раз видел как бд ломают самописными запросами на обновление, а тут меньше человеческого фактора ( знаю что в ролике упоминалось, но очень вскользь)
1. InMemory вообще не привящана к БД
2. Про миграции кратко - в кривых руках и калькулятор зависает. 😄
Всегда использую EntityFrameworkCore как самую популярную ОRM или EntityFramework, но часто вижу требования на позицию джуна знания Dapper, NHibernate, хотелось бы узнать основные отличия м/у этими ORM, что они такое предоставляют что неспоcобен EntityFramework
Первый критерий, который вы услышите - производительность. Но в версии EntityFramework Core 6 почти сравняется с Dapper. То есть, если все отключить у EntityFramework, он будет такой же как Dapper
@@SergeiCalabonga добавлю что в ноябре будет обновление. В обновлении со слов разрабов все фичи будут связанны с производительностью +60%
Именно так я и сказал, или я что-то не пойму, что вы хотели сказать-то?
@@SergeiCalabonga ох, читал в дороге с мобильного, + привычка скорочтения по диагонали подвела
Круто, так много полезной инфы для нубаса
Добро пожаловать на канал! :)
Не согласен с вердиктом "против", что это "ещё одна прослойка". Просто потому, что - эта прослойка в ЛЮБОМ СЛУЧАЕ появится. Чтобы оперировать данными на уровне приложения - надо как то данные из БД превратить в классы, объекты и т.д. А будет ли это череp EF или какой-то другой враппер - разница объективно невелика. В конце то концов тот же DataReader - "банально и неудобно".
Опять же BigData - что не так с ними? Ну как-то прийдётся с ними общаться и опять же лопатить - почему не через EF? Делаем Paging output, задействум пул обработанных данных, потоки и прочие весёлые вещи.
Получается валидация это не бизнес бизнес логика?
Судя по всему, не такой уж и бизнес-процесс. Правильнее сказать, валидация бывает разной. И валидация ввода данных - не бизнес-процесс.
@@SergeiCalabonga Спасибо
отложенная загрузка. select не обязателен. можно так context.Blogs.Include(p => p.Posts).ToList()
Select - это projection, причем тут отложенная загрузка?
@@SergeiCalabonga в видео, чтобы не было отложенной загрузки в цикле, вы использовали select, а можно было бы include
Это примеры с сайта Microsoft, они как раз и говорят, что так делпть не надо.
@@SergeiCalabonga вы объяснить можете почему так делать не надо?
var blogs = context.Blogs.Include(p => p.Posts).ToList()
foreach(var blog in blogs) {
foreach(var post in blogs.Posts) {
Console.WriteLine(post.Name);
}
}};
"lazy loading плохо так как если вы начинаете сериализовать объекты так все грузится" просто не сериализуйте никогда модели БД, они не для этого, используйте DTO
Да, это тоже вариант.
context.Configuration.AutoDetectChangesEnabled = false;
Все смешалось, люди, кони
Конюшня?