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

Вот антипример: не стоит добавлять к IEnumerable индексатор, который внутри вызывает ElementAt.

От индексатора обычно ожидают стоимость доступа O(1).

доки

👉 @KodBlog

Как обычно рисуют архитектурные диаграммы?

Самый распространённый вариант — UML-диаграммы.
Но есть и другой подход — модель C4.

C4 расшифровывается как:
Context Diagram — диаграмма контекста системы
Container Diagram — диаграмма контейнеров
Component Diagram — диаграмма компонентов
Code Diagram — диаграмма кода

Это лёгкая модель для описания архитектуры, которая помогает постепенно раскрывать систему: от общего представления до деталей реализации.

👉 @KodBlog

Windows 11 26H2: что нового этой осенью

Осенью Microsoft выпустит обновление Windows 11 26H2, которое принесёт множество улучшений во всей операционной системе.

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

Похоже, это будет один из самых интересных релизов Windows за последние годы.

Вот всё, что известно на данный момент

👉 @KodBlog

Если тебе кажется, что для результатов true/false есть только if/else…
…то вот альтернатива.

Тернарный оператор — это условный оператор в C#, который во многих случаях работает как компактная версия if/else.

Для него нужны три части:
- условие;
- результат, если условие истинно;
- результат, если условие ложно.

Если условие возвращает true, используется первое значение. Если false — второе.
Тернарный оператор поддерживает target-typing и может использоваться с var.

При этом типы результатов должны быть совместимы: один тип должен неявно приводиться к другому либо оба значения должны приводиться к целевому типу.

Тернарный оператор помогает сократить несколько строк кода до одной.
Но если условий становится много, код быстро становится запутанным и хуже читается.
Так что держи в голове: тернарный оператор — хорошая альтернатива для простых if/else.
Для более сложной логики лучше использовать switch expression.

👉 @KodBlog

Планировщик запросов PostgreSQL использует динамическое программирование, чтобы подобрать наиболее дешёвый порядок JOIN при объединении нескольких таблиц.

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

https://internals-for-interns.com/posts/postgres-query-planner/

👉 @KodBlog

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

Такие значения ничего не объясняют сами по себе, поэтому код становится сложнее читать, понимать и поддерживать, а вероятность ошибок растёт.

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

Небольшое изменение, которое делает код чище и понятнее.

👉 @KodBlog

Как понять, что твоя стратегия кеширования правильная?

Ключевая метрика — процент запросов, когда данные находятся в кеше.

Это называется коэффициент попаданий в кеш и показывает, как часто ты можешь переиспользовать закешированный объект.

Вот как замаксить этот коэффициент:

I. Размер пространства ключей

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

II. Размер кеша и элементов

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

III. Долговечность

Во многих случаях можно кешировать объекты на предопределённое время, так называемый Time to Live, TTL.
В других случаях ты не можешь рисковать устаревшими данными и должен инвалидировать объекты в кеше.
В общем, чем дольше ты можешь держать элементы в кеше, тем выше шанс их переиспользовать.

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

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

👉 @KodBlog

Как быстро находить узкие места в запросах EF Core:

Можно визуализировать план выполнения SQL-запроса прямо в Visual Studio и сразу увидеть, что именно стоит оптимизировать.

Для этого есть расширение EFCore.Visualizer.

Оно поддерживает SQL Server, PostgreSQL, SQLite, MySQL и Oracle.

Используется прямо во время отладки: наведите курсор на запрос EF Core — появится возможность открыть его план выполнения.

Пример на скриншоте .

👉 @KodBlog

Что вам не нужно на старте проекта:

— Kubernetes
— микросервисы
— отдельные базы для чтения и записи

Что действительно нужно:

— юнит-тесты
— CI/CD-пайплайн
— монолитная архитектура

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

👉 @KodBlog

Надоело раскладывать проект по слоям?

Vertical Slice Architecture предлагает другой подход: код группируется по фичам, а не по горизонтальным слоям вроде Controllers, Services и Repositories.

В результате всё, что относится к конкретной фиче, находится рядом:

— выше связность кода
— проще вносить изменения
— меньше переходов между слоями и папками
— бизнес-логика не размазана по всему проекту

И есть ещё один актуальный плюс: такой подход хорошо ложится на работу с LLM и кодинг-агентами. Когда весь контекст фичи собран в одном месте, модели проще понять, что именно нужно изменить.

👉 @KodBlog

Используете ли вы человекочитаемые ID объектов?

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

Начнём с выбора типа данных для идентификаторов объектов, или первичных ключей.

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

