⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга

Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад.
Решение - авторегистрировать endpoints через DI.

Идея:
1) Делаешь общий интерфейс IEndpoint
2) Каждый endpoint реализует его
3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI
4) Достаёшь их из DI и вызываешь MapEndpoints()

Плюсы:
✅ чистый Program.cs
✅ каждый endpoint в отдельном файле
✅ масштабируется без хаоса
✅ легко тестировать и поддерживать

Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDescriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}

#ПятничныйКвиз #ДляСамыхМаленьких

📦 Всё ещё не используешь Central Package Management в .NET?

Открой свой .csproj прямо сейчас.

Пакеты обычно выглядят так:
<PackageReference Include="Serilog" Version="4.3.0" />
<PackageReference Include="WolverineFx" Version="5.6.0" />

И в итоге проект превращается в мусорку из версий.

А теперь представь, что это будет так:
<PackageReference Include="Serilog" />
<PackageReference Include="WolverineFx" />

Вот в этом и кайф Central Package Management.

Что он даёт:
✅ .csproj становится чистым и читаемым
✅ никто случайно не поставит “левую” версию пакета
✅ вся команда работает на одинаковых версиях библиотек
✅ сборка становится предсказуемой и детерминированной

Как работает:
Ты управляешь версиями централизованно через файл
Directory.Packages.props в корне репозитория.

То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version.

Если у тебя монорепа или несколько проектов - это must-have.

Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️

Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу.

Идея простая:
Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат.

Что происходит в примере:

— В DI регистрируется Resilience Pipeline
— Добавляется FallbackStrategy
— Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения

Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline:

pipeline.ExecuteAsync(...)

И если API:
❌ упало
❌ вернуло ошибку
❌ словило таймаут

Пользователь не увидит 500. Он получит контролируемый ответ.

Это особенно важно для:
- внешних API
- микросервисов
- нестабильных сетей
- интеграций с SaaS

Fallback — это не про «скрыть ошибку».
Это про graceful degradation, когда система продолжает жить даже при частичных сбоях.

Надёжность — это архитектура, а не try/catch в каждом методе.
#dotnet #backend #architecture

🏗️ Пытаться вытаскивать микросервисы из “спагетти-монолита” - почти всегда плохая идея.

Вместо красивой архитектуры ты получишь распределённую кашу, ещё больше зависимостей, ошибок и боли при поддержке.

Самый безопасный путь миграции - паттерн Strangler Fig:
выносить функциональность по кускам, постепенно “замещая” монолит.

Но есть важное условие:
сначала нужно привести систему к Modular Monolith.

То есть:
- чётко выделить границы модулей
- изолировать данные
- оставить только чистые публичные API для общения между модулями

И только после этого выбирать, какой модуль выносить первым.

Как выбрать правильного кандидата на первый микросервис?
Ищи 4 “зелёных флага”:

1) Low Coupling - минимум зависимостей от других модулей
2) High Cohesion - логика внутри модуля максимально связная и цельная
3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”)
4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе

Если модуль соответствует этим критериям - его можно вынести относительно безопасно,
не превращая архитектуру в распределённый хаос.

⚡️ 10 причин перейти на .NET 10 (чтобы это одобрил руководитель)

.NET 10 и C# 14 вышли 11 ноября 2025. Ниже - 10 причин, почему апгрейд реально стоит запланировать.

1) LTS-релиз
- .NET 10 - Long-Term Support, поддержка до 14 ноября 2028
- поддержка .NET 8 заканчивается 10 ноября 2026 → лучше не тянуть

2) Быстрее ASP.NET Core
- до +15% RPS по сравнению с .NET 8
- до -93% потребления памяти → меньше нагрузка и дешевле инфраструктура

3) Общий прирост производительности .NET
- сотни улучшений “из коробки” просто после апгрейда проекта

4) File-Based Apps (один .cs файл)
- можно сделать один файл *.cs и запускать напрямую
- удобно для CLI, автоматизации и утилит без создания проекта

5) Server-Sent Events (SSE)
- лёгкий способ стримить данные на клиента
- идеален для real-time обновлений без сложности WebSocket

6) Extension Members в C# 14
- более удобный синтаксис расширений
- можно расширять свойства и static members

7) Minimal APIs: Validation + JSON Patch
- встроенная валидация для Minimal APIs
- JSON Patch доступен из коробки

8) EF 10: LeftJoin / RightJoin в LINQ
- наконец-то нормальные LeftJoin/RightJoin
- запросы становятся проще и читаемее

