Мой секрет, как не ронять продакшен: запускать тесты в CI/CD.

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

Хотите вывести интеграционное тестирование в .NET на новый уровень?

Подробное руководство

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

Да, выполнение CI замедлится, но для меня это оправданно: так я обнаружил множество проблем ещё до того, как они попали в продакшен.

👉 @KodBlog

Чем отличаются middleware и фильтры в .NET?

Фильтры в ASP.NET Core:
• Имеют доступ к контексту MVC: данным маршрутизации и, на соответствующих этапах, результатам привязки модели.
• Выполняются внутри конвейера MVC при обработке действий контроллера.
• Применяются к действиям контроллеров.
• Используются для задач MVC: логирования, авторизации и валидации.
• Примеры: ActionFilterAttribute и ResultFilterAttribute.
• Позволяют вынести общую логику обработки действий MVC в отдельные компоненты.
• Имеют доступ к HttpContext, но ориентированы на обработку в рамках MVC.
• Порядок выполнения зависит от типа фильтра, значения Order и области применения.
• Могут применяться глобально, к отдельному контроллеру или действию.

Middleware в ASP.NET Core:
• Являются частью HTTP-конвейера обработки запросов.
• Могут выполнять логику до и после следующих компонентов, а также прерывать обработку запроса.
• Применяются ко всему приложению или к отдельным веткам конвейера.
• Настраиваются в Program.cs, а в проектах с классом Startup — в Startup.cs.
• Примеры регистрации: UseAuthentication(), UseAuthorization() и UseRouting().
• Решают общие задачи обработки запросов, не ограничиваясь MVC.
Имеют прямой доступ к HttpContext, запросу и ответу.
• Выполняются в порядке регистрации, а обработка после вызова следующего компонента проходит в обратном порядке.

Что выбрать? Используйте middleware, если задача решается на уровне HTTP-запроса и ответа: обработка ошибок, логирование, аутентификация. Выбирайте фильтры, когда нужны детали выполнения MVC: аргументы действия, состояние модели или результат действия.

👉 @KodBlog

Как использовать ИИ-агентов в .NET-разработке

На freeCodeCamp вышел гайд по внедрению ИИ-ассистентов в рабочий процесс .NET-команды. Внутри примеры на C#: генерация контроллеров и DTO, написание unit-тестов, рефакторинг, отладка и работа с Entity Framework.

Отдельно разобраны составление промптов, интеграция в CI/CD и безопасность. Автор показывает, как ускорить рутинные задачи, сохраняя ревью кода и автоматические проверки.

Читать статью

👉 @KodBlog

Что такое RBAC — управление доступом на основе ролей?

RBAC помогает организовать авторизацию: роли объединяют разрешения, пользователи получают роли и вместе с ними право выполнять определённые действия.

Принцип простой:
• Роли задают общие правила доступа.
• Каждая роль содержит набор разрешений.
• Пользователи получают разрешения через назначенные роли.
• Разрешения определяют, что пользователь может делать.

Зачем нужны отдельные разрешения?

Одних проверок ролей часто недостаточно для точных правил доступа. Например, роль «Редактор» слишком общая, если нужно отдельно управлять правами на создание, публикацию и удаление материалов.

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

Начните с вопроса «Какие действия может выполнять пользователь?» — так проще выстроить понятную и гибкую систему авторизации.

Подробнее о RBAC и его реализации

👉 @KodBlog

Union types в C# 15

Годами разработчики C# имитировали union types — типы-объединения — через маркерные интерфейсы, базовые классы и библиотеку OneOf. Всё ради того, чтобы выразить простую идею: «результат — либо Success, либо Failure». C# 15 переносит эту возможность на уровень языка.

Что меняется на практике:

• Набор вариантов объявляется один раз, например Success или Failure, и компилятор знает все допустимые случаи.
• Компилятор проверяет полноту switch: если пропустить вариант, он сообщит об этом ещё при компиляции.
• Для описания закрытого набора результатов больше не нужна сторонняя библиотека.

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

👉 @KodBlog

Архитектура ПО — это просто?..

Объединяйте связанные концепции, и приложения станут лучше. Неужели всё настолько просто? Конечно, нет. Но направление верное.

За этим стоит cohesion — связность. Идея в том, чтобы держать компоненты одной функциональности рядом.

В слоистой архитектуре они обычно разнесены по разным слоям. Чтобы добавить или изменить одну функцию, приходится править код сразу в нескольких местах.

