⚡ ASP.NET Core: Глобальный обработчик исключений

Красивый и лаконичный пример реализации IExceptionHandler в .NET 8+ через switch`-выражение и сервис `IProblemDetailsService.

internal sealed class GlobalExceptionHandler(
    IProblemDetailsService problemDetailsService,
    ILogger<GlobalExceptionHandler> logger) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(
        HttpContext httpContext,
        Exception exception,
        CancellationToken cancellationToken)
    {
        logger.LogError(exception, "Unhandled exception occurred");

        httpContext.Response.StatusCode = exception switch
        {
            ApplicationException => StatusCodes.Status400BadRequest,
            _ => StatusCodes.Status500InternalServerError
        };

        return await problemDetailsService.TryWriteAsync(new ProblemDetailsContext
        {
            HttpContext = httpContext,
            Exception = exception,
            ProblemDetails = new ProblemDetails
            {
                Type = exception.GetType().Name,
                Title = "An error occured",
                Detail = exception.Message
            }
        });
    }
}

📌 Что тут важно:

- switch по типу исключения для назначения статуса ответа
- IProblemDetailsService для единообразного формирования ответа
- Логгирование всех необработанных ошибок

🔥 Такой подход делает код чище, централизует обработку ошибок и избавляет от дублирования в middleware.

🚀 Docker + .NET pro tip

Для .NET приложений используйте многоступенчатую сборку: сначала компилируем и публикуем, потом копируем только готовые бинарники в минимальный рантайм-образ.

# Этап сборки
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Этап финального образа
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

💡 Преимущества:

- минимальный размер финального контейнера,
- быстрый запуск без SDK, только рантайм,
- меньше уязвимостей благодаря облегчённому окружению.

@csharp_ci

⚡ .NET 9 — самая быстрая платформа 2025 года

Microsoft прокачала .NET так, что он обгоняет почти все популярные фреймворки: Java, Go, Node.js, Python и даже PHP.

🚀 Что сделали:
- Мусорщик (GC) стал адаптивным → меньше пауз даже при высоких нагрузках.
- JIT-компилятор быстрее разогревает код и оптимизирует горячие участки.
- Векторизация через AVX10 и Arm SVE ускоряет циклы в несколько раз.
- Native AOT уменьшает размер бинарников и ускоряет запуск (контейнеры, IoT, edge).
- Сеть (сокеты, HTTP/3) стала работать быстрее с низкой задержкой.
- JSON обрабатывается через System.Text.Json максимально эффективно.
- Меньше аллокаций → меньше нагрузка на память и GC.
- Thread-pool и многопоточность лучше распределяют задачи по ядрам.
- Минимальные API и оптимизация исключений дали ещё +15% к скорости.

📊 Бенчмарки показывают:
- Java (Spring) — медленнее в 2.5 раза
- Go (Fiber) — в 1.3 раза
- Node.js (Fastify) — в 4 раза
- Python (FastAPI) — в 10 раз
- PHP (Laravel) — в 15 раз
- Ruby (Rails) — в 20 раз

💡 Итог: .NET 9 — быстрый старт, низкая задержка и топ-производительность. Отличный выбор для веба, микросервисов и облака.

#dotnet #performance #benchmark #backend

⚡ Как выбор структур данных влияет на скорость .NET приложений

Недавно я оптимизировал 12 крупных систем на ASP .NET Core и каждый раз сталкивался с одной и той же проблемой.
Разработчики тратят много времени на оптимизацию запросов, индексов и кэша, но забывают про базу — правильный выбор коллекций.

Ошибка в выборе структуры данных может замедлить приложение в 10 раз.
Вот простые примеры:

1. Поиск по ключу
- List<T>.Find() → O(n) — медленно на больших объёмах
- ✅ Dictionary<K,V> → O(1) — быстрый доступ

2. Вставка в начало списка
- List<T>.Insert(0, item) → O(n) — сдвигает все элементы
- ✅ LinkedList<T> → O(1) — мгновенная вставка

3. Уникальные элементы
- List<T> + Contains() → O(n) на каждую проверку
- ✅ HashSet<T> → O(1) — уникальность проверяется сразу

