До сих пор выкатываешь новые фичи через if?

Есть решение получше.

В .NET есть отличная поддержка feature flags, и что важнее - таргетированных feature flags

Это значит, что можно включать функциональность:

- только для внутренних тестировщиков
- для определённого сегмента пользователей
- или даже для одного конкретного юзера

Больше никаких флагов "для всех сразу". Больше никаких костылей с разветвлённой логикой в коде.

Ты задаёшь правила, а .NET сам обрабатывает таргетинг.

А если совместить это с версионированием API, то получаешь полный контроль над тем, кто и когда увидит новое поведение.

Feature flags — это не просто переключатель кода. Это инструмент доставки продукта.

👉 @KodBlog

Устал каждый раз собирать .NET-проекты с нуля?

Есть готовый blueprint для .NET backend, в котором уже настроены 12 продакшен-фич:

- Современный .NET 9 Web API
- Архитектура Vertical Slice
- PostgreSQL + Entity Framework Core
- Преднастроенная аутентификация через Keycloak
- Swagger UI с поддержкой авторизации для интерактивного тестирования
- Глобальная обработка ошибок
- Локальная разработка с .NET Aspire без лишних танцев
- Интеграционные тесты на Test Containers
- Деплой на Azure в продакшн
- CI/CD пайплайны для GitHub Actions и Azure DevOps
- Поддержка GitHub Codespaces
- Шаблон dotnet new готов к установке

Это не очередной "Hello World". Это полноценный продакшен-бэкенд, который обычно занимает у разработчиков недели настройки.

Собран на Vertical Slice Architecture, потому что чистый код важнее, чем следование устаревшим слоёным паттернам.

Честно, если делаешь простые CRUD-приложения, это перебор. Но если нужен API, готовый к продакшену без мучений на старте этот шаблон сэкономит тебе 40+ часов.

👉 @KodBlog

Разница между IN и EXISTS в SQL:

🔸IN

- Пишется проще
- Загружает все совпавшие ID в память
- Тормозит на больших таблицах (например, Customers)
- Может плохо работать без индексов
- В случае NOT IN падает, если подзапрос возвращает NULL

🔸EXISTS

- Останавливается на первом совпадении
- Лучше дружит с индексами
- Эффективнее при коррелированных подзапросах
- Корректно обходит NULL
- По производительности
- На маленьких выборках: разница минимальна
- На больших: чаще выигрывает EXISTS
- В коррелированных подзапросах: почти всегда лучше EXISTS

IN должен вычислить и сохранить весь результат подзапроса.
EXISTS просто проверяет — существует ли строка, и идёт дальше.

Современные оптимизаторы умеют уравнивать разницу, но понимать это полезно при работе с реальными данными.

👉 @KodBlog

В dotnet 9 появился обобщённый OrderedDictionary

Во многих случаях нужно хранить пары ключ-значение с сохранением порядка и быстрым поиском по ключу. Теперь это можно делать с помощью обобщённого OrderedDictionary в .NET 9.

👉 @KodBlog

С неявными преобразованиями в Span<T> в .NET 10 теперь можно передавать массивы напрямую в методы, которые ожидают Span<T> или ReadOnlySpan<T>, без вызова .AsSpan(). Это делает высокопроизводительный код без аллокаций чище и безопаснее. Очень удобно

👉 @KodBlog

Dictionary Expressions в C#?

Сейчас это предложение в статусе champion (ссылка ниже) и продолжение фичи Collection Expressions из C# 12.

Что думаете? 👎 или 👍

Предложение Dictionary Expressions

👉 @KodBlog

Большинство разработчиков используют Code-First или Database-First подход в EF Core.

Но немногие знают про Model-First

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

Code-First даёт возможность строить базу данных из C#-классов и управлять схемой через миграции.

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

Есть более эффективный и современный вариант — Model-First.

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

Одним из лучших инструментов для Model-First является Entity Developer от Devart.

Он делает моделирование сущностей простым и удобным.
С помощью drag-and-drop интерфейса не нужно писать классы и вручную задавать связи.

– Меньше времени на шаблонный код и повторяющиеся конфигурации
– Быстрая генерация и обновление моделей по сравнению с ручным кодом
– Меньше риска ошибок рантайма из-за неверных маппингов или конфигураций
– Entity Developer генерирует корректный код и SQL-скрипты за вас

