C# 1001 notes

Архитектурные ошибки, которые совершают даже опытные C#-разработчики Можно соблюдать SOLID, использовать паттерны и современные архитектурные подходы — и всё равно со временем получить систему, которую сложно и дорого поддерживать. Почему так происходит? Где заканчивается хорошая архитектура и начинается оверинжиниринг? И какие решения, которые сегодня кажутся правильными, завтра становятся источником технического долга? 18 августа в 20:00 МСК на открытом вебинаре OTUS вместе с Антоном Герасименко разберём архитектурные ошибки, которые регулярно встречаются в реальных .NET-проектах. Вы узнаете, как отличать действительно полезные архитектурные решения от «архитектуры ради архитектуры» и проектировать системы, которые можно развивать без постоянных дорогостоящих переделок. Вебинар проходит в преддверии старта курса «C#-разработчик. Продвинутый уровень». Регистрируйтесь: https://otus.pw/fvrf/?erid=2W5zFHT5e3T Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡️ C#-приём: не привязывай метаданные к объектам через обычный `Dictionary` — иногда нужен `ConditionalWeakTable`. Допустим, библиотека кеширует данные о типах: private static readonly Dictionary<Type, Metadata> Cache = new(); В обычном приложении это может годами работать без проблем. Но если используются plugins, dynamic assemblies или unloadable AssemblyLoadContext, такой словарь способен удерживать Type, а вместе с ним — всю загруженную сборку. И получить memory leak. Для таких случаев в .NET есть малоизвестный: ConditionalWeakTable<TKey, TValue> Пример: private static readonly ConditionalWeakTable<Type, Metadata> Cache = new(); static Metadata GetMetadata(Type type) { return Cache.GetValue(type, BuildMetadata); } Ключ здесь хранится слабо. Если Type больше нигде не нужен, GC может его собрать, а связанная запись автоматически исчезнет из таблицы. Это особенно полезно для: * reflection-кешей; * proxy/framework-кода; * source/runtime metadata; * plugin-систем; * приложений с AssemblyLoadContext. 🔥 Если видишь: static Dictionary<Type, ...> или static ConcurrentDictionary<Type, ...> в коде, который работает с динамически загружаемыми сборками, стоит проверить: не удерживает ли этот кеш сборки в памяти навсегда? Иногда правильный ответ — ConditionalWeakTable. #CSharp #DotNet #Backend #Programming #CLR

🎓 Скоро заканчивается прием документов на онлайн-магистратуру ИТМО в партнерстве с Яндекс Практикумом «Фронтенд-, бэкенд‑разработка и ИИ‑решения» Это двухлетняя программа, где обучение проходит полностью онлайн с лекциями по вечерам. Нагрузка адаптируется под ваш уровень, сохраняются все статусы и льготы очной формы. После выпуска выдается диплом магистра ИТМО и диплом о профпереподготовке от Яндекса. Что внутри: • 9 треков на выбор по уровню и стеку: 4 базoвых (JS, Python, Java, C++) и 5 продвинутых — с упором на асинхронность, микросервисы, высокое нагружение, Kafka, C++/Boost, NestJS, Spring Boot. • Упор на практику на основе реальных задач партнеров программы и сервисов Яндекса, также есть возможность вести собственный рабочий проект. На выходе получите 10+ кейсов в портфолио. • Интеграция ИИ в разработку: автоматизация рутинных задач (генерация кода, написание тестов, дебаггинг, документация) и промпт-инжиниринг на всех треках. • Специализированный трек «ИИ-решения в разработке»: проектирование систем на базе LLM, сборка RAG-пайплайнов, работа с мультиагентными сетями и внедрение AI-компонентов в продакшен. Подать заявление можно также онлайн. Отбор проходит одним из способов: по рекомендательному письму для выпускников курсов Практикума или через вступительные экзамены. 📌 Подробности о программе.

