Изучаем CollectionsMarshal для Dictionary (.NET)

В отличие от ConcurrentDictionary, обычный Dictionary не имеет метода GetOrAdd.
Он нужен, чтобы добавить пару ключ–значение, если ключа ещё нет, или вернуть существующее значение, если он уже есть.

Наивная реализация выглядит так:

public static TValue GetOrAdd<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    if (dict.TryGetValue(key, out var result))
        return result;

    dict[key] = value;
    return value;
}

Проблема → словарь обращается к ключу дважды: один раз для проверки наличия, второй — для вставки.
Это значит, что хеш-код и Equals вызываются минимум по два раза — неэффективно.

Более быстрый вариант с CollectionsMarshal

Метод CollectionsMarshal.GetValueRefOrAddDefault возвращает ссылку на значение по ключу и флаг, существует ли ключ.
Так как возвращается именно ref, значение можно менять напрямую:

public static TValue GetOrAdd<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    ref var dictionaryValue = ref CollectionsMarshal.GetValueRefOrAddDefault(dict, key, out var exists);
    if (exists)
        return dictionaryValue;

    dictionaryValue = value;
    return value;
}

Обновление значения с GetValueRefOrNullRef

CollectionsMarshal также предлагает метод GetValueRefOrNullRef, который позволяет обновить значение, если ключ уже существует:

public static bool TryUpdate<TKey, TValue>(this Dictionary<TKey, TValue> dict, TKey key, TValue value)
    where TKey : notnull
{
    ref var dictionaryValue = ref CollectionsMarshal.GetValueRefOrNullRef(dict, key);
    if (!Unsafe.IsNullRef(ref dictionaryValue))
    {
        dictionaryValue = value;
        return true;
    }

    return false;
}

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

👉 @KodBlog

Скрытая цена энтерпрайз-архитектуры на .NET

Ад адской отладки.

За 13+ лет в .NET-кодовых базах — одно и то же:

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

IUserService → вызывает → IUserRepository
IUserRepository → оборачивает → IUserDataAccess
IUserDataAccess → дергает → IUserQueryBuilder
IUserQueryBuilder → наконец-то стучится → в базу

Чтобы поменять одно правило валидации → проходишь 5 слоев.
Чтобы починить баг → открываешь 7 файлов.

И оправдание всегда одно и то же:
«А вдруг нам придется заменить Entity Framework?»
«А вдруг мы поменяем базу?»
«А вдруг нам понадобится несколько реализаций?»

А вдруг то, а вдруг это.

Реальность такая:
99% этих "вдруг" никогда не происходят.

Я не видел ни одного проекта, где реально сменили ORM.
Зато видел десятки разработчиков, теряющих часы в лабиринтах абстракций.

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

Итог?
Ты больше времени тратишь на навигацию, чем на разработку.

Хорошие абстракции прячут сложность.
Плохие → создают её.

А в большинстве энтерпрайз-.NET-проектов второго типа слишком много.

👉 @KodBlog

Используй C# для работы с файлами Excel
(полностью бесплатно, кстати)

Если на машине установлен Excel (или Office 365, если уж на то пошло), то в системе уже есть встроенные библиотеки для программной работы со всеми приложениями Office.

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

Но даже в 2025 году есть простой и понятный способ управлять Office из кода.

А LINQPad — идеальная среда для такого демо.

Добавь NuGet-ссылку на https://Microsoft.Office.Interop.Excel

Посмотри этот пример кода, чтобы понять, как:

- открыть книгу
- прочитать листы
- прочитать ячейки

Код создает невидимый процесс Excel для чтения и записи данных в таблицу. Минус в том, что Excel должен быть установлен на машине, поэтому этот способ не подходит для headless-автоматизации.

👉 @KodBlog

С EF Core можно делать забавные штуки.

Конфигурация сущности с:

- CHECK-ограничением Price > 0
- контролем точности столбца Price
- уникальным индексом на Name

Дальше генерим EF-миграцию и накатываем всё в базу.

Источник: читать

👉 @KodBlog

Бенчмарк: чтение таблиц из C#

ClosedXML vs EPPlus
(FOSS против коммерческого решения)

Не стоит слишком углубляться в это.

LINQPad делает бенчмаркинг кода через BenchmarkDotNet до безумия простым.

Исходная таблица: 1000 строк и 2 колонки.
Колонка A: int
Колонка B: string

ClosedXML примерно на 29% быстрее в этом тесте.

С субъективной стороны — ClosedXML, на мой взгляд, проще в использовании.

👉 @KodBlog

Узнайте все о протоколе HTTP

Всё про самый используемый протокол в интернете. 😎

