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

В .NET долгое время одним из самых удобных инструментов для организации CQRS и разделения логики был MediatR, он помогал структурировать команды и запросы, разгружал API слой и снижал связанность кода. Многие проекты, особенно с архитектурой Vertical Slice, держались на нём годами. Но в работе со сложными сценариями у MediatR есть нюанс. Из-за отвязки команд и обработчиков навигация по коду и отладка становятся менее очевидными, особенно когда один обработчик начинает вызывать другой. Альтернатива, которая решает эти проблемы, — переход на простые ручные обработчики. Такой подход убирает лишнюю рефлексию и декораторы, упрощает трассировку, а IDE быстрее находит нужный участок кода. Вот гайд как выстроить систему, где: > Стартовая реализация использует MediatR, а затем заменяется на ручные обработчики > Регистрация обработчиков происходит автоматически > Уведомления обрабатываются без MediatR Notifications > Общая функциональность (логирование, валидация, транзакции) подключается без лишней обвязки В результате получается решение с теми же преимуществами в архитектуре, но с более прямым и прозрачным кодом, что особенно полезно для крупных и долгоживущих проектов. 👉 @KodBlog

Для тех, кто пишет на Go и C#: Ozon Tech устраивает летнюю перезагрузку, чтобы зарядиться новыми идеями и встретиться с сильным комьюнити backend-разработчиков. Топ-инженеры Ozon Tech откроют детали работы с крупнейшим highload в стране: — как неконтролируемый трафик в API Gateway и DDoS бьют по домену — и какие инструменты помогут его защитить; — как превратить блокировку ресурсов в инструмент для оптимизации работы приложения и системы; — как ускорить ваши микросервисы и повысить конверсию пользователей; — как обновлять конфигурации сервисов в проде в кратчайшие сроки и без ущерба стабильности. Подавай заявку на GoSharp Weekend, чтобы на один вечер сменить свет монитора на закат у воды, DJ-сет и живое общение.

Примеры middleware для ограничения частоты запросов в ASP .NET 1. Fixed Window Limiter (20 запросов за 2 минуты) Фиксированное временное окно. После достижения лимита блокирует все запросы до конца текущего окна. Лимит сбрасывается каждые 2 минуты. 2. Sliding Window Limiter (20 запросов за 2 минуты, 4 сегмента) Делит окно на сегменты (в примере 4 сегмента по 30 секунд). Когда открывается новый сегмент, самый старый истекает. Это распределяет нагрузку более равномерно и сглаживает трафик. 3. Token Bucket Limiter (15 токенов максимум, пополнение 1 токен/сек) Позволяет кратковременные всплески нагрузки за счёт накопленных токенов. Каждый запрос расходует токен, при их нехватке запросы ограничиваются до восстановления токенов (по 1 в секунду). 4. Concurrency Limiter (5 параллельных запросов, 10 в очереди) Ограничивает число одновременно обрабатываемых запросов (в примере до 5). Остальные попадают в очередь (до 10). Если очередь переполнена, новые запросы возвращают 503 или 429 (если переопределено). В коде эти лимитеры регистрируются в AddRateLimiter() и привязываются к конкретным эндпоинтам через .RequireRateLimiting() 👉 @KodBlog

Как находить медленные запросы в Entity Framework Используя систему перехватчиков Entity Framework и подключаясь к событию ReaderExecuted мы можем видеть сколько времени реально занимают запросы Сохрани в закладки 🧀

    
        public class SlowQueryInterceptor : DbCommandInterceptor
{
    private const int _slowQueryThreshold = 200; // миллисекунды

    public override DbDataReader ReaderExecuted(
        DbCommand command,
        CommandExecutedEventData eventData,
        DbDataReader result)
    {
        if (eventData.Duration.TotalMilliseconds > _slowQueryThreshold)
        {
            // Логируем медленный запрос — тут можно вставить свою систему логирования
            Console.WriteLine(
                $"Slow query ({eventData.Duration.TotalMilliseconds} ms): {command.CommandText}");
        }

        return base.ReaderExecuted(command, eventData, result);
    }
}

public class YourDbContext : DbContext
{
    // ... твои DbSet ...

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder
            .UseSqlServer("YourConnectionString") // замени на свою строку подключения
            .AddInterceptors(new SlowQueryInterceptor());
    }
}{}
    