🚀 C# 15 меняет подход к `unsafe`: указатели больше не означают автоматически опасный код Раньше в C# сам факт использования указателя требовал: unsafe { int* ptr; } Теперь язык движется к более точной модели: опасным считается не наличие указателя, а операция, которая реально работает с unmanaged-памятью. В preview-версии C# 15 уже не требуют unsafe: ✅ объявление pointer-типа ✅ получение адреса через & ✅ fixed для закрепления памяти ✅ преобразование stackalloc в указатель ✅ sizeof для unmanaged-типов Пример: int number = 42; int* pointer = &number; int[] numbers = [10, 20, 30]; fixed (int* first = numbers) { // само закрепление памяти безопасно } Но вот это всё ещё требует unsafe: *pointer; // dereference pointer->Value; // доступ через указатель pointer[0]; // работа с элементами delegate*<> // вызов function pointer Главная идея: **создать инструмент можно безопасно. Опасно — когда начинаешь напрямую менять память.** Это первый этап большой переработки модели безопасности C#. Дальше ожидаются: - requires-unsafe для отдельных членов; - opt-in на уровне assembly; - новый safe keyword. C# постепенно делает unsafe-код более точечным: меньше блоков вокруг всего файла, больше внимания к реально опасным операциям. #csharp #dotnet #programming

🔥 EF Core migrations - это компилятор схемы базы, а не кнопка «создать таблицу» Опытный C#-разработчик не оставляет бизнес-инварианты только внутри SaveChangesAsync(). Проверку в приложении можно обойти прямым SQL, импортом данных, фоновым процессом или второй версией сервиса. Поэтому правила, нарушение которых делает данные некорректными, стоит закреплять в самой базе. public sealed class ProductConfiguration : IEntityTypeConfiguration<Product> { public void Configure(EntityTypeBuilder<Product> builder) { builder.ToTable("Products", table => { table.HasCheckConstraint( "CK_Products_Price_Range", "[Price] > 0 AND [Price] <= 10000000"); }); builder.Property(x => x.Name) .HasMaxLength(200) .IsRequired(); builder.Property(x => x.NormalizedName) .HasMaxLength(200) .IsRequired(); builder.Property(x => x.Price) .HasPrecision(18, 2); builder.HasIndex(x => x.NormalizedName) .IsUnique() .HasDatabaseName("UX_Products_NormalizedName"); } } HasPrecision(18, 2) управляет физическим представлением decimal, но не проверяет допустимый диапазон цены. За это отвечает CHECK. Уникальный индекс решает другую важную проблему - гонку между запросами. if (!await db.Products.AnyAsync(x => x.Name == name)) { db.Products.Add(product); await db.SaveChangesAsync(); } Два параллельных запроса могут одновременно пройти AnyAsync() и попытаться создать одинаковые записи. Только уникальное ограничение базы гарантированно остановит второй запрос. Использовать для уникальности исходный Name тоже опасно. Результат будет зависеть от collation базы: Laptop, LAPTOP и Laptop могут считаться одинаковыми или разными. Поэтому часто сохраняют нормализованное значение: product.NormalizedName = product.Name .Trim() .ToUpperInvariant(); После изменения модели создаём миграцию: dotnet ef migrations add HardenProductSchema Но миграцию нельзя принимать вслепую. EF Core сравнивает текущую модель с ModelSnapshot и генерирует предполагаемый переход между двумя состояниями. Например, обычное переименование свойства может быть распознано как удаление старого столбца и создание нового: migrationBuilder.DropColumn( name: "Name", table: "Products"); migrationBuilder.AddColumn<string>( name: "DisplayName", table: "Products", nullable: false); В production это означает потерю данных. Правильную операцию нужно указать вручную: migrationBuilder.RenameColumn( name: "Name", table: "Products", newName: "DisplayName"); Для крупных таблиц полезен подход expand -> backfill -> contract. Сначала добавляется nullable-столбец: migrationBuilder.AddColumn<string>( name: "NormalizedName", table: "Products", type: "nvarchar(200)", nullable: true); Затем данные заполняются порциями отдельной задачей. После обновления всех строк новая версия приложения начинает записывать оба значения. И только в следующем релизе столбец переводится в NOT NULL, добавляется индекс и удаляется устаревшая логика. Так миграция не держит долгую блокировку и остаётся совместимой сразу с несколькими версиями приложения. В CI стоит проверять, не забыл ли разработчик создать миграцию: dotnet ef migrations has-pending-model-changes Для production лучше генерировать проверяемый SQL: dotnet ef migrations script \ --idempotent \ --output migrations.sql Либо собирать отдельный executable: dotnet ef migrations bundle \ --self-contained \ -r linux-x64 efbundle можно запускать в deployment job без исходников проекта и установленного EF CLI.