Vertical Slice Architecture предлагает другой подход: все файлы одного сценария использования располагаются рядом. Так проще найти нужные компоненты, разобраться в их взаимодействии и внести изменения.

Подробнее о Vertical Slice Architecture

👉 @KodBlog

Ваш API отвечает пять минут? Это уже захват заложников

Пользователь смотрит на индикатор загрузки. Запрос занимает ресурсы сервера. Балансировщик обрывает соединение по тайм-ауту. Клиент повторяет запрос — и один отчёт строится уже дважды. Здесь поможет перенос долгой операции в фоновую обработку.

Как выглядит схема:

• Клиент отправляет POST /reports.
• API ставит задачу в очередь и быстро возвращает 202 Accepted с заголовком Location: /reports/42.
• Фоновый воркер забирает задачу и выполняет пятиминутную работу.
• Клиент запрашивает GET /reports/42 и получает статус Running.
• При следующей проверке получает Done и ссылку на результат.

Что это даёт:

• HTTP-запросы завершаются быстро, не дожидаясь построения отчёта.
• Длительность фоновой задачи больше не упирается в тайм-аут запроса.
• Воркеры масштабируются независимо от API.
• Повторная проверка статуса не запускает создание отчёта заново.

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

Ещё две детали:

• Возвращайте Retry-After, чтобы клиент понимал, через какое время снова проверить статус.
• Используйте SignalR или webhook, если нужно уведомлять о готовности вместо периодических запросов.

Длительная операция становится отдельным ресурсом: её можно создать, проверить состояние и получить результат. А как вы обрабатываете долгие задачи в своих API: polling, webhooks или SignalR?

👉 @KodBlog

Health Checks в .NET — два вызова методов

• AddHealthChecks() регистрирует необходимые сервисы.
• MapHealthChecks() добавляет эндпоинт для проверки состояния приложения.

Но это только инфраструктура. Сами проверки нужно зарегистрировать отдельно.

Для популярных баз данных, брокеров сообщений и других зависимостей уже существуют готовые библиотеки проверок.

Подробнее о Health Checks

👉 @KodBlog

Хватит возвращать BadRequest("какая-то строка")

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

В ASP.NET Core есть ProblemDetails: AddProblemDetails() и Results.Problem() помогают использовать единый машиночитаемый формат ошибок по стандарту RFC.

👉 @KodBlog

Пишете код каждый день? Помните о пяти вещах:

• Сначала добейтесь, чтобы код работал.
• Затем сделайте его понятным и аккуратным.
• Подстрахуйте его тестами.
• Избегайте избыточного усложнения.
• Проводите рефакторинг, когда это необходимо — а обычно это необходимо.

Рефакторинг — ваша суперсила для приведения кода в порядок.

Пять проверенных техник рефакторинга

С ИИ-агентами этот подход тоже работает. Но нужно уметь направлять их: ваши навыки разработки по-прежнему пригодятся.

👉 @KodBlog

Один API-запрос на несколько минут создаёт проблемы всем.

Пользователь смотрит на индикатор загрузки, сервер держит соединение открытым, а балансировщик или прокси может оборвать запрос по тайм-ауту. Повторные попытки только усугубляют ситуацию.

Решение — изменить подход к обработке долгих задач:

• Принять задачу и сразу вернуть 202 Accepted со ссылкой для проверки статуса.
• Выполнить тяжёлую работу в фоновом обработчике.
• Позволить клиенту опрашивать статус или получить уведомление о готовности результата.

Теперь отчёт, который формируется пять минут, не требует держать HTTP-запрос открытым всё это время. API остаётся отзывчивым, а фоновые обработчики можно масштабировать независимо от веб-серверов.

Длительная задача — это ресурс, который вы создаёте и отслеживаете, а не ответ, которого нужно ждать в открытом соединении.

👉 @KodBlog

Не начинайте с микросервисов ❌

Даже если уверены, что в будущем они понадобятся вашему приложению.

У микросервисов есть скрытые издержки:

• Координация команд.
• Сбои в распределённой системе.
• Работа с eventual consistency — согласованностью данных в конечном счёте.
• Автоматизация развёртывания нескольких сервисов.
• Управление множеством инфраструктурных компонентов.
• Выделение дополнительных ресурсов по мере необходимости.

На старте проекта такая сложность часто не оправдана. Менее рискованный подход:

• Начните с монолита.
• Определите границы предметной области — bounded contexts.
• Решите, нужно ли выделять отдельные контексты в самостоятельные сервисы.

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

👉 @KodBlog