Однако у автоинкрементных ID есть недостаток: они делают приложение уязвимым для перебора идентификаторов. Если ID текущего объекта — 42, злоумышленник может предположить, что следующий объект имеет ID 43. При наличии незащищённых API-эндпоинтов этим можно воспользоваться.

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

UUID также полезны, когда ID объекта необходимо сгенерировать непосредственно в коде, а не на стороне базы данных.

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

Иначе обстоит дело с такими ID:

* ord_01HZW2RKF63AWC1BT901FPGRGT

* tr_afdf5738-6a8e-4d1a-90db-e894a3828320

По префиксу можно понять, к какому типу относится объект. Например, ord может означать Order — заказ, а tr — Transaction — транзакцию.

При этом такие ID необязательно делать первичными ключами в базе данных. Их можно генерировать в коде перед возвратом данных клиенту.

Такой формат сделает API более удобным и понятным для его потребителей.

Как вы относитесь к человекочитаемым ID объектов?

👉 @KodBlog

Если вы создаёте новый API на .NET 9 или .NET 10 и ищете привычную страницу документации, её больше нет.

Годами в стандартном шаблоне использовался Swashbuckle, а интерактивная документация появлялась сразу из коробки. Теперь всё изменилось. Фреймворк сам генерирует OpenAPI-документ, а встроенный UI больше не входит в шаблон по умолчанию.

На первый взгляд кажется, что это потеря. Но потом становится понятно, что пришло на замену. Фреймворк сам создаёт OpenAPI-спеку одним вызовом. Дальше можно подключить современный UI поверх этой спеки.

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

Главное изменение — поменялось место, где находится ответственность за описание API. Теперь OpenAPI-спека принадлежит самому фреймворку, а не сторонней библиотеке UI, которую приходится накручивать поверх. Интерфейс документации становится тонким слоем, который можно заменить без изменения процесса генерации спеки.

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

👉 @KodBlog

Анонсирована v2.0 официального MCP SDK для C#.

MCP C# SDK 2.0 реализует спецификацию от 28 июля 2026 года и включает:
- протокол с приоритетом на stateless-режим работы;
- стандартизированные HTTP-заголовки;
- поддержку Multi Round-Trip Requests для интерактивных инструментов.

При этом SDK сохраняет обратную совместимость с предыдущими версиями.

👉 @KodBlog

В C# 15 появятся break и continue с метками.

«Они заменят обходные решения для управления потоком выполнения во вложенных циклах: например, булевый флаг, который устанавливается во внутреннем цикле и затем проверяется на каждом внешнем уровне, или goto, перескакивающий за пределы циклов».

👉 @KodBlog

Блог .NET: от сгенерированного кода к проверенному с помощью агента для написания юнит-тестов.

https://devblogs.microsoft.com/dotnet/polyglot-unit-testing-agent/

👉 @KodBlog

Middleware, но для исходящих HTTP-запросов?
Да, в ASP.NET Core такое есть.

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

Отличный сценарий использования? Добавление заголовков аутентификации в запрос.

👉 @KodBlog

Агенты Copilot Studio получили полноценные корпоративные идентификаторы.

Теперь каждому новому агенту автоматически выдаётся собственный Microsoft Entra Agent ID. Отключить это нельзя.
После публикации агента разрешения поддерживаемых коннекторов Power Platform отображаются прямо в его профиле в Entra.

Администраторы могут:

Видеть, к каким сервисам настроено обращение агента
Проверять историю входов
Управлять его жизненным циклом
Настраивать доступ к коннекторам через Conditional Access

DLP и Advanced Connector Policies по-прежнему контролируют доступ во время выполнения.
Теперь у агента есть собственный идентификатор, назначенный ответственный, видимые разрешения, журналы и политики.

Именно такой уровень управления был нужен корпоративным агентам.

Пока есть одно ограничение: сквозное применение Conditional Access по Agent ID к вызовам коннекторов сейчас работает только в Teams. При этом разрешения видны во всех каналах.

Microsoft готовит серьёзные вещи.

👉 @KodBlog

В .NET 11 появилось множество изменений в JIT (они также применяются к Native AOT), которые устраняют избыточные проверки границ массива. Цель — сделать безопасный код таким же быстрым, как и unsafe.

Эти изменения можно отслеживать по метке reduce-unsafe. Один из примеров улучшений — по ссылке ниже.

https://github.com/EgorBot/Benchmarks/issues/169

#dotnet

👉 @KodBlog

А вы знали? Теперь в C# есть ключевое слово safe 🙃

Оно обязательно для всех P/Invoke-объявлений и полей в структурах с explicit или extended layout. Нужно явно указать либо safe, либо unsafe — если не указать модификатор, код не скомпилируется.

👉 @KodBlog