9) EF 10: Named Query Filters
- можно заводить несколько фильтров на одну сущность
- включать/выключать их независимо

10) Улучшения Blazor
- Hot Reload для Blazor WASM и .NET on WASM
- профилирование производительности + диагностические счётчики

Источник/подробности:
antondevtips.com/draft/10-reasons-to-upgrade-to-dotnet-10/

Если вы не используете OpenTelemetry, вы буквально летите вслепую в продакшене.

И хорошая новость — вам не нужно переписывать код, чтобы получить “рентген-зрение” для своих сервисов.
Достаточно подключить правильные пакеты авто-инструментирования.

Вот базовый стартовый набор для .NET:

- AspNetCore — автоматически трейсит все входящие HTTP-запросы
- HttpClient — показывает тайминги и статусы всех исходящих API-вызовов
- EF Core — логирует реальные SQL-запросы и их длительность
- Npgsql — добавляет глубокий трейсинг для PostgreSQL
- StackExchange.Redis — помогает увидеть cache hits, misses и скачки латентности

После установки вы начинаете видеть полный жизненный цикл запроса через все микросервисы — от входящего HTTP до базы, кэша и внешних API.

Это уже не “логи и надежда”.
Это наблюдаемость продакшен-уровня.

Я разобрал, как всё это подключить к Grafana или Jaeger и получить полноценную визуализацию трейсов.

Полный гайд по настройке:
https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet?utm_source=X&utm_medium=social&utm_campaign=19.01.2026

🟥 Утечки данных в .NET-приложениях чаще происходят не из-за хакеров, а из-за неверной работы с ключами, конфигурациями и базовой криптографией. Ошибки на уровне кода быстро превращаются в инциденты.

На открытом уроке разберём практическое применение System.Security.Cryptography: AES, RSA, хеширование и цифровые подписи. Поговорим о безопасном хранении и передаче секретов, управлении ключами и принципе наименьших привилегий.

❗️ Вы системно разберёте уязвимости OWASP Top-10 для .NET: инъекции, небезопасную десериализацию, XSS, CSRF — и способы их нейтрализации на уровне кода и архитектуры. Отдельно обсудим шифрование данных в БД, защиту строк подключения и безопасное логирование без утечек токенов.

🟥Встречаемся 10 февраля в 20:00 МСК в преддверии старта курса «C# Developer. Professional».

Зарегистрируйтесь, чтобы не пропустить: https://tglink.io/73e7493a7d6ff1?erid=2W5zFGXFxba
#реклама
О рекламодателе

Если вы думаете, что EF Core «медленный» в 2026 — вы просто живёте в прошлом.

Одна из мощных современных фич — bulk-операции, в том числе массовое удаление.

Теперь можно удалить любое количество записей одним запросом к базе.

Пример: e-commerce платформа хочет удалить все корзины, созданные более года назад. Раньше это выглядело так: загрузили сущности в память, RemoveRange, SaveChanges — лишние аллокации, трафик и нагрузка.

Теперь достаточно:

context.Carts
    .Where(o => o.CreatedOn < DateTime.Now.AddYears(-1))
    .ExecuteDelete();

В результате выполняется один SQL DELETE, который напрямую удаляет старые записи в базе — быстро и без промежуточных объектов в памяти.

⚠️ Важно: bulk-операции обходят change tracker EF. Если в контексте уже есть отслеживаемые сущности, состояние может рассинхронизироваться — учитывайте это в логике.

EF Core давно уже не просто ORM, а полноценный инструмент для высоконагруженных систем. И у него есть ещё много фич, которые серьёзно упрощают жизнь разработчику.

Подробнее

👨‍💻 Ручная сборка, деплой по инструкции в Confluence и ночные правки на сервере — частая реальность ASP.NET-проектов. Пока система доставки не автоматизирована, скорость разработки и стабильность всегда под угрозой.

На открытом уроке разберём, как выстроить рабочий pipeline от коммита до деплоя. Покажем типовую цепочку: сборка, тесты, упаковка в Docker-образ, публикация в реестр и автоматическое развертывание.

❗️ Вы увидите CI/CD не как абстрактную DevOps-теорию, а как воспроизводимый процесс, который можно применить в собственном проекте. Это фундамент для перехода к микросервисам и контейнерной инфраструктуре без лишней сложности.

🗓 Встречаемся 11 февраля в 20:00 МСК в преддверии старта курса «C# ASP.NET Core-разработчик».

➡️ Регистрация открыта: https://tglink.io/3e020aa35caaf6?erid=2W5zFGkbWek

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
#реклама
О рекламодателе