🚀 Claude Opus 5 за 24 часа собрал собственный космический симулятор Разработчик запустил модель на одну непрерывную сессию и получил The Long Silence - полноценную браузерную игру об исследовании космоса. По словам автора, весь код, визуал и звук создал Claude. Внутри: • процедурные звёзды, планеты, кольца и туманности • посадка на поверхность планет • перелёты между системами и fold drive • сканирование объектов, станции и заброшенные корабли • карта галактики, сюжет и архив найденных данных • динамическое масштабирование графики для стабильных 60 FPS Игра работает на WebGL2 без готовых ассетов: миры генерируются из seed, графика написана на GLSL, а музыка и звук создаются процедурно. Это ещё не Starfield по масштабу, но для проекта, собранного моделью за сутки, результат выглядит безумно. 🎮 Код и запуск: https://github.com/achimala/TheLongSilence 🌐 Запустить в браузере: https://longsilence.anshu.dev/

.NET 11 готовят под эпоху AI Microsoft собрала ключевые .NET-сессии с Build 2026. Фокус - AI, агенты и развитие C#. Что показали: - union types в C#; - улучшения runtime, SDK и производительности в .NET 11; - инструменты для добавления AI в C#-приложения; - agentic web в ASP.NET Core и Blazor; - локальные AI-модели и on-device inference через .NET MAUI; - новый dotnetup для установки и обновления SDK/runtime. Важно: .NET 11 пока находится в preview, а часть возможностей ещё развивается. https://devblogs.microsoft.com/dotnet/dotnet-at-microsoft-build-2026/

Каждый год в середине лета мы с друзьями собираемся на E-CODE. Ещё относительно молодая конфа Ozon Tech стала уже своего рода легендой. Не удивительно: хардовость официальной части здесь не уступает громкости афтерпати. На E-CODE 2026 нас по части бэкэнда ждут: • Runtime Async с его + и – • трассировка с eBPF • ускорение на SIMD • построение кастомной real-time системы видеоаналитики • сравнительный анализ алгоритмов сборки мусора Фишка этого года — брейнринг разработчиков и ИИ. Эксперты разберут сложные кейсы и сравнят свои подходы с тем, что предложит машина. Победителя выберет зал. Регистрируйтесь сейчас, чтобы услышать это всё вживую: https://ecode.ozon.tech/ 12 и 13 сентября, Москва. До встречи на E-CODE!

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку В IT прокачивается тот, кто каждый день видит сильные идеи, новые инструменты, реальные задачи, вакансии и разборы. Окружение решает больше, чем кажется. Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре. AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Хакинг: t.me/linuxkalii DevOps: t.me/DevOPSitsec Docker: t.me/DevopsDocker Golang: t.me/Golang_google Rust: t.me/rust_code C++: t.me/cpluspluc C#: t.me/csharp_1001_notes Java: t.me/java_library JavaScript: t.me/javascriptv React: t.me/react_tg Frontend: t.me/front PHP: t.me/phpshka Android: t.me/android_its Мобильная разработка: t.me/mobdevelop Базы данных: t.me/sqlhub Data Science: t.me/data_analysis_ml Big Data: t.me/bigdatai Математика: t.me/data_math Физика: t.me/fizmat Kubernetes: t.me/kubernetc GameDev: https://t.me/gamedev Haskell: t.me/haskell_tg Собеседования и карьера: DS собеседования: t.me/machinelearning_interview Python собеседования: t.me/python_job_interview Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка Frontend: https://t.me/addlist/mzMMG3RPZhY2M2Iy Полезное сверху: ИТ-мемы: t.me/memes_prog Английский для программистов: t.me/english_forprogrammers ИИ и технологии: t.me/vistehno 954 ГБ open-source курсов: @courses ИТ-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Max Ai: https://max.ru/ai_machinelearning_big_data Max python: https://max.ru/pythonl ТЕХНО: https://max.ru/vistehno Max Go: https://max.ru/Golang_google Max Linux: https://max.ru/linuxkalii Devops: https://max.ru/DevOPSitsec C#: https://max.ru/csharp_ci C++: https://max.ru/cpluspluc SQL: https://max.ru/sqlhub Java: https://max.ru/javatg Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд. Пока кто-то листает шум, ты будешь видеть инструменты, задачи и идеи, которые помогают расти в профессии.

