Не получается разобраться с EF Core queries?

По умолчанию EF Core уже логирует SQL, но вместо реальных значений parameters вы увидите плейсхолдеры ?.

Объедините EnableSensitiveDataLogging() с LogTo(), и получите реальные значения parameters прямо в query — именно в том виде, в котором EF отправляет его в базу данных.

optionsBuilder
    .LogTo(Console.WriteLine)
    .EnableSensitiveDataLogging();

Где это полезно:

• Видны реальные значения parameters вместо ?
• Можно скопировать точный SQL и сразу выполнить его в БД
• Легче обнаружить ситуации, когда EF отправляет неправильный тип или неожиданный NULL

Никогда не включайте это в production. В logs могут попасть чувствительные данные: PII, tokens и keys. Ограничивайте использование через проверку environment, а не через комментарий с напоминанием отключить настройку позже.

👉 @KodBlog

Что должно находиться в слоях Clean Architecture?

Clean Architecture — один из самых распространённых подходов к правильному разделению ответственности. Но на практике разработчики часто размещают компоненты не в тех слоях.

Вот что обычно относится к каждому слою:

1) Domain
• Events
• Entities
• Exceptions
• Repository Interfaces

2) Application
• Services
• Behaviours
• Validators
• Queries / Commands

3) Infrastructure
• Email
• Storage
• Background Jobs
• Database — если нет отдельного слоя Persistence
• Repository Implementations — если нет отдельного слоя Persistence

4) Persistence (опционально, если отделён от Infrastructure)
• Database
• Repository Implementations

5) Presentation
• Controllers
• Middlewares
• View Models или Request Models

👉 @KodBlog

IAsyncActionFilter недооценивают, хотя это очень мощный инструмент.

В ASP.NET Core filters позволяют выполнять собственную логику до или после определённых этапов request pipeline, не затрагивая controllers.

Есть две основные причины использовать их:

1. Переиспользование — одну и ту же логику можно применять к нескольким controllers или actions.
2. Расширяемость — business rules можно полностью вынести из action methods.

IActionFilter выполняется до и после action method и хорошо подходит для лёгких синхронных проверок. IAsyncActionFilter стоит использовать, когда сама проверка требует await, например обращения к базе данных или внешнему service.

Вместо двух отдельных методов «до» и «после», как в синхронной версии, здесь используется один OnActionExecutionAsync, который оборачивает delegate next(). Вызовите next(), чтобы продолжить pipeline, либо не вызывайте его и установите context.Result, чтобы досрочно завершить обработку request.

// EmailVerifiedFilter.cs
internal sealed class EmailVerifiedFilter(
    IUser currentUser,
    IUserService userService) : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(
        ActionExecutingContext context,
        ActionExecutionDelegate next)
    {
        Guid? userId = currentUser.Id;

        if (userId != null &&
            !await userService.IsEmailVerifiedAsync(userId))
        {
            context.Result = new ForbidResult();
            return;
        }

        await next();
    }
}

// Program.cs
builder.Services.AddScoped<EmailVerifiedFilter>();

// UsersController.cs
[HttpGet("dashboard")]
[ServiceFilter(typeof(EmailVerifiedFilter))]
public IActionResult GetUserDashboard()
{
    ...
}

Где этот подход особенно полезен:

• Проверка подтверждения email или подписки
• Проверка business rules перед выполнением action
• Условная блокировка request без early return в каждом action
• Cross-cutting logic, которую иначе пришлось бы копировать в десятки controllers

Для обычных проверок ролей или policies, не требующих обращения к БД, обычно лучше подходит IAsyncAuthorizationFilter. Он выполняется до model binding, поэтому отклонённому request не придётся проходить ненужный этап привязки данных.

👉 @KodBlog

Как вы рисуете архитектурные диаграммы?

Скорее всего, вы уже знакомы с одним из самых популярных подходов — UML. Но есть и другой вариант — C4 Model.

C4 включает четыре уровня представления архитектуры:

• System Context Diagram
• Container Diagram
• Component Diagram
• Code Diagram

