C# Portal | Программирование

Микросервисы сильно изменили то, как мы создаём и масштабируем приложения. Но микросервисные системы очень динамичны. Сервисы могут появляться и исчезать, масштабироваться вверх и вниз и даже перемещаться внутри инфраструктуры. И здесь возникает проблема. Как сервисам находить друг друга и надёжно взаимодействовать? Жёстко прописывать IP-адреса и порты — плохая идея. Если экземпляр сервиса сменит адрес или появится новый, система может просто перестать работать. Для этого и нужен Service Discovery. Он работает как центральный каталог микросервисов. Сервисы регистрируют в нём своё местоположение, а другие сервисы могут через него находить нужные экземпляры и подключаться к ним. 👉 @KodBlog

Летняя уборка в базе данных. Теперь пора посмотреть на сами запросы. pg_stat_statements отслеживает форму запросов, количество вызовов и время выполнения по всей базе. Это самый короткий путь от «база почему-то тормозит» до «вот эти пять запросов съедают большую часть времени». Включаем pg_stat_statements Если вы используете Crunchy Bridge, расширение уже доступно по умолчанию и можно сразу переходить к CREATE EXTENSION. При самостоятельном размещении нужно изменить postgresql.conf и перезапустить PostgreSQL shared_preload_libraries = 'pg_stat_statements, ...' pg_stat_statements.track = top Можно указать top или all. Режим all также учитывает запросы внутри функций и процедур. top используется по умолчанию и отслеживает только запросы, выполняемые клиентами. Затем включаем расширение для нужной базы CREATE EXTENSION IF NOT EXISTS pg_stat_statements; Ищем дорогие запросы Для такой проверки обычно полезнее смотреть на суммарное время выполнения. Запрос средней тяжести, который вызывается миллионы раз, часто наносит больше вреда, чем один редкий медленный запрос. SELECT round(total_exec_time::numeric, 1) AS total_ms, calls, round(mean_exec_time::numeric, 2) AS mean_ms, rows, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; Также стоит смотреть на среднее время и количество строк. Например, последовательное сканирование может проявиться как большое total_exec_time и большое значение rows у запроса, который в норме должен находить одну конкретную запись. Что означают столбцы • calls — сколько раз запрос выполнялся с момента последнего сброса статистики • total_exec_time и mean_exec_time — суммарное и среднее время выполнения в миллисекундах • rows — общее количество полученных или изменённых строк • query — нормализованный запрос с параметрами вида $1 Статистика копится до ручного сброса SELECT pg_stat_statements_reset(); Важно помнить, что сброс удаляет всю накопленную историю. Для анализа можно либо сбросить статистику перед заранее известным периодом высокой нагрузки, либо сравнивать текущие данные с сохранённым ранее снимком. Что делать с найденными запросами 1. Запустить EXPLAIN с реальными параметрами. pg_stat_statements показывает форму запроса, но не план выполнения. 2. Проверить недостающие индексы, сбросы на диск из-за work_mem и слишком большое количество мелких запросов приложения вроде N+1. 3. После деплоя или добавления индекса сбросить статистику, дать системе поработать под реальной нагрузкой и проверить, уменьшилось ли суммарное время выполнения. 👉 @KodBlog

Автор статьи разбирает лучшие практики безопасности REST API в ASP.NET Core. За годы работы он выпустил и проверил множество .NET API и собрал 18 практик, которые, по его опыту, постоянно помогают держать такие системы безопасными. В статье есть примеры кода и разбор HTTPS, JWT, политик авторизации, принципа минимальных привилегий, валидации входных данных, защиты от over-posting, ограничения размера запросов, параметризованных запросов и EF Core, rate limiting, CORS, CSRF, хранения секретов, логирования и других базовых мер. Антон также предлагает сохранить статью как dotnet-security-review-skill для ИИ-агентов и прогнать по ней существующую кодовую базу. По его словам, количество найденных проблем может удивить. 👉 @KodBlog

Насколько быстрый асинхронный Runtime в .NET 11? | Medium 👉 @KodBlog

Хотите использовать Minimal APIs вместе с архитектурой Vertical Slice? Вот довольно простая абстракция: - интерфейс IEndpoint для описания конечных точек; - несколько методов расширения для их автоматической регистрации; - целую функциональность можно оформить как отдельный Minimal API endpoint. Дополнительные затраты при запуске приложения — всего несколько миллисекунд. Практически незаметно. 👉 @KodBlog