Полезный Docker-трюк для .NET: кэшируйте NuGet-пакеты через BuildKit, а не скачивайте их заново при каждой сборке. # syntax=docker/dockerfile:1.7 FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build WORKDIR /src COPY *.csproj . RUN --mount=type=cache,target=/root/.nuget/packages \ dotnet restore COPY . . RUN --mount=type=cache,target=/root/.nuget/packages \ dotnet publish -c Release -o /app NuGet-кэш не попадает в финальный image, но между сборками сохраняется. В итоге restore работает быстрее, особенно в CI, где зависимости обычно весят больше, чем сам код.

⚡️ GPT-5.6 РЕЛИЗ OpenAI выкатили сразу три новые модели. • Sol - заявлено, что модель мощнее Mythos. Доступ для платных пользователей обещают в течение 24 часов. На Terminal Bench 2.1 с настройкой Ultra модель выбивает рекордные 91,9%. Первые тестеры отдельно отмечают сильную работу с интерфейсами: она уверенно собирает UI для приложений и сайтов, а не просто генерирует сырой код. • Terra - уровень Fable 5. Будет доступна бесплатно. • Luna - еще одна бесплатная модель для всех. Помимо самой модели, показали 3 крупных продуктовых обновления: 1. ChatGPT Work 2. новое desktop-приложение ChatGPT 3. hosted sites, то есть размещение сайтов прямо через Chatgpt https://openai.com/ru-RU/live/

AI-инструменты стали стандартной частью стека C#/.NET-разработчиков: ассистенты в IDE, генерация кода и тестов, помощь с документацией и ревью. По данным отраслевых отчётов, 80–90% инженеров уже используют AI-сервисы, а 97% компаний встроили AI в SDLC. Однако разрыв сегодня проходит не по доступу к моделям. У одних команд AI встроен в мультиагентные пайплайны, SDD подход и метрики качества. У других остаётся локальным помощником без влияния на метрики, скорость релизов и риск-профиль. Именно для интеграции AI в процессы команда Naition запускает 12‑недельную программу по AI-driven разработке. Программу собрали инженеры и техлиды из Яндекс Cloud, Сбера, Google и других продуктовых команд с опытом более 15 лет. Что внутри: • создание AI-окружения под ваш стек • контекст-инжиниринг - от создания и подключения кастомных MCP до RAG под вашу кодовую базу • решение продуктовых задач, spec-driven разработка и контроль качества с evals • разработка агентов, сабагентов с выходом в практики оркестрации • практики работы с легаси-проектами и крупными кодовыми базами при ограниченном бюджете Форматы участия: Командный - для C#/.NET-команд от 3–5 человек. Заходите в общий поток и получаете отдельный трек: разбор текущих процессов, выделение узких мест, план внедрения AI-практик и фиксация метрик до и после изменений. Индивидуальный формат - для архитекторов, техлидов, middle/senior‑разработчиков и руководителей, которые хотят собрать язык и паттерны AI‑ориентированной разработки, чтобы затем использовать их как основу изменений внутри своих команд. 95% участников прошлого потока дошли до конца. Первые изменения в процессах команды вносили уже после второго модуля. Новый поток AI‑DRIVEN стартует 21 июля. Если вы отвечаете за архитектуру и метрики разработки в C#/.NET‑проектах, вы можете оставить заявку на сайте и до 13 июля получить индивидуальные условия участия для команды или для себя как индивидуального участника. Подробности на сайте: naition.ai Реклама: ИП Крутов Дмитрий Валерьевич ИНН: 772973192199 Erid: 2VtzqxRqZmC