Это лёгкий и понятный подход к визуализации архитектуры программных систем. Создатель C4 Model Simon Brown также выпустил книгу по этому подходу — её тоже стоит посмотреть.

Хотите подробнее разобраться в C4 Model? Начать можно с этой статьи: https://milanjovanovic.tech/blog/visualize-your-software-architecture-with-the-c4-model

👉 @KodBlog

6 ошибок в EF Core queries, которые кажутся безобидными в development, но дорого обходятся в production:

• Фильтры, которые не позволяют эффективно использовать indexes
• Загрузка целых entities, когда нужны всего несколько columns
• Result sets, которые растут без каких-либо ограничений
• Загрузка связанных данных, приводящая к N+1 queries или огромным JOIN

Буферизация тысяч строк, когда данные можно обрабатывать через streaming
Tracking entities, которые вы не собираетесь обновлять

В статье каждый пункт разобран на примерах: компромиссы разных подходов и то, что стоит проверять в первую очередь, когда EF Core endpoint начинает тормозить.

Полная статья здесь

👉 @KodBlog

Одна из самых крутых возможностей .NET, о которой почти никто не говорит:

→ Channels

Найти их можно в namespace System.Threading.Channels.
Channels позволяют организовать асинхронный обмен сообщениями с помощью простого C#-кода. Они предоставляют два основных API:

• для записи сообщений в channel
• для асинхронного чтения сообщений из channel

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

Например, на основе Channels можно реализовать простой in-memory message bus — разумеется, со всеми ограничениями такого подхода.

Пример реализации: https://milanjovanovic.tech/blog/lightweight-in-memory-message-bus-using-dotnet-channels

👉 @KodBlog

Нужно получить ID авторизованного пользователя в Web API?
(При условии, что User ID был добавлен как claim при генерации token.)

✔️ Создайте интерфейс IUser
✔️ Реализуйте его для получения ID из claims
✔️ Зарегистрируйте зависимости
✔️ Внедрите IUser и получайте ID пользователя в нужном месте приложения

👉 @KodBlog

Я встречаю этот code smell почти в каждом production-коде, который приходится разбирать.

→ Magic numbers и magic strings.

Главная проблема таких значений — отсутствие смысла. Это просто произвольное число или строка, из которых непонятно, что именно они означают. Из-за этого код сложнее понимать и проще сломать. Что разработчики могут сделать, чтобы добавить смысл?

Мой предпочтительный вариант — вынести значение в config или использовать enum. То есть дать magic number или string понятное имя.

Имя уже объясняет намерение кода и делает его гораздо проще для понимания. Это лишь один из способов сделать код чище.

Сегодня Clean Code Sunday, поэтому вот ещё 5 советов по рефакторингу C#: 5 Awesome C# Refactoring Tips

👉 @KodBlog

Clean Code — это не про то, чтобы писать больше кода.

Это про то, чтобы делать код понятнее, проще для тестирования и поддержки. Вот 5 практических советов по Clean Code для .NET-разработчиков:

1/ Давайте понятные имена
Код должен объяснять себя сам и не требовать лишних комментариев.

2/ Старайтесь не возвращать null
Так можно сократить количество постоянных null checks и снизить риск NullReferenceException.

3/ Делайте классы и методы небольшими
Разделяйте ответственности, чтобы код было проще понимать, тестировать и поддерживать.

4/ Не изобретайте велосипед
Используйте готовые abstractions и libraries из .NET вместо того, чтобы заново решать уже решённые задачи.

5/ Используйте подходящие инструменты и IDE
Освойте возможности своей IDE, а для единообразия между проектами используйте .editorconfig и общие .props файлы.

👉 @KodBlog

Распространённая ошибка в software architecture, которую я часто встречаю:

→ Код организован без учёта бизнес-задач и частоты изменений.

К счастью, Vertical Slice Architecture (VSA) решает эту проблему довольно просто. Вместо разделения приложения на горизонтальные layers, VSA организует код вокруг конкретных features или use cases.

Почему это важно?

• Такой подход даёт несколько преимуществ:
• Повышает cohesion
• Упрощает поддержку
• Снижает общую сложность
• Фокусирует код на business logic

Вот с чего можно начать: https://milanjovanovic.tech/blog/vertical-slice-architecture-structuring-vertical-slices

👉 @KodBlog

17 ключевых слов C#, которые стоит запомнить

1/ static — принадлежит самому типу, а не конкретному экземпляру.
2/ const — определяет константное значение, известное на этапе компиляции.
3/ readonly — значение можно присвоить только при объявлении или в конструкторе.
4/ async / await — используются для написания асинхронного кода без блокировки потока во время ожидания.
5/ yield — упрощает создание итераторов, возвращая значения по мере их запроса.
6/ ref — передаёт переменную по ссылке, позволяя методу изменять её.
7/ out — передаёт переменную по ссылке, при этом вызываемый метод должен присвоить ей значение.
8/ params — позволяет методу принимать переменное количество аргументов.
9/ is / as — используются для проверки типа и безопасного приведения типов.
10/ lock — обеспечивает эксклюзивный доступ к критической секции в многопоточном коде.
11/ base — предоставляет доступ к членам и конструкторам базового класса.
12/ this — ссылается на текущий экземпляр.
13/ new — создаёт объект или скрывает унаследованный член.
14/ abstract — определяет классы или члены, предназначенные для реализации в производных типах.
15/ sealed — запрещает наследование от класса.
16/ override — предоставляет новую реализацию унаследованного virtual-члена.
17/ partial — позволяет разделить определение типа между несколькими файлами.

👉 @KodBlog

В .NET можно использовать Wolverine как Mediator, не создавая отдельные handler interfaces для каждого request.

Вот как это настраивается:

1/ Установите Wolverine
Добавьте пакет Wolverine в проект.
2/ Зарегистрируйте Wolverine
Настройте Wolverine при конфигурации приложения.
3/ Создайте Request
Определите request как обычный record или class. Специальный mediator interface не требуется.
4/ Создайте Handler
Добавьте метод Handle. Wolverine сам найдёт подходящий handler по conventions.
5/ Вызовите из Endpoint
Внедрите IMessageBus и отправьте request из API endpoint.
6/ Wolverine обработает весь flow
Endpoint → Request → Wolverine → Handler → Response

В результате получается чистый request/response flow с меньшим количеством boilerplate, связанного с Mediator pattern.

При этом возможности Wolverine не ограничиваются mediation: он также поддерживает asynchronous messaging, durable messaging, scheduled delivery, retries, sagas и transactional messaging.

👉 @KodBlog

Я попросил AI-ассистента написать всего один метод.

В итоге он принял за меня с десяток решений — и ни об одном не предупредил.

Промпт был простым: «Получи заказы для списка пользователей». В ответ я получил 10 строк аккуратного C#-кода. Всё компилировалось. Тесты проходили. Казалось, всё отлично.

А потом я внимательно посмотрел на код. Вот какие решения AI молча принял за меня:

• Новый HttpClient при каждом вызове
• Нет timeout
• Нет retries
• Нет ограничения на количество параллельных requests
• Нет cancellation
• Нет logging и tracing
• Ошибка для одного пользователя ломает весь batch

Сегодня ни один из этих пунктов не выглядит как явный bug. На моей машине всё работает. Но каждый из них может стать проблемой в production. Поэтому я это исправил.

👉 @KodBlog

На дворе 2026 год, а вы всё ещё не используете OpenTelemetry?

Вот как он может упростить жизнь software engineer. Если вам важна observability, стоит знать про OpenTelemetry.

Это vendor-neutral open-source стандарт для инструментирования приложений и сбора telemetry data.

Если проще — речь про:
• Logs
• Traces
• Metrics

Работает ли это с .NET? Да. Для .NET есть несколько библиотек, которые достаточно легко интегрировать в приложение.

Вот простой гайд, с которого можно начать знакомство: https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet

👉 @KodBlog

Ваш .NET API отлично работает локально. Но это ещё не значит, что он готов к продакшену.

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

В статье я разобрал, что важно в каждом пункте, почему это имеет значение и как всё настроить на практике в .NET.

Полная статья: https://mwaseemzakir.substack.com/p/before-your-net-api-goes-to-production

👉 @KodBlog