Вот гайд по тому, как именно это реализовать:

- Начало работы: создание EF Core модели для PostgreSQL
- Визуальное проектирование модели данных
- Генерация SQL-скриптов для PostgreSQL
- Автоматизация генерации кода EF Core
- Основные преимущества для разработки на EF Core + PostgreSQL

👉 @KodBlog

Всё, что нужно, чтобы запустить реальный продукт

1. Аутентификация → [ASP .NET Core Identity]
2. База данных → [EF Core + SQL Server/PostgreSQL]
3. Платежи → [Stripe, PayPal]
4. Безопасность → [FluentValidation, OWASP]
5. Фронтенд → [Next.js + Shadcn/UI]
6. Бэкенд → [ASP .NET Core Web API]
7. Уведомления → [SendGrid, SignalR]
8. Наблюдаемость → [Application Insights, Serilog, OpenTelemetry]

Надёжный фундамент превращает идеи в работающие продукты.

👉 @KodBlog

Какой способ пагинации лучше использовать?

Это зависит от данных.

Offset-пагинация используется по умолчанию: пропускаешь X строк, берёшь следующие Y.
Нормально для небольших выборок или неглубоких страниц, но чем дальше идёшь, тем медленнее работает.

Keyset (или cursor) пагинация лучше подходит для больших или часто обновляемых данных.

Вместо пропуска строк она «ищет» последнюю известную позицию (например, ID или timestamp) и оттуда достаёт следующую страницу.

Это быстрее, стабильнее и отлично работает для таких случаев, как:

- бесконечный скролл
- ленты активности
- почтовые ящики

Если делаешь что-то похожее, может помочь эта статья

А ты в своём проекте что используешь ?

offset - 👍 или keyset -❤️

👉 @KodBlog

Похоже, ты пропустил эти два типа коллекций.

Стоит о них знать, потому что…

Frozen collections — это новые коллекции, которые на 100% неизменяемы.

Но разве в .NET уже нет read-only и immutable коллекций?

Есть, но нюанс вот в чём…

Read-only коллекция может поменяться, если изменить исходную структуру данных.

Immutable коллекция при изменении создаёт новую копию оригинала с новыми значениями.

И вот тут проблема.

Frozen collections работают иначе.
После создания их изменить нельзя + у них вообще нет методов модификации.

На данный момент доступны только два типа:

- FrozenDictionary
- FrozenSet

Это абстрактные классы, их нельзя создать напрямую, как обычные Dictionary или Set.
Но можно использовать extension-методы.

Их стоит применять там, где коллекция редко создаётся, но часто используется.

Они оптимизированы под:

- быстрый доступ по ключу
- эффективное использование памяти
- потокобезопасность

Минус — более медленное создание.

Но, на мой взгляд, это вполне оправдано с учётом получаемых оптимизаций. Cогласны? 👍

👉 @KodBlog

Вот подробное руководство для C#-разработчиков по созданию и работе с серверами Model Context Protocol (MCP). Это практический материал для изучения MCP и интеграции AI-ассистентов в .NET-среде.

В .net 10 сервер MCP можно сделать за 20 строк кода — чек

👉 @KodBlog

Как сделать ежедневный отчёт и отправить его пользователям на почту?

Для этого можно использовать Coravel

Coravel — это библиотека для .NET без лишней конфигурации, вдохновлённая Laravel. Она добавляет в приложение фоновые задачи и автоматизацию, упрощая работу с бэкендом.

С помощью неё можно запускать задачи по расписанию, выполнять фоновые джобы в очереди, использовать invocables (классы фоновых задач), делать event broadcasting внутри процесса, рассылать письма и кешировать данные. Для всего этого не нужен ни брокер сообщений, ни база, ни внешние сервисы.

Конечно, Coravel не подойдёт для критически важных фоновых задач, где нужна надёжная персистентность или распределённая координация. Но как «ускоритель продуктивности» для .NET приложений — вполне рабочее решение.

Пробовал ли ты его? Ставь 👍 если да

Подробнее здесь: читать

👉 @KodBlog

Работаете с легаси-SQL в EF Core?

Хранимые процедуры, представления, странные джойны, которые не мапятся на ваши сущности?

Поддержка «сырого» SQL в EF Core сняла для меня большую боль.