Как это работает 1. Создаём класс перехватчика, наследуемся от DbCommandInterceptor и реализуем метод ReaderExecuted 2. Регистрируем этот перехватчик в контексте через AddInterceptors 👉 @KodBlog

Изоляция данных в модульном монолите - Схема и роль на модуль — для каждого модуля создаётся собственная схема и роль - Привилегии только для своей схемы — модуль не имеет доступа к данным других схем - Отдельный DbContext + схема по умолчанию — разделение кода и данных на уровне ORM - Разные строки подключения и миграции — независимое управление конфигурацией и развёртыванием - Read-only представления для межмодульных запросов — безопасный доступ к данным между модулями Смотрите пошаговое руководство: ссылка 👉 @KodBlog

🤢🤢🤢Проводим самый БОЛЬШОЙ розыгрыш этого лета сразу на 🤢🤢🤢🤢🤢🤢🤢 рублей РАЗЫГРЫВАЕМ iPhone 16 Pro Max, Macbook Air M4, AirPods Pro и кучу других призов — с вас всего лишь подписка. Для участия нужно: 🤢Быть подписанным на Техночат и Сёрч 🤢Нажать «Участвую!» под этим постом Итоги подведём 8 сентября в 18:00 случайным образом при помощи бота. Доставка для победителя бесплатная. Всем удачи!

Сохрани этот пост Покажу репозиторий на GitHub, где есть 99% кода, который тебе нужен для разработки 485 примеров кода .NET в одном месте 🙏 Репозиторий называется: practical-aspnetcore — https://github.com/dodyg/practical-aspnetcore В одном месте собрано 485 практических примеров, чтобы ты мог понять и эффективно внедрить ключевые возможности ASP .NET Core Что покрыто:

Authentication Blazor Caching Email gRPC HealthCheck Localization Logging Middleware Minimal API Open Telemetry Routing SignalR Security YARP

Это, по сути, швейцарский нож для .NET - инструменты почти для любой ситуации 👉 @KodBlog

Что такое RBAC и как это помогает с авторизацией RBAC расшифровывается как Role-Based Access Control, то есть управление доступом на основе ролей Суть простая • У ролей есть набор разрешений • Пользователи получают роли • Разрешения определяют, что пользователи могут делать Всё довольно просто, но при этом мощно Хотя сами по себе роли могут быть слишком широкими Поэтому я предпочитаю комбинировать роли с более точечными разрешениями. Вместо того чтобы хардкодить правила доступа, я привязываю разрешения к конкретным действиям и уже потом связываю эти разрешения с ролями Так проще управлять и легче расширять Как смоделировать такой подход и применить его в .NET — читать А как у тебя сейчас устроена авторизация в системе 😏 👉 @KodBlog

🎁 РОЗЫГРЫШ ПРИЗОВ 🎁 🤩 Nintendo Switch, оригинальный Labubu и Робот-доставщик на пульте управления: разыгрываем среди подписчиков! Все что нужно сделать: 1. ПОДПИСАТЬСЯ на все каналы: ✅ Сазонов о Web ✅ Путь Инди ✅ MZGames ✅ Платонов Девелопер ✅ Тот самый Алекс из Appwill ✅ Инди Андрюша | GameDev ✅ Kozlov Dev - Разработка игр ✅ Baxx Studio | Unity GameDev ✅ Savely Teplov | Welwise Universe ✅ Владислав Сухацкий - GameDev Блог 2. Нажать на кнопку «УЧАСТВУЮ» под постом ❗️ Победителя определим 22 августа в 19:00 мск на стриме! Итоги также появятся в телеграм-каналах. Победителей выберем случайно с помощью бота. Важно быть подписанным на все каналы. P.S. Все каналы по геймдеву

Я отучаюсь от всего, что знал про юнит-тестирование Потому что большая часть этого — неправда Для юнит-тестов нужен mocking-фреймворк Юнит-тест должен покрывать один метод С EF Core обязательно использовать Repository-паттерн для тестирования Если всё это совместить, получаются хрупкие тесты, которые ничего не говорят о требованиях и вынуждают плодить ненужные слои Вместо этого я придерживаюсь простых правил • Использовать фейки вместо mocking-фреймворка • Юнит-тесты проверяют поведение, а не структуру • При работе с EF Core использовать in-memory или SQLite провайдер и обходить их ограничения через интеграционные тесты Так тесты становятся менее хрупкими, покрывают больше кода и требуют меньше поддержки Кто со мной? 👉 @KodBlog