Record-типы в C#: когда модель данных не должна быть обычным class record в C# удобен там, где объект описывает данные, а не поведение и идентичность. Типичный пример: public record User(string Name, int Age); Компилятор сам сгенерирует конструктор, Equals, GetHashCode, ToString и деконструкцию. Но главное отличие не в сокращении кода, а в семантике. Обычный class сравнивается по ссылке: var a = new UserClass("Alice", 25); var b = new UserClass("Alice", 25); Console.WriteLine(a == b); // false record сравнивается по значению: var a = new User("Alice", 25); var b = new User("Alice", 25); Console.WriteLine(a == b); // true Это делает record хорошим выбором для DTO, read models, value objects, событий, результатов запросов и моделей, где важны значения полей. Ещё одна удобная вещь - with. Можно создать копию объекта, изменив только нужные поля: var user = new User("Alice", 25); var updated = user with { Age = 26 }; Console.WriteLine(updated); // User { Name = Alice, Age = 26 } Но есть важный нюанс: with делает поверхностную копию. Если внутри есть изменяемая коллекция, она не станет автоматически immutable. public record Team(string Name, List<string> Members); Такой record всё ещё может меняться через Members.Add(...). Поэтому для реально неизменяемых моделей лучше использовать immutable-коллекции или аккуратно закрывать доступ к изменяемому состоянию. record не заменяет class везде. Если у объекта есть жизненный цикл, identity, состояние и бизнес-поведение, обычный класс часто будет честнее. Но когда тип нужен как чистая модель данных, record убирает шум и делает намерение в коде очевидным.

Методы, их перегрузка и расширения. Бесплатный урок специализации «C#-разработчик» Методы — одна из базовых вещей в C#, без которой невозможно нормально писать, читать и поддерживать код. Но у начинающих разработчиков часто всё смешивается: где обычный метод, где перегрузка, как работает сигнатура, зачем нужны параметры по умолчанию и в каких случаях использовать params. На открытом уроке 2 июля в 20:00 разберём, что такое метод в C#, как писать собственные методы и как использовать перегрузку без хаоса в коде. Поговорим о сигнатуре метода, параметрах по умолчанию, ключевом слове params и методах-расширениях. На примерах покажем, как эти механики помогают делать код понятнее, гибче и удобнее для повторного использования. Урок не для тех, кто хочет просто «выучить синтаксис» без понимания, как методы влияют на структуру программы. 👉 Записаться: https://otus.pw/wkKs/?erid=2W5zFG7dRZ3 Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Продвинутый C#-трюк: обновляй `Dictionary` без двойного поиска Многие пишут так: if (dict.TryGetValue(key, out var value)) { dict[key] = value + 1; } else { dict[key] = 1; } Проблема: ты сначала ищешь ключ через TryGetValue, а потом снова лезешь в словарь через dict[key]. В hot path это лишняя работа. Есть более взрослый вариант: using System.Runtime.InteropServices; ref var count = ref CollectionsMarshal.GetValueRefOrAddDefault( dict, key, out var exists ); if (!exists) { count = 0; } count++; Что происходит: 1. C# получает ссылку прямо на значение внутри Dictionary 2. ключ ищется один раз 3. значение можно менять без повторного обращения 4. меньше лишних операций в tight loop Где это полезно: 1. счётчики событий 2. парсеры 3. агрегации 4. обработка логов 5. high-performance backend code Но есть важный нюанс: не меняй структуру словаря, пока держишь ref. То есть не делай Add, Remove, Clear рядом с этой ссылкой. Это не трюк для каждого CRUD-сервиса. Это инструмент для мест, где C# уже упёрся в производительность, и ты начинаешь выжимать лишние аллокации и лишние lookup’и.