Вышла .NET 11 Preview 7! https://devblogs.microsoft.com/dotnet/dotnet-11-preview-7/ 👉 @KodBlog

Не отправляйте несколько SQL-команд в базу данных последовательно. Есть более производительный способ. Когда нужно добавить новую запись, а затем сразу её прочитать, обычно выполняют два SQL-запроса: INSERT и SELECT. С точки зрения выполнения всё нормально, но есть дополнительные расходы: задержка сети и лишние обращения к базе данных. На производительности это вполне может сказаться. С Npgsql этого можно избежать. В нём есть пакетное выполнение запросов. Суть в том, что несколько SQL-команд отправляются в базу данных за одно обращение вместо отдельного вызова Execute для каждой команды. В Npgsql для этого используется NpgsqlBatch: несколько NpgsqlBatchCommand объединяются и отправляются серверу одним запросом. Важная деталь. Если вы сами не начали транзакцию, пакет автоматически выполняется внутри неявной транзакции. Если одна из команд завершается с ошибкой, оставшиеся команды не выполняются, а весь пакет откатывается. 👉 @KodBlog

FluentValidation: пример проверки совпадения паролей. https://github.com/karenpayneoregon/vs2026-how-to/tree/master/MatchPasswordsApp 👉 @KodBlog

C# 12 убрал приличный кусок шаблонного кода, который вы пишете почти в каждом сервисном классе. Если вы до сих пор для каждой зависимости объявляете поле, параметр конструктора и потом отдельно присваиваете одно другому, то пишете три строки там, где теперь нужна одна. Возьмём обычный OrderService. Три readonly-поля. Конструктор с тремя параметрами. Ещё три строки внутри конструктора, где каждый параметр присваивается своему полю. Получается 13 строк, и почти все они нужны только для прокидывания зависимостей. С первичным конструктором та же версия занимает около шести строк. Вы просто указываете зависимости прямо в объявлении класса: OrderService получает IOrderRepo repo, ILogger и IEmailSender email. После этого repo, logger и email можно напрямую использовать в методах. Поведение то же, шаблонного кода почти нет. Перед тем как переписывать всё подряд, стоит помнить три вещи. Больше не нужно повторять каждую зависимость по три раза. Объявляете её один раз — в заголовке класса. Параметры первичного конструктора доступны во всём классе, а не только внутри конструктора, поэтому к ним можно обращаться из любых методов. Тестируемость при этом никуда не исчезает. Моки внедряются точно так же, как раньше. Есть один нюанс, который может сэкономить вам час: параметры первичного конструктора не становятся полями автоматически. Если вам действительно нужно сохранить параметр именно как поле, сделайте это явно. Не додумывайте за компилятор — он сам подскажет. Попробуйте сегодня открыть один сервисный класс и перевести его на первичный конструктор. Посчитайте строки до и после. Разница — это тот шаблонный код, который вам больше не придётся писать. 👉 @KodBlog

Предпочитайте внедрение зависимостей вместо создания зависимостей вручную. — Через DI можно управлять временем жизни сервисов. — Проще реализовывать более продвинутые возможности вроде декораторов. — Код становится легче покрывать юнит-тестами, подставляя мок-реализации. Ещё 5 советов по рефакторингу C#: https://milanjovanovic.tech/blog/5-awesome-csharp-refactoring-tips 👉 @KodBlog

Если достаточно долго работать с базами данных, рано или поздно столкнёшься с проблемами подключений или параллелизма. В такой ситуации не стоит просто повышать лимиты в конфигурации. Лучше разобраться в архитектуре, чтобы понимать, почему это происходит и как исправить проблему оптимальным способом. Эта статья от гениального человека — отличный разбор управления подключениями в Postgres и возможных решений. Легко свести всё к особенностям Postgres с отдельным процессом на каждое соединение, но похожие проблемы могут возникать и в других базах данных, включая MySQL. Часто ответ кроется в пуле подключений, но и он добавляет свою сложность, которую тоже важно понимать. Статье уже 8 лет, но для Postgres она остаётся актуальной и в 2026 году. Ссылка ниже. https://brandur.org/postgres-connections 👉 @KodBlog