✓ Все коды состояния с пояснениями
✓ Заголовки и методы с примерами
✓ Инструменты для тестирования HTTP
✓ Понятная инфа про HTTP/3

→ https://http.dev

👉 @KodBlog

Сохрани себе нервы, когда работаешь с базой данных.

Всегда оборачивай UPDATE или DELETE в транзакцию с откатом — так ты защитишься от случайных косяков.

Лично я первым делом пишу:

begin transaction

rollback transaction

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

Когда всё готово и уверен в результате = либо выделяешь нужный SQL и запускаешь напрямую,
либо просто меняешь rollback transaction на commit transaction.

👉 @KodBlog

Code Coverage теперь доступен в Visual Studio Community и Professional

Раньше эта функция была только в Enterprise-версии, но теперь любой разработчик может проверить, насколько хорошо его код покрыт тестами - прямо из IDE.

Больше не нужно ставить сторонние плагины или собирать отчёты вручную. Просто запускаешь тесты и Visual Studio показывает, какие участки кода реально выполнялись, а какие остались нетронутыми.

Отличный ход Microsoft 👍

👉 @KodBlog

В .NET считается хорошей практикой задавать размер List<T> при создании. И у меня есть бенчмарк, который это подтверждает.

Если добавить в список 10 миллионов элементов, то версия с заранее заданной емкостью работает примерно на 60% быстрее, чем список, созданный через конструктор по умолчанию.

Проблема на поверхности простая:

- List<T> внутри использует обычный массив
- по умолчанию Capacity = 0

То есть новый экземпляр List<T> всегда стартует с нуля.

Что происходит, когда список заполняется? Создается новый массив!
Когда элементы добавляются, а внутренний массив уже заполнен:

a) создается новый массив (всплеск использования памяти)
b) старые данные копируются в новый массив (лишние операции)

Получается довольно неприятный цикл.

Избежать этого можно, если создавать List<T> сразу с емкостью, примерно соответствующей ожидаемому количеству элементов.

Бенчмарк — добавление 10 миллионов элементов в список.

Тестировались три варианта:

- Capacity = 10_000_000 (равен ожидаемому количеству)
- Capacity = 5_000_000 (половина ожидаемого)
- Capacity = 0 (по умолчанию)

Если за базовую точку взять Capacity = 0:

- при Capacity = 50% — прирост скорости 48%
- при Capacity = 100% — прирост скорости 53%

👉 @KodBlog

Майкрософт выпустил второй и последний релиз-кандидат .NET 10, который поставляется с лицензией go-live и поэтому уже может использоваться в production. Этот выпуск .NET 10 добавляет главным образом улучшения и исправления уже имеющегося функционала и поддерживается в новом выпуске Visual Studio 2026 Insiders, а также в Visual Studio Code с C# Dev Kit.

Окончательный релиз .NET 10 с C# 14 состоится 11 ноября.

https://devblogs.microsoft.com/dotnet/dotnet-10-rc-2/

👉 @KodBlog

Есть вещи в C#, которые настолько базовые для современного .NET, что игнорировать их почти преступление. Это не модные фишки, а практичные инструменты, по которым легко отличить код новичка от кода опытного разработчика.

1. Проверка зависимостей на старте

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

Как делает новичок:

builder.Services.AddScoped<IMyService, MyService>();
// Без проверки

Ошибка проявится только при первом же запросе.

Как делает опытный:

var builder = Program.CreateHostBuilder(args);
builder.Services.AddScoped<IMyService, MyService>();
builder.Host.UseDefaultServiceProvider((context, options) =>
{
    options.ValidateOnBuild = true;
    options.ValidateScopes = true;
});

Эти настройки заставляют контейнер проверить конфигурацию при сборке приложения. ValidateScopes выявляет, например, внедрение scoped-сервиса в singleton, а ValidateOnBuild — пробует создать сервисы ещё до запуска. Ошибки проявятся сразу, а не в проде.

2. Осознанное использование областей действия

Многие просто лепят всё в Transient, не задумываясь, что это вообще значит. А время жизни сервисов — это не синтаксис, это логика памяти приложения.

Типичный пример:

builder.Services.AddTransient<UserSession>();

Без понимания, когда объект должен жить и когда исчезать.

Что знает опытный разработчик:

- Transient – новый экземпляр каждый раз,
- Scoped – один экземпляр на запрос/скоуп DI,
- Singleton – один экземпляр на всё время жизни приложения.

Создавая свой скоуп, можно изолировать контексты:

using var scope = serviceProvider.CreateScope();
var scopedService = scope.ServiceProvider.GetRequiredService<IScopedThing>();

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