Что выведет код? using System; using System.Collections.Generic; using System.Linq; static IEnumerable<int> GetNumbers() { Console.Write("A"); yield return 1; Console.Write("B"); yield return 2; } var query = GetNumbers().Where(x => x > 0); Console.Write(query.First()); Console.Write(query.Count()); А — A12 Б — A1B2 В — A1AB2 Г — Error Правильный ответ: В — A1AB2. Почему: IEnumerable и LINQ выполняются лениво. First() запускает перебор один раз и доходит только до первого элемента: печатает A, потом 1. Count() запускает перебор заново: снова A, потом B, и в конце печатает 2.

Аллокации, которых нет в коде: охота на скрытый боксинг в .NET 10 Самая дорогая аллокация в вашем сервисе та, которой нет в исходниках. Вы написали struct ради zero-allocation, прошли code review, а в проде Gen0-коллекции все равно идут косяком. Потому что между вашим кодом и машинным кодом стоит компилятор, и он молча упаковывает ваш value-тип в кучу там, где вы этого не просили — а на код-ревью этого не видно. TL;DR. Боксинг (boxing) в .NET - это не только object o = 42. Он прячется в вызовах интерфейсных методов на struct, в дефолтном ValueType.Equals, в params object[]-аргументах, в foreach по интерфейсу и в замыканиях. При этом часть “классических” примеров боксинга из старых гайдов на современном рантайме уже не аллоцирует — JIT научился их вырезать, и слепо копировать советы десятилетней давности вредно. Ниже — карта мест, где боксинг живёт и сейчас, отдельный разбор того, что рантайм уже оптимизировал, реальный мини-кейс, воспроизводимый бенчмарк на BenchmarkDotNet с MemoryDiagnoser, способ ловить упаковку через DOTNET_JitDisasm и dotnet-gcdump, и паттерны лечения без потери читаемости. О версиях и числах. Всё прверялось на .NET 10 (текущий LTS) и C# 13/14-уровне компилятора, Release, без отладчика, BenchmarkDotNet с MemoryDiagnoser. На .NET 8/9 поведение в основном такое же, но отдельные оптимизации JIT отличаются между мажорными версиями — поэтому главный принцип статьи: не верьте на слово (в том числе мне), гоняйте MemoryDiagnoser на своей версии рантайма. Числа в таблицах ниже - иллюстративные, порядок величины, а не точные замеры с вашего железа. Пролог: “у нас же всё на struct, откуда Gen0?” Сервис на горячем пути считает метрики: миллионы маленьких readonly struct-значений в секунду, никакого new, никаких классов в hot path. По задумке — ноль аллокаций. На дашборде — стабильный поток Gen0-коллекций раз в несколько секунд под нагрузкой. Профайлер показывает аллокации, но стек ведёт в метод, где в коде нет ни одного new. Там цикл по интерфейсу, пара вызовов .Equals(), передача значения в params-метод лога. Глазами — чисто. В машинном коде — box-инструкции на каждой итерации. Это и есть скрытый боксинг: компилятор C# и JIT упаковывают ваш struct в объект на куче, потому что в конкретной точке кода value-тип нужно представить как ссылочный. Симптом — Gen0-коллекции “из ниоткуда”, и его не видно ни в code review, ни в дампе, пока не посмотришь на IL или дизасм. Если тема близка - я регулярно разбираю такие штуки по C# и .NET (внутренности рантайма, перформанс, неочевидные грабли с замерами и дизасмом) в своём Telegram-канале: t.me/csharp_ci. Заходите, если интересно копаться глубже. Что такое боксинг и почему он стоит дорого Боксинг — это упаковка value-типа (struct, enum, примитив) в объект на управляемой куче. Рантайму нужно выделить заголовок объекта, скопировать туда значение и вернуть ссылку. Анбоксинг - обратная операция с проверкой типа. Цена не в самой инструкции, а в последствиях: каждая упаковка - это аллокация в Gen0. Много мелких аллокаций на горячем пути означают частые Gen0-коллекции, паузы (пусть и короткие), вытеснение полезных данных из кэша и общий рост CPU на ровном месте. На сервисе с SLA по p99 это бьёт по хвосту латентности так же, как и любая другая лишняя аллокация. В IL боксинг виден явно - инструкция box. Именно её мы и будем искать. Читать дальше: https://habr.com/ru/articles/1049236/