Пробовали IExceptionHandler в .NET 10? Это более простой способ глобально обрабатывать исключения. IExceptionHandler встроен в стандартный middleware обработки ошибок. Можно обрабатывать либо все исключения, либо только конкретные типы. А значит, обработчики можно выстраивать в цепочку. 👉 @KodBlog

C# 15 позволяет объявить тип, который может быть только одним из заранее заданного набора других типов. Union types. Новое ключевое слово, одна строка, базовый класс не нужен. public record class Cat(string Name); public record class Dog(string Name); public record class Bird(string Name); public union Pet(Cat, Dog, Bird); Теперь Pet может содержать Cat, Dog или Bird — и ничего больше. Pet pet = new Dog("Rex"); string name = pet switch { Dog d => d.Name, Cat c => c.Name, Bird b => b.Name, }; ✔️ Неявное преобразование каждого из допустимых типов напрямую в union ✔️ Компилятор заставляет switch обработать все варианты — пропустите один, и проект не соберётся ✔️ Не нужна иерархия наследования, класс-обёртка или ручные проверки в духе «это Cat или Dog» Пока это предварительная функция в .NET 11, поэтому синтаксис ещё может измениться до релиза. Но попробовать уже сейчас вполне можно, если хотите заранее разобраться с новой возможностью. 👉 @KodBlog

О правилах Clean Architecture спорят много. Но по-настоящему важно только одно. Зависимости направлены внутрь. Посмотрите на схему. Web.Api находится снаружи. Затем Infrastructure. Затем Application. В центре — Domain, и он ничего не знает ни об одном из этих слоёв. В вашем Domain нет зависимостей от базы данных, веб-фреймворка или сервиса отправки почты. Там только бизнес-правила на обычном C#. Что это даёт: * Можно заменить Postgres на что-то другое, не меняя Domain. Хотя лучше не надо. * Можно тестировать бизнес-правила вообще без базы данных — быстрыми юнит-тестами, которые могут написать ваши агенты. * Новый разработчик может разобраться в ядре приложения, не изучая весь стек. Понять это правило легко. Намного сложнее не нарушить его спустя шесть месяцев дедлайнов. Поэтому в моём шаблоне есть архитектурные тесты, которые валят сборку в тот момент, когда внутренний слой нарушает это правило. 👉 @KodBlog

Новое в .NET 11: Сжатие HTTP-запросов с помощью GZip, Brotli и Zstandard. 👉 @KodBlog

Как контролировать соблюдение архитектурных правил в проекте? Возможности компилятора C# здесь довольно ограничены, а проверять всё вручную на код-ревью дорого. Есть промежуточный вариант, который я использую в своих проектах — архитектурные тесты. Это автоматические тесты, которые проверяют структуру и устройство кода. С их помощью можно задавать архитектурные правила прямо на C#: * контролировать направление зависимостей между проектами; * задавать правила именования классов; * требовать, чтобы классы были sealed. 👉 @KodBlog

Знали ли вы, что обмен сообщениями можно использовать по схеме request–response? Один сервис — отправитель запроса — посылает сообщение с запросом и ожидает соответствующее ответное сообщение. Со стороны отправителя это выглядит как синхронное взаимодействие. Вот как выглядит такой поток. Плюсы: Слабая связанность ✅ Прозрачность расположения сервисов ✅ Минусы: Высокая задержка ❌ Дополнительная сложность реализации ❌ Я реализовывал такой подход с RabbitMQ и NATS — в обоих случаях он отлично себя показал. 👉 @KodBlog

Что такое breaking change для API? Вот несколько примеров: > Удаление или переименование API-методов или параметров API. > Изменение поведения существующих API. > Изменение кодов ошибок API. Breaking change означает, что вам нужно версионировать API — иначе вы рискуете сломать существующих потребителей API. К счастью, ASP.NET Core упрощает добавление версионирования API. И ещё немного спорное мнение: версионирование API должно быть крайней мерой. 👉 @KodBlog

Интересный эксперимент: windows-csharp https://github.com/microsoft/windows-rs/pull/4777 Генератор C#, который строит проекции Windows API из метаданных Windows, но вместо обёрток CsWinRT генерирует прямые вызовы COM/ABI. Без WinRT.Runtime.dll и без SDK projections. Это пока не полноценная замена (?), но уже работает с реальными приложениями на базе Composition/WinUI. 🤔 👉 @KodBlog