3. DateTimeOffset вместо DateTime

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

Плохой вариант:

var orderTime = DateTime.Now; // локальное время

В другом часовом поясе это может поехать.

Хороший вариант:

var orderTime = DateTimeOffset.Now;

DateTimeOffset хранит не только момент времени, но и смещение. Это идеально для логов, транзакций и расписаний. Храните в UTC, показывайте пользователю в его часовом поясе.

4. Алиасы для пространств имён и типов

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

До:

System.Collections.Generic.Dictionary<System.Tuple<string, int>, List<MyNamespace.Models.ComplexThing>> myMap;

После:

using ComplexMap = System.Collections.Generic.Dictionary<(string, int), List<ComplexThing>>;

Алиасы — это не просто сокращение, это способ упростить чтение и сделать код гибче. При смене библиотеки или рефакторинге правите одну строчку и всё работает.

👉 @KodBlog

Новичок в C#: «Когда стоит использовать static-класс?»

NPC-ответ: «Когда тебе не нужен экземпляр».

Формально верно, но бесполезно. Такой ответ помогает только самооценке того, кто его дал.

На практике всё проще и понятнее:

Используй обычный класс, когда хочешь смоделировать систему, чтобы её было легче понять и использовать.
Система это набор связанных данных и операций над ними.
Например, табло очков (scoreboard): у него есть данные (очки, имена, время), и есть поведение (обновить счёт, сбросить, вывести). Ценность в целостности системы, а не в отдельном поле.

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

Но если ты не моделируешь и не внедряешь зависимости, тогда используй static-класс.
Всё, что ты делаешь это, скорее всего, утилитарная операция, которая не зависит от состояния и может применяться к любым данным.

Честно говоря, можно было бы даже сказать, что static-классы должны быть дефолтом, а instance использовать только тогда, когда действительно есть повод включать ООП.

👉 @KodBlog

Встраивать бизнес-логику прямо в SQL-запросы?

Это верный способ превратить код в нечто нетестируемое и хрупкое.

Представь, ты делаешь поиск по инвойсам. Нужно фильтровать по:

- номеру инвойса
- имени клиента
- email
- статусу заказа
- названию продукта

И всё это в любых комбинациях.

Самое быстрое, но грязное решение — напихать всю эту логику прямо в SQL-запрос.
И вот теперь все твои бизнес-правила оказались заперты внутри базы.
Тестировать их без реальной базы уже не выйдет.

Альтернатива — Specification Pattern.

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

Как это работает:

Создаёшь класс спецификации, который описывает критерии поиска.

Он принимает фильтры и строит выражение (например, LINQ).

Потом передаёшь эту спецификацию в репозиторий или обработчик запросов.

Этот подход отлично подходит для фильтрации и сложных запросов.

Результат:

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

Specification Pattern это про то, чтобы держать логику в месте, где её можно понять, протестировать и не проклинать через полгода. 🔫

👉 @KodBlog

👉 @KodBlog

На Хабре вышла статья о том, как с помощью EF Core и PostgreSQL избежать deadlock и oversell при работе со стоками. Автор разбирает подход с сортировкой обновлений по ключам, использованием ExecuteUpdateAsync, повторными попытками (retry), триггерами, очередями и батчами.

В статье есть бенчмарки, примеры кода и ссылка на репозиторий на GitHub.

Читать подробнее: habr.com/ru/articles/955714/

👉 @KodBlog

В превью C# 14 появились partial-конструкторы и partial-события.

Каждый из них должен состоять ровно из одного объявления-определения и одного объявления-реализации.

Реализация partial-события обязана содержать add и remove аксессоры.

👉 @KodBlog

На GitHub появился классный репозиторий с чётко структурированным материалом по system design. В нём собраны:

- основы проектирования крупных систем,
- типичные вопросы и решения для собеседований,
- карточки Anki для запоминания ключевых концепций.

Сохрани, чтобы не потерять: https://github.com/donnemartin/system-design-primer

👉 @KodBlog

Ты правильно называешь свои DTO?

Какую схему именования выбрать

Когда ты делаешь Web API, твои эндпоинты принимают и отдают данные.

Частая практика — добавлять к таким моделям суффикс Dto

Но вот в чём проблема:

DTO часто смешивают входные и выходные данные в одном классе.
Со временем такие классы разрастаются и становятся непонятными.

Мой вариант: использовать суффиксы Request и Response вместо Dto:

• CreateUserRequest —> для входных данных
• UserResponse —> для выходных

Почему так лучше:

