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

Вот пример работы с Testcontainersна .NET:

https://testcontainers.com/guides/getting-started-with-testcontainers-for-dotnet/

#dotnet #csharp #fsharp

@csharp_1001_notes

#Квиз #ПрощеНекуда #csharp

С# задачи

🔥 UUID v7 в .NET 9

.NET изначально поддерживает UUID v4 через Guid.NewGuid().

При этом начиная с предварительной версии 7, появилась поддержка UUID версии 7.

📌 UUID v7

Так как GUID является альтернативным названием для UUID, новый API находится в пространстве имен System.Guid:


var guid = Guid.CreateVersion7();
var guidWithTimestamp = Guid.CreateVersion7(DateTimeOffset.UtcNow);

Главным преимуществом является включение метки времени в UUID. Это дает 122 бита энтропии, включая 6 бит для версии и варианта где-то посередине.

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

📌 Контроль метки времени

Поскольку метод ожидает DateTimeOffset, вызывающая функция может использовать TimeProvider для контроля UtcNow:


var uuid = Guid.CreateVersion7(timeProvider.GetUtcNow());


timeProvider может быть получен через DI контейнер и подделан в тестовых сценариях.

#csharp #dotnet #code

Источник

@csharp_1001_notes

⚡ В EF Core чаще всего используют два подхода:
- Database-First — быстрое создание моделей из готовой БД
- Code-First — проектирование схемы через C# классы и миграции

Но оба могут тормозить разработку при сложных связях и настройках.

👉 Есть третий путь — Model-First.
Вы визуально проектируете модель, а она автоматически превращается в EF Core сущности и схему БД.

🛠 Один из лучших инструментов — Entity Developer от Devart:
- drag-and-drop интерфейс вместо ручного кода
- меньше рутины и ошибок в конфигурации
- точная генерация кода и SQL-скриптов
- быстрее дизайн → генерация → обновление моделей

Меньше кода ✍️, больше скорости 🚀.

#dotnet #efcore #csharp #devtools

⚡ .NET Channel Publisher — простой способ строить настоящий async messaging

📌 Как это работает:
- Использует System.Threading.Channels для асинхронной публикации событий
- Сообщения пишутся в канал и обрабатываются в фоне, не блокируя поток
- Поддержка CancellationToken для безопасной отмены

🔥 Плюсы:
- Минимум кода — максимум гибкости
- Высокая производительность и низкая задержка
- Удобно для event-driven архитектуры и микросервисов

На скриншоте:
- Пример класса ChannelPublisher для отправки нотификаций
- Трейсинг вызова Order.Service: POST orders показывает прозрачную обработку и асинхронность

#dotnet #csharp #async #messaging

🧩 Несколько DbContext в одном приложении на EF Core — когда это нужно

Использовать несколько DbContext в одном приложении — не ошибка, а часто отличное архитектурное решение.
Вот когда это оправдано:

- 🗃 Работа с несколькими базами данных
- 🧠 Разделение областей ответственности
- 🧩 Архитектура modular monolith
- ⚡ Использование read replicas

Автор применил это при создании модульного монолита:
каждый модуль имел собственную схему в БД и отдельный DbContext в коде.

Самое интересное — как EF Core справляется с миграциями и разными схемами баз данных.
Разбор и пошаговое решение — здесь:
🔗 https://milanjovanovic.tech/blog/using-multiple-ef-core-dbcontext-in-single-application

#DotNet #EFCore #CSharp #Backend #Architecture #DesignPatterns

ASP .NET 10 получил новую возможность — Server-Sent Events (SSE)

В свежем ASP .NET 10 появилась поддержка Server-Sent Events — современного способа стримить данные в браузер без WebSockets.

Что такое SSE
- Односторонний канал: сервер → браузер
- Идеально подходит для потоковых обновлений, логов, нотификаций, live-данных
- Работает поверх обычного HTTP, без сложной настройки протокола

Почему это круто
- Проще, чем WebSockets
- Легче масштабировать
- Отлично подходит для real-time интерфейсов и hypermedia-приложений
- Встроено прямо в ASP .NET 10, без сторонних библиотек

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

#dotnet #aspnet #csharp #backend #webdev

🐳 «Используй Testcontainers вместо in-memory» - это только половина правды

Все уже выучили: EF Core InMemory provider - не интеграционный тест.

Он не ловит:

- баги в LINQ-трансляции
- ограничения БД
- коллации
- реальные типы колонок
- поведение конкретного SQL-провайдера

Окей, заменили на реальный PostgreSQL через Testcontainers. Победа? Не совсем.

Вот что начинается дальше.

1. Вы получили «медленное враньё» вместо «быстрого»

Поднимать контейнер на каждый тест-класс - быстрый способ превратить CI из 30 секунд в 8 минут.

Нормальный вариант:

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

Respawn чистит таблицы с учётом графа foreign keys за миллисекунды.

2. Транзакционный откат ≠ реальный сценарий

Трюк «обернули тест в транзакцию и откатили» красиво выглядит, но ломается, когда в коде есть:

- свои транзакции
- несколько SaveChanges
- фоновые операции
- поведение, завязанное на commit