Задача по .NET: зачем нужен IHttpClientFactory? Есть сервис, который ходит во внешний API: public sealed class PaymentApiClient { private readonly HttpClient _http; public PaymentApiClient(HttpClient http) { _http = http; } public async Task<string> GetStatusAsync(string id, CancellationToken ct) { using var response = await _http.GetAsync($"/payments/{id}", ct); response.EnsureSuccessStatusCode(); return await response.Content.ReadAsStringAsync(ct); } } Регистрация: builder.Services.AddHttpClient<PaymentApiClient>(client => { client.BaseAddress = new Uri("https://payments.example.com"); client.Timeout = TimeSpan.FromSeconds(10); }) .ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler { PooledConnectionLifetime = TimeSpan.FromMinutes(5), MaxConnectionsPerServer = 50 }); Вопрос: почему это лучше, чем создавать new HttpClient() на каждый запрос? Потому что IHttpClientFactory переиспользует HttpMessageHandler и соединения под капотом. Это снижает риск socket exhaustion, даёт централизованную настройку таймаутов, ретраев, логирования и авторизации. А PooledConnectionLifetime нужен, чтобы соединения не жили вечно и приложение могло корректно подхватывать изменения DNS.

⚡️Про Каналы в .NET Если в приложении нужно обрабатывать поток данных от продюсеров к потребителям, первым делом вспоминают про очереди или ConcurrentQueue. Но в асинхронном мире этого мало. Поэтому в .NET есть каналы. Канал устроен как пара из продюсера и потребителя. Когда продюсер пишет элемент в канал, он либо сразу уходит к потребителю, либо ждёт, если очередь переполнена. Потребитель, в свою очередь, может ждать новые элементы без блокировки потоков — всё работает на async/await. Главная сила каналов — балансировка нагрузки. Ограниченные каналы позволяют держать под контролем количество элементов. Это защищает приложение от перегрузки: если продюсер работает быстрее, чем потребитель, система сама притормозит поток данных. Неограниченные каналы — вариант попроще, они всегда принимают новые элементы, но это может обернуться непредсказуемым ростом памяти. Мини-пример: var channel = Channel.CreateBounded<int>(5); // producer _ = Task.Run(async () => { for (int i = 0; i < 10; i++) { await channel.Writer.WriteAsync(i); Console.WriteLine($"Produced {i}"); } channel.Writer.Complete(); }); // consumer await foreach (var item in channel.Reader.ReadAllAsync()) { Console.WriteLine($"Consumed {item}"); } Почему это лучше, чем ConcurrentQueue? Потому что Channel создан сразу с учётом асинхронности. Вам не нужно городить блокировки и таймеры ожидания — достаточно написать await reader.ReadAsync(), и код будет сам по себе масштабироваться без блокировки потоков. #sharp_view