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

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

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

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

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

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

👉 @KodBlog

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

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

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

👉 @KodBlog

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

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

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

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

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

👉 @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

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

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

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

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

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

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

👉 @KodBlog

Union types в C# 15

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

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

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

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

👉 @KodBlog

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

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

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

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

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

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

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

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

👉 @KodBlog

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

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

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

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

👉 @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

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

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

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

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

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

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

👉 @KodBlog

Шпаргалка по безопасности .NET

• Устанавливайте для cookies флаг HttpOnly, чтобы клиентские скрипты не могли получить к ним доступ.

• Используйте [Authorize] для контроллеров и .RequireAuthorization() для эндпоинтов, чтобы ограничивать доступ.

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

• При аутентификации через cookies проверяйте anti-forgery-токены для запросов, изменяющих состояние, чтобы защищаться от CSRF.

• Обновляйте NuGet-пакеты и используйте инструменты, которые уведомляют об уязвимостях зависимостей.

• Логируйте подозрительную активность и события безопасности, не записывая пароли, токены и другие секреты.

• Для защиты от SSRF проверяйте адреса исходящих запросов, формируемые на основе пользовательского ввода, и ограничивайте доступные назначения.

• Не храните секреты в appsettings.json и репозитории. Используйте предназначенные для этого хранилища секретов.

👉 @KodBlog

Как создавать фоновые задачи в .NET?

С Quartz достаточно реализовать один интерфейс:

• Создать класс задачи.
• Зарегистрировать его в Quartz.
• Quartz возьмёт на себя планирование и выполнение.

Библиотека полностью поддерживает DI, поэтому можно внедрять нужные сервисы. Задачи выполняются в отдельном scope, что позволяет безопасно внедрять DbContext.

Начав использовать Quartz, сложно вернуться к другим решениям — хотя альтернативы, конечно, есть.

Подробное руководство по работе с Quartz в .NET: Читать статью

👉 @KodBlog

17 .NET-библиотек, которые стоит держать под рукой каждому backend-разработчику

Необязательно писать всё с нуля. Вот какие задачи закрывает каждая:

Wolverine — современный mediator и message bus для CQRS со встроенными outbox, retries и планированием.
Dapper — лёгкий micro ORM. Особенно удобен для сложных запросов с большим количеством таблиц и JOIN.
Serilog — структурированное логирование с поддержкой более 40 sinks.
Bogus — генерация реалистичных тестовых данных для разработки и тестирования.
FluentValidation — валидация моделей с помощью понятного fluent-синтаксиса.
Refit — уменьшает количество boilerplate-кода при работе с HTTP API поверх HttpClient.
Health Checks — стандартный механизм проверки состояния сервисов и интеграции с мониторингом и алертами.
Hangfire / Quartz — надёжное выполнение и планирование фоновых задач для сценариев, где обычных hosted services уже недостаточно.
Noda Time — корректная работа с датами, временем и часовыми поясами. Создана Джоном Скитом.
Autofac — DI-контейнер для более сложных сценариев внедрения зависимостей.
MiniProfiler — простой способ быстро найти узкие места в производительности приложения.
FastEndpoints — библиотека для создания Web API на основе REPR-паттерна. Структурированная альтернатива controllers и Minimal APIs.
NSubstitute — простой в настройке mocking framework для тестов.
System.Text.Json — зрелая сериализация JSON и стандартный вариант для современных .NET-приложений.
BenchmarkDotNet — точные бенчмарки производительности .NET-кода.
Scalar — интерактивная документация для API, современная альтернатива Swagger UI.
SignalR — упрощает реализацию real-time функций: чатов, уведомлений, live-обновлений и других сценариев.

А какой инструмент из списка чаще всего используете вы?

👉 @KodBlog

Интерактивные курсы по Git

GitHub запустила cборку онлайн курсов, где можно прокачать навыки работы с Git и GitHub бесплатно. Ветки, коммиты, pull request’ы, Actions и реальные командные сценарии.

Быстрый и лёгкий способ подтянуть базу и перестать гуглить «как откатить коммит» в неподходящий момент.

👉 @KodBlog

Можете найти ошибку в этом фрагменте кода?

Второй пример вставляет 10 000 записей в базу данных в 43 раза быстрее. Откуда такая огромная разница в производительности?

Код в обоих примерах выглядит похоже. Но если понимать, как EF работает под капотом, ответ становится очевидным.

Каждый вызов SaveChanges означает обращение к базе данных. В первом примере для вставки каждой записи выполняется отдельный вызов. И накладные расходы быстро накапливаются…

Вот как правильно решить эту задачу: читать статью.

Лишние запросы к БД — одна из главных причин падения производительности. Не допускайте этой ошибки в своём коде.

👉 @KodBlog

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

Вот почему.

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

С помощью архитектурных тестов можно контролировать:
• Направление зависимостей.
• Соглашения об именовании.
• Различные правила проектирования.

Подробное руководство, которое, думаю, вам понравится: читать статью.

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

Добавили бы такую проверку в свой процесс ревью кода?

👉 @KodBlog

Ваш API входа раскрывает злоумышленникам, у кого есть аккаунт?

Распространённая ошибка: Если email не существует, возвращать «Пользователь не найден». Если пароль неверный, возвращать «Неверные учётные данные».

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

Обычное исправление: всегда возвращать «Неверные учётные данные», независимо от причины ошибки. Хорошее начало. Но есть второй канал утечки, который многие упускают.

Когда пользователя не существует, вы пропускаете проверку пароля и быстро возвращаете ответ. Когда пользователь существует, вы обрабатываете введённый пароль с помощью bcrypt или Argon2, а это занимает ощутимое время.

Сообщение одинаковое. Время ответа разное. Злоумышленник просто измеряет миллисекунды и составляет тот же список зарегистрированных аккаунтов, используя секундомер вместо текста ошибки.

Вот как закрыть эту брешь:

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

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

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

👉 @KodBlog

Когда мне нужна функциональность в реальном времени, я выбираю проверенное решение:

→ SignalR

SignalR позволяет добавить взаимодействие в реальном времени в .NET-приложения. При этом клиент может быть написан на React, Angular или обычном JavaScript.

Вы создаёте класс SignalR Hub. Это центральный компонент приложения, который управляет клиентскими подключениями и обменом сообщениями. Клиенты подключаются к Hub, чтобы отправлять и получать сообщения, поэтому связь может быть двусторонней.

SignalR скрывает детали транспортного механизма. Обычно используется WebSockets, но при необходимости библиотека может переключиться на Server-Sent Events или опрос сервера.

Всё, что нужно для начала: статья.

SignalR определённо входит в число лучших библиотек экосистемы .NET.

👉 @KodBlog