В итоге тестируется сценарий, которого в проде нет.

3. Самая коварная ловушка - общий DbContext

Если тест и код используют один экземпляр DbContext, EF может вернуть данные из change tracker, а не из базы.

Тест зелёный, но он врёт: реальный SQL-запрос мог вообще не выполниться.

Между Act и Assert стоит чистить трекер:

Db.ChangeTracker.Clear();

4. Бонус, который теряют 90% команд - тест миграций

Реальная БД позволяет прогнать EF-миграции на чистой схеме.

Если миграция падает или схема разъехалась с моделью, вы узнаёте об этом в CI, а не в проде в пятницу вечером.

Пример базового подхода:

public class IntegrationTestBase : IAsyncLifetime
{
    private static readonly PostgreSqlContainer _db =
        new PostgreSqlBuilder()
            .WithImage("postgres:16-alpine")
            .Build();

    private Respawner _respawner = null!;
    protected AppDbContext Db = null!;

    public async Task InitializeAsync()
    {
        await _db.StartAsync();

        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseNpgsql(_db.GetConnectionString())
            .Options;

        Db = new AppDbContext(options);

        // Реальные миграции - заодно проверяем, что они накатываются
        await Db.Database.MigrateAsync();

        await using var conn = new NpgsqlConnection(_db.GetConnectionString());
        await conn.OpenAsync();

        _respawner = await Respawner.CreateAsync(conn, new RespawnerOptions
        {
            DbAdapter = DbAdapter.Postgres,
            SchemasToInclude = ["public"]
        });
    }

    // Сброс данных перед каждым тестом - без пересоздания контейнера
    protected async Task ResetAsync()
    {
        await using var conn = new NpgsqlConnection(_db.GetConnectionString());
        await conn.OpenAsync();

        await _respawner.ResetAsync(conn);

        // Иначе тест может читать из кеша, а не из БД
        Db.ChangeTracker.Clear();
    }

    public Task DisposeAsync() => Task.CompletedTask;
}

Testcontainers - это не галочка «best practice», а смена философии.

Без нормальной изоляции данных вы просто пересели с быстрого вранья на медленное.

А как вы изолируете состояние БД между интеграционными тестами - Respawn, транзакции или пересоздание контейнера?

#dotnet #csharp #testing #efcore

🚀 C# 15 меняет подход к `unsafe`: указатели больше не означают автоматически опасный код

Раньше в C# сам факт использования указателя требовал:

unsafe
{
    int* ptr;
}

Теперь язык движется к более точной модели:

опасным считается не наличие указателя, а операция, которая реально работает с unmanaged-памятью.

В preview-версии C# 15 уже не требуют unsafe:

✅ объявление pointer-типа
✅ получение адреса через &
✅ fixed для закрепления памяти
✅ преобразование stackalloc в указатель
✅ sizeof для unmanaged-типов

Пример:

int number = 42;

int* pointer = &number;

int[] numbers = [10, 20, 30];

fixed (int* first = numbers)
{
    // само закрепление памяти безопасно
}

Но вот это всё ещё требует unsafe:

*pointer;        // dereference
pointer->Value; // доступ через указатель
pointer[0];     // работа с элементами
delegate*<>     // вызов function pointer

Главная идея:

**создать инструмент можно безопасно.
Опасно — когда начинаешь напрямую менять память.**

Это первый этап большой переработки модели безопасности C#.

Дальше ожидаются:

- requires-unsafe для отдельных членов;
- opt-in на уровне assembly;
- новый safe keyword.

C# постепенно делает unsafe-код более точечным: меньше блоков вокруг всего файла, больше внимания к реально опасным операциям.

#csharp #dotnet #programming

⚡️ C#-приём: не привязывай метаданные к объектам через обычный `Dictionary` — иногда нужен `ConditionalWeakTable`.

Допустим, библиотека кеширует данные о типах:

private static readonly Dictionary<Type, Metadata> Cache = new();

В обычном приложении это может годами работать без проблем.

Но если используются plugins, dynamic assemblies или unloadable AssemblyLoadContext, такой словарь способен удерживать Type, а вместе с ним — всю загруженную сборку.

И получить memory leak.

Для таких случаев в .NET есть малоизвестный:

ConditionalWeakTable<TKey, TValue>

Пример:

private static readonly ConditionalWeakTable<Type, Metadata> Cache = new();

static Metadata GetMetadata(Type type)
{
    return Cache.GetValue(type, BuildMetadata);
}

Ключ здесь хранится слабо.

Если Type больше нигде не нужен, GC может его собрать, а связанная запись автоматически исчезнет из таблицы.

Это особенно полезно для:

* reflection-кешей;
* proxy/framework-кода;
* source/runtime metadata;
* plugin-систем;
* приложений с AssemblyLoadContext.

🔥 Если видишь:

static Dictionary<Type, ...>

или

static ConcurrentDictionary<Type, ...>

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

не удерживает ли этот кеш сборки в памяти навсегда?

Иногда правильный ответ — ConditionalWeakTable.

#CSharp #DotNet #Backend #Programming #CLR