Уже к .NET 5 EF стал достаточно умен. Можно тонко настроить LINQ-запросы, ChangeTracker (когда следить\не следить), транзакции и т.д. В целом использую EF в 90% случаев, ибо быстро и удобно.
Все неплохо, но забыли еще о главной вещи рассказать. О IQueryable и IEnumerable. Что например если есть фильтрация 'Where' и привести в .ToList() (Ienumerable) сразу, то под капотом выберутся все записи в память, а только потом фильтрация пойдет.
Не согласен с вердиктом "против", что это "ещё одна прослойка". Просто потому, что - эта прослойка в ЛЮБОМ СЛУЧАЕ появится. Чтобы оперировать данными на уровне приложения - надо как то данные из БД превратить в классы, объекты и т.д. А будет ли это череp EF или какой-то другой враппер - разница объективно невелика. В конце то концов тот же DataReader - "банально и неудобно". Опять же BigData - что не так с ними? Ну как-то прийдётся с ними общаться и опять же лопатить - почему не через EF? Делаем Paging output, задействум пул обработанных данных, потоки и прочие весёлые вещи.
Привет. пару «замечаний» индексы ускоряют выборку множества где этот индекс применим. Инмемори не всегда на 100% = тому что произойдет на реальной бд, особенно, если будет бд не поддерживающая этот режим, например тот же postgresql. И в начале ролика было сказано про альтернативы, и я похоже не правильно понял, потому что подумал будет еще сравнение с ними, их плюсы и минусы. И для новичков entity делает миграции - много раз видел как бд ломают самописными запросами на обновление, а тут меньше человеческого фактора ( знаю что в ролике упоминалось, но очень вскользь)
Здраствуйте. Очевидно что лучше сохранять список объектов в таблицу за один раз, чем 100 раз добавлять по одному. У меня есть транзакции которые приходят по времени хаотично. Как мне лучше всего сделать их сохранение? Я думаю лучше использовать промежуточное хранилище, чтобы всём скопом сохранять в бд. Пытался сделать через Apache Kafka, но сообщения там приходят по одному вместо группы. Есть ли у Вас мысли как лучше?
Всегда использую EntityFrameworkCore как самую популярную ОRM или EntityFramework, но часто вижу требования на позицию джуна знания Dapper, NHibernate, хотелось бы узнать основные отличия м/у этими ORM, что они такое предоставляют что неспоcобен EntityFramework
Первый критерий, который вы услышите - производительность. Но в версии EntityFramework Core 6 почти сравняется с Dapper. То есть, если все отключить у EntityFramework, он будет такой же как Dapper
@@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) сразу, то под капотом выберутся все записи в память, а только потом фильтрация пойдет.
Хорошее замечание, правильное. Спасибо.
Не согласен с вердиктом "против", что это "ещё одна прослойка". Просто потому, что - эта прослойка в ЛЮБОМ СЛУЧАЕ появится. Чтобы оперировать данными на уровне приложения - надо как то данные из БД превратить в классы, объекты и т.д. А будет ли это череp EF или какой-то другой враппер - разница объективно невелика. В конце то концов тот же DataReader - "банально и неудобно".
Опять же BigData - что не так с ними? Ну как-то прийдётся с ними общаться и опять же лопатить - почему не через EF? Делаем Paging output, задействум пул обработанных данных, потоки и прочие весёлые вещи.
Огонь!
🕺
Как всегда на высоте)
спасибо)
Спасибо
Привет. пару «замечаний» индексы ускоряют выборку множества где этот индекс применим. Инмемори не всегда на 100% = тому что произойдет на реальной бд, особенно, если будет бд не поддерживающая этот режим, например тот же postgresql.
И в начале ролика было сказано про альтернативы, и я похоже не правильно понял, потому что подумал будет еще сравнение с ними, их плюсы и минусы. И для новичков entity делает миграции - много раз видел как бд ломают самописными запросами на обновление, а тут меньше человеческого фактора ( знаю что в ролике упоминалось, но очень вскользь)
1. InMemory вообще не привящана к БД
2. Про миграции кратко - в кривых руках и калькулятор зависает. 😄
Круто, так много полезной инфы для нубаса
Добро пожаловать на канал! :)
Отличное видео, спасибо!
Спасибо за комментарий. Я старался.
Здраствуйте. Очевидно что лучше сохранять список объектов в таблицу за один раз, чем 100 раз добавлять по одному. У меня есть транзакции которые приходят по времени хаотично. Как мне лучше всего сделать их сохранение? Я думаю лучше использовать промежуточное хранилище, чтобы всём скопом сохранять в бд. Пытался сделать через Apache Kafka, но сообщения там приходят по одному вместо группы. Есть ли у Вас мысли как лучше?
Я бы использовал MongoDb, если бы возникла подобная ситуация. Отдельно - накопление, отдельно - сохранение в БД.
@@SergeiCalabonga спасибо
Всегда использую EntityFrameworkCore как самую популярную ОRM или EntityFramework, но часто вижу требования на позицию джуна знания Dapper, NHibernate, хотелось бы узнать основные отличия м/у этими ORM, что они такое предоставляют что неспоcобен EntityFramework
Первый критерий, который вы услышите - производительность. Но в версии EntityFramework Core 6 почти сравняется с Dapper. То есть, если все отключить у EntityFramework, он будет такой же как Dapper
@@SergeiCalabonga добавлю что в ноябре будет обновление. В обновлении со слов разрабов все фичи будут связанны с производительностью +60%
Именно так я и сказал, или я что-то не пойму, что вы хотели сказать-то?
@@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
Да, это тоже вариант.
Получается валидация это не бизнес бизнес логика?
Судя по всему, не такой уж и бизнес-процесс. Правильнее сказать, валидация бывает разной. И валидация ввода данных - не бизнес-процесс.
@@SergeiCalabonga Спасибо
context.Configuration.AutoDetectChangesEnabled = false;
Все смешалось, люди, кони
Конюшня?