4. Упорядоченные данные
- List<T> + Sort() → O(n log n) и нужен свой поиск
- ✅ SortedDictionary<K,V> → встроенный порядок и быстрый поиск

5. Кэширование API-ответов
- Static Dictionary → риск утечек памяти и «зависших» данных
- ✅ MemoryCache → встроенная очистка и управление временем жизни

💡 Итог: чаще всего не нужны «хитрые оптимизации». Достаточно выбрать правильную коллекцию — и производительность вырастет кратно.

👉 Вопрос к вам: какая самая серьёзная проблема с производительностью у вас решилась заменой структуры данных?

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

🎮 Клад для геймдева — Kenney Assets

Бесплатная библиотека 2D и 3D-ассетов: спрайты, текстуры, звуки, шрифты и даже модели для VR/AR. Всё под лицензией CC0 — можно использовать где угодно, включая коммерческие проекты.

📌 Плюсы:
- Регулярные обновления и новые пакеты
- Идеально для прототипов, обучения и инди-игр
- Никаких ограничений по использованию

🔥 Забирай здесь: https://kenney.nl/assets

🚀 SQL Ultimate Course — бесплатный полный курс по SQL на GitHub

Если хочешь освоить SQL с нуля и дойти до продвинутого уровня — бери готовый репозиторий:

📂 Что внутри:
- datasets/ — реальные данные из ERP и CRM
- scripts/ — готовые SQL-скрипты для практики
- docs/ — документация и материалы курса

✅ MIT-лицензия — можно использовать и менять свободно
🌍 Подходит для всех СУБД (PostgreSQL, MySQL и др.)
🎥 К курсу прилагаются видео и гайды от автора

Автор: Data With Baraa — практик и ютубер, собравший в одном месте полный SQL-путь от простого SELECT до оптимизации запросов и реальных кейсов.

🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course

Сохраняй, проходи и прокачивай SQL 💡

🚀 Микросервисная платформа для страхования

Yosef — это открытая микросервисная платформа для финансовой страховой отрасли, разработанная на .NET, Python, TypeScript и Golang. Она обеспечивает масштабируемость, гибкость и высокую наблюдаемость для современных страховых приложений.

🚀 Основные моменты:
- Микросервисная архитектура для легкости масштабирования
- Централизованное управление идентификацией и доступом
- Полный цикл страхования от оценки до создания полиса
- Высокая наблюдаемость с использованием Grafana и Prometheus
- Интеграция с современными инструментами безопасности

📌 GitHub: https://github.com/elyosemite/Yosef

#csharp

❗️C# вопрос с собеседования: Middle–Senior level

Вопрос: почему возникает предупреждение о возможном null, если ProductStock здесь явно не равен null?

Код:

private static IEnumerable<Error> VerifyProductQuantities(
    List<ProductStock> products,
    Dictionary<string, Domain.Entities.ProductStock> stocks)
{
    foreach (var product in products)
    {
        if (!stocks.TryGetValue(product.ProductName, out var stock))
        {
            yield return StockErrors.ProductNotFound(product.ProductName);
        }

        if (stock.AvailableQuantity < product.Quantity)
        {
            yield return StockErrors.InsufficientStocks(
                product.ProductName, product.Quantity, stock.AvailableQuantity);
        }
    }
}

Компилятор выдет: «Dereference of a possibly null reference» для переменной stock.

Почему так происходит?
• Метод TryGetValue возвращает false, и тогда stock остаётся равным null.
• Даже если мы отфильтровали это через if (!TryGetValue(...)), компилятор не гарантирует, что в блоке после условия stock точно не null.
• В результате в строке if (stock.AvailableQuantity < product.Quantity) возникает предупреждение.

Как исправить?
1. Добавить continue после yield return внутри блока if (!TryGetValue(...)). Тогда компилятор поймёт, что кода после этой ветки для null не будет.
2. Либо использовать оператор !:
if (stock!.AvailableQuantity < product.Quantity) — но это безопасно только если мы уверены, что значение точно не null.
3. Более читаемый вариант — переписать логику так, чтобы работа с stock была строго в ветке, где оно гарантированно задано.

Вопрос для проверки понимания nullable reference types и поведения компилятора при анализе путей выполнения кода.