Чёткое назначение —> сразу видно, модель для входа или для выхода.
Масштабируемость —> изменения в Response не ломают Request.
Поддерживаемость —> не надо гадать, что вообще делает UserDto.

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

А ты как называешь свои модели Request/Response или Dto? Делись опытом

👉 @KodBlog

Деревья выражений в C# помогают создавать быстрые и эффективные методы преобразования данных, ускоряя работу с объектами и запросами в Entity Framework Core. В статье раскрываются механизмы мэппинга и построения сложных фильтров через IQueryable.

Читать подробнее: https://habr.com/ru/articles/932110/

👉 @KodBlog

Экономим память как профи: 5 продвинутых техник

Если вы работаете с .NET, то знаете, под капотом куча мощных инструментов, про которые редко говорят. Вот 5 API, которые реально экономят память и ускоряют код.

1. CollectionsMarshal.AsSpan() — прямой доступ к списку

Обычно List<T> это удобная, но безопасная обёртка над массивом.
Если нужен Span без копирования:

using System.Runtime.InteropServices;

var numbers = new List<int> { 1, 2, 3, 4, 5 };
Span<int> span = CollectionsMarshal.AsSpan(numbers);

Работает напрямую с внутренним массивом списка, без ToArray().
Важно: при изменении размера списка Span станет недействительным.
Когда использовать: большие буферы, короткие циклы.
Выигрыш: до 2 раз меньше памяти.

2. CollectionsMarshal.GetValueRefOrNullRef() — доступ к словарю без двойного поиска

Обычный способ вызывает поиск ключа дважды:

if (dict.TryGetValue("foo", out var value)) {
    value++;
    dict["foo"] = value;
}

Лучше так:

using System.Runtime.InteropServices;

ref int valueRef = ref CollectionsMarshal.GetValueRefOrNullRef(dict, "foo");
if (!Unsafe.IsNullRef(ref valueRef))
    valueRef++;

Получаем ссылку прямо на значение без повторного поиска.
Когда использовать: большие словари, горячие циклы.
Выигрыш: примерно в 2 раза быстрее.

3. GC.AllocateUninitializedArray<T>() — массив без обнуления

.NET по умолчанию обнуляет массив:

int[] arr = new int[1000];

Если вы всё равно перезаписываете элементы - то это лишняя работа.
Быстрее:

int[] arr = GC.AllocateUninitializedArray<int>(1000);
for (int i = 0; i < arr.Length; i++) arr[i] = i;

Когда использовать: если массив заполняется сразу.
Выигрыш: ~15% быстрее на больших массивах.

4. ArrayPool<T>.Shared и IMemoryOwner — аренда массивов

Постоянные аллокации убивают GC:

for (int i = 0; i < 1000; i++) {
    var buffer = new byte[1024];
    DoSomething(buffer);
}

Используем пул:

using System.Buffers;

for (int i = 0; i < 1000; i++) {
    using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(1024);
    DoSomething(owner.Memory.Span);
}

Когда использовать: сетевые серверы, конвейеры, потоковые операции.
Выигрыш: до 1000 раз меньше аллокаций.

5. ObjectPool<T> — переиспользование дорогих объектов

Создание тяжёлых объектов вроде StringBuilder дорого:

for (int i = 0; i < 100; i++) {
    var sb = new StringBuilder(1024);
    sb.Append("Hello ").Append(i);
    Console.WriteLine(sb.ToString());
}

Пулим:

using Microsoft.Extensions.ObjectPool;

var provider = new DefaultObjectPoolProvider();
var pool = provider.CreateStringBuilderPool();

for (int i = 0; i < 100; i++) {
    var sb = pool.Get();
    sb.Clear();
    sb.Append("Hello ").Append(i);
    Console.WriteLine(sb.ToString());
    pool.Return(sb);
}

Когда использовать: логирование, сериализация, временные буферы.
Выигрыш: до 4 раз быстрее, в 50 раз меньше памяти.

Если вы когда-нибудь заглядывали в свой профилировщик и задавались вопросом, почему так много времени тратится на сборку мусора или копирование памяти, эти приёмы помогут вам это исправить. Они требуют аккуратности, но дают настоящую производительность.

👉 @KodBlog

Rider 2025.3 EAP 6 уже доступен!

В этом билде появилась поддержка ASP. NET и обнаружения проблем с базой данных прямо в окне Monitoring 🔥

Теперь, когда ты запускаешь или отлаживаешь приложение, мониторинг автоматически определяет:

Медленные или чрезмерно частые запросы к БД
Слишком большие результаты выборок
Медленные действия MVC или обработчики Razor-страниц
…и многое другое

Подробнее — здесь

👉 @KodBlog