Разница между LINQ lazy loading и eager loading
В случае lazy loading зависимые таблицы (дочерние объекты) не загружаются автоматически с родительскими, а загрузятся в тот момент, когда они понадобятся. В LINQ по умолчанию используется lazy loading.
В случае eager loading зависимые объекты загружаются автоматически с родительской таблицей. Для того, чтобы использовать eager loading, нужно применить метод Include().
🐸 Библиотека собеса по С#
В случае lazy loading зависимые таблицы (дочерние объекты) не загружаются автоматически с родительскими, а загрузятся в тот момент, когда они понадобятся. В LINQ по умолчанию используется lazy loading.
В случае eager loading зависимые объекты загружаются автоматически с родительской таблицей. Для того, чтобы использовать eager loading, нужно применить метод Include().
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Покупать новый курс каждый раз, когда меняется рабочая задача, — довольно странная механика. Нашли альтернативу 👇
🥱1
Forwarded from Proglib.academy | IT-курсы
Сегодня хочется разобраться в AI-агентах. Через пару недель появляется задача, где нужны алгоритмы. Потом понимаешь, что неплохо бы освежить Python или математику для Data Science.
В подписку Proglib Academy входят все основные направления — AI, ML, Python, алгоритмы, математика для DS и другие курсы, а ещё закрытый видеохаб с вебинарами практиков.
Начать можно с пробного месяца. Если решите остаться, его стоимость зачтётся при оформлении подписки
Please open Telegram to view this post
VIEW IN TELEGRAM
Долгоживущий .NET-сервис постепенно “распухает” по памяти без явных LOH-пиков. В дампе видно множество делегатов/лямбд, Timer и CancellationTokenRegistration, висящих в Gen2. Как диагностировать и устранить утечки из-за событий/таймеров/регистраций?
Проанализировать пути до корней (dotMemory/PerfView/dotnet-dump gcroot) — проверить коллекции подписчиков и списки делегатов у источников событий. Убедиться, что:
✍🏻 все подписки снимаются в Dispose/IAsyncDisposable;
✍🏻 CancellationToken.Register хранит IDisposable и корректно Dispose();
✍🏻 Timer/PeriodicTimer/System.Threading.Channels закрываются/завершаются;
✍🏻 не удерживаются замыканиями большие объекты/this.
При необходимости — слабые события/WeakReference, паттерн “own the lifetime”, и тест “утечек” в CI с сравнением heap-снимков.
Библиотека собеса по С#
✍🏻 все подписки снимаются в Dispose/IAsyncDisposable;
✍🏻 CancellationToken.Register хранит IDisposable и корректно Dispose();
✍🏻 Timer/PeriodicTimer/System.Threading.Channels закрываются/завершаются;
✍🏻 не удерживаются замыканиями большие объекты/this.
При необходимости — слабые события/WeakReference, паттерн “own the lifetime”, и тест “утечек” в CI с сравнением heap-снимков.
Библиотека собеса по С#
❤1🥱1
⚡️⚡️Актуальные темы .NET на DotNext 2026
В .NET одновременно происходит много интересного: C# получает новые возможности, .NET 10 меняет расклад между Native AOT и JIT, а в разработке появляются ИИ-агенты, которые берут на себя часть инженерной работы.
На DotNext 2026 разберем как вещи, которые происходят на уровне машинного кода, так и вполне прикладные вопросы архитектуры и разработки.
📅 25–26 сентября, Москва + online
Выбрали 8 тем из программы, среди которых не только доклады, но и хардкорный воркшоп, чтобы показать этот диапазон:
— как заставить Transactional Outbox одновременно быть строгим и параллельным;
— зачем ASP.NET Core модульный монолит и как собрать его без микросервисов;
— где Native AOT выигрывает у JIT в .NET 10;
— что происходит с циклами, inlining и bounds checks в C# и Go;
— как меняется SDLC, когда в команде появляются ИИ-агенты;
— что принесут discriminated unions в C# 15;
— как проектировать асинхронное взаимодействие в распределенных системах (воркшоп).
Все подробности — в карточках и на сайте конференции.
🌟По промокоду
→ Программа DotNext
→ Купить билет
В .NET одновременно происходит много интересного: C# получает новые возможности, .NET 10 меняет расклад между Native AOT и JIT, а в разработке появляются ИИ-агенты, которые берут на себя часть инженерной работы.
На DotNext 2026 разберем как вещи, которые происходят на уровне машинного кода, так и вполне прикладные вопросы архитектуры и разработки.
📅 25–26 сентября, Москва + online
Выбрали 8 тем из программы, среди которых не только доклады, но и хардкорный воркшоп, чтобы показать этот диапазон:
— как заставить Transactional Outbox одновременно быть строгим и параллельным;
— зачем ASP.NET Core модульный монолит и как собрать его без микросервисов;
— где Native AOT выигрывает у JIT в .NET 10;
— что происходит с циклами, inlining и bounds checks в C# и Go;
— как меняется SDLC, когда в команде появляются ИИ-агенты;
— что принесут discriminated unions в C# 15;
— как проектировать асинхронное взаимодействие в распределенных системах (воркшоп).
Все подробности — в карточках и на сайте конференции.
🌟По промокоду
csharpinterview — персональные билеты дешевле→ Программа DotNext
→ Купить билет
🔥2
RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core
Отправить сообщение в RabbitMQ несложно. Гораздо сложнее сделать так, чтобы система продолжала работать корректно в production: сообщения не терялись, не обрабатывались повторно, а ошибки не приводили к бесконечным ретраям и дублированию данных.
На открытом уроке 17 сентября в 20:00 разберем типичные проблемы, с которыми сталкиваются разработчики при построении событийно-ориентированных систем, и последовательно рассмотрим проверенные подходы к их решению. Поговорим о паттерне Transactional Outbox, разберем, зачем нужна идемпотентность при обработке сообщений, и покажем, как Dead Letter Queue (DLQ) помогает безопасно работать с ошибками и некорректными сообщениями. Все примеры будут реализованы на ASP.NET Core с использованием RabbitMQ, однако рассмотренные подходы применимы и к другим брокерам сообщений.
Урок не для тех, кто хочет просто научиться отправлять первое сообщение в очередь. Будет полезен backend-разработчикам, строящим микросервисные архитектуры, и инженерам, которые хотят довести свои event-driven системы до промышленного уровня надежности.
После урока вы поймете, как гарантировать доставку сообщений, избежать дублирования данных при повторных обработках и организовать корректную обработку ошибок без остановки всего пайплайна.
👉 Записаться: https://clc.to/pp4zgQ
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Отправить сообщение в RabbitMQ несложно. Гораздо сложнее сделать так, чтобы система продолжала работать корректно в production: сообщения не терялись, не обрабатывались повторно, а ошибки не приводили к бесконечным ретраям и дублированию данных.
На открытом уроке 17 сентября в 20:00 разберем типичные проблемы, с которыми сталкиваются разработчики при построении событийно-ориентированных систем, и последовательно рассмотрим проверенные подходы к их решению. Поговорим о паттерне Transactional Outbox, разберем, зачем нужна идемпотентность при обработке сообщений, и покажем, как Dead Letter Queue (DLQ) помогает безопасно работать с ошибками и некорректными сообщениями. Все примеры будут реализованы на ASP.NET Core с использованием RabbitMQ, однако рассмотренные подходы применимы и к другим брокерам сообщений.
Урок не для тех, кто хочет просто научиться отправлять первое сообщение в очередь. Будет полезен backend-разработчикам, строящим микросервисные архитектуры, и инженерам, которые хотят довести свои event-driven системы до промышленного уровня надежности.
После урока вы поймете, как гарантировать доставку сообщений, избежать дублирования данных при повторных обработках и организовать корректную обработку ошибок без остановки всего пайплайна.
👉 Записаться: https://clc.to/pp4zgQ
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Разберём на вебинаре, как тратить меньше на AI-агентов — без потери качества кода.
— когда дорогая модель действительно нужна, а когда хватит дешёвой;
— сколько стоит один прогон и куда уходят токены;
— какие задачи можно отдавать субагентам;
— как настроить маршрутизацию моделей;
— что проверять в AI-коде перед merge.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Когда выбирать struct/record struct вместо class?
Для маленьких, неизменяемых и часто копируемых значений (≤ ~16–32 байт), где важна локальность и отсутствие аллокаций. Нужны структурное равенство/with — берите record struct. Если объект крупный/мутабельный/долго живёт — используйте class.
Библиотека собеса по С#
Библиотека собеса по С#