Я просто объявляю простой POCO, пишу SQL и позволяю EF выполнить маппинг.

Никакой грязной конфигурации. Никакой ручной материализации.

И так как используются параметризованные запросы, это ещё и безопасно в плане SQL-инъекций.

Если вы работаете с легаси-базами, эта фича — спасение. 👍

Вот как этим пользоваться: тык

👉 @KodBlog

15 гайдов для изучения 15 лучших паттернов проектирования:

1. Singleton: https://algomaster.io/learn/lld/singleton

2. Factory Method: https://algomaster.io/learn/lld/factory-method

3. Abstract Factory: https://algomaster.io/learn/lld/abstract-factory

4. Builder: https://algomaster.io/learn/lld/builder

5. Adapter: https://algomaster.io/learn/lld/adapter

6. Facade: https://algomaster.io/learn/lld/facade

7. Decorator: https://algomaster.io/learn/lld/decorator

8. Composite: https://algomaster.io/learn/lld/composite

9. Proxy: https://algomaster.io/learn/lld/proxy

10. Iterator: https://algomaster.io/learn/lld/iterator

11. Observer: https://algomaster.io/learn/lld/observer

12. Strategy: https://algomaster.io/learn/lld/strategy

13. Command: https://algomaster.io/learn/lld/command

14. State: https://algomaster.io/learn/lld/state

15. Template Method: https://algomaster.io/learn/lld/template-method

👉 @KodBlog

Вот список постов Стивена Тауба про улучшения производительности в разных версиях .NET. Удобно держать под рукой:

.NET 9
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/

.NET 8
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/

.NET 7
https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/

.NET 6
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/

.NET 5
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/

.NET 3.0
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

.NET 2.1
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-2-1/

.NET 2.0
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core/

Надеюсь, завезет и про dotnet 10 👍

👉 @KodBlog

Как кеш может работать неправильно?

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

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

Пробой кеша случается, когда ключа нет ни в кеше, ни в базе. Приложение не может обновить кеш и создаёт лишнюю нагрузку. В этом случае помогает кеширование null для несуществующих ключей или проверка ключа через bloom filter, чтобы лишний раз не обращаться к базе.

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

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

А вы встречали такие ситуации в продакшене? 😱

👉 @KodBlog

В .NET 9 может быть самая удобная платформа для микросервисов и вот почему.

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

В .NET 9 всё это уже есть из коробки.

- Resilience
Встроенные ретраи, таймауты и circuit breakers, без сторонних библиотек.

- Observability
Поддержка OpenTelemetry из коробки. Трассировки, метрики и логи без лишних усилий.

- .NET Aspire
Cloud-native стек для быстрых распределённых систем.

- Service Discovery
Можно использовать логические имена сервисов вместо жёстко прописанных URL. В рантайме они резолвятся через конфиг.

- API Gateway
YARP — лёгкий reverse proxy, который работает и как API-шлюз, с минимальной настройкой.

Если вы строите микросервисы на .NET, больше не нужно собирать инфраструктуру вручную.

Подробности: ссылка

А как вы строите микросервисы? 👍

👉 @KodBlog

Добавление инструментов OpenTelemetry

Подробнее об инструментировании и анализе -- тут

👉 @KodBlog

Как включить DATAS в .NET 8

Dynamic adaptation to application sizes (DATAS) по умолчанию включен в dotnet 9, и многие приложения благодаря этому заметно сократили потребление памяти.

В .NET 8 можно включить его через настройку выше.

Не забудь прогнать бенчмарки своего сценария до и после.

https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/datas

👉 @KodBlog

Redis полезен не только для кэширования.

С его помощью можно реализовать базовый Pub/Sub механизм.

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

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

RabbitMQ и Kafka отлично подходят для сложных сценариев, но иногда достаточно чего-то простого, быстрого и уже встроенного в стек. Здесь пригодится Redis Pub/Sub.

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

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

Например, для обновления интерфейсов в реальном времени, для инвалидации кэша между сервисами или для передачи сигналов между приложениями.

Пример реализации: https://thecodeman.net/posts/messaging-in-dotnet-with-redis ✏️

👉 @KodBlog

Docker publisher в .NET Aspire позволяет описать всю среду разработки на C# и задеплоить её в Docker Compose.

Посмотрите, как Aspire упрощает работу с Docker Compose для .NET: тык

👉 @KodBlog