Если вы думаете, что EF Core «медленный» в 2026 — вы просто живёте в прошлом.

Одна из мощных современных фич — bulk-операции, в том числе массовое удаление.

Теперь можно удалить любое количество записей одним запросом к базе.

Пример: e-commerce платформа хочет удалить все корзины, созданные более года назад. Раньше это выглядело так: загрузили сущности в память, RemoveRange, SaveChanges — лишние аллокации, трафик и нагрузка.

Теперь достаточно:

context.Carts
    .Where(o => o.CreatedOn < DateTime.Now.AddYears(-1))
    .ExecuteDelete();

В результате выполняется один SQL DELETE, который напрямую удаляет старые записи в базе — быстро и без промежуточных объектов в памяти.

⚠️ Важно: bulk-операции обходят change tracker EF. Если в контексте уже есть отслеживаемые сущности, состояние может рассинхронизироваться — учитывайте это в логике.

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

Подробнее

#ПятничныйКвиз #ДляСамыхМаленьких

⚡️ Guard Clauses в .NET: проверяй ошибки одной строкой

Хочешь упростить код и избавиться от вложенных if? Используй guard clauses — быстрые проверки входных данных в самом начале метода.

Вместо длинной логики и вложенности ты сразу останавливаешь выполнение, если данные некорректны. Код становится чище, короче и легче для чтения.

В новых версиях .NET появилось много встроенных проверок:

.NET 6:
- ArgumentNullException.ThrowIfNull

.NET 7:
- ArgumentException.ThrowIfNullOrEmpty

.NET 8:
- ThrowIfNullOrWhiteSpace
- ThrowIfNullOrEmpty (для коллекций)
- ThrowIfZero
- ThrowIfNegative
- ThrowIfGreaterThan

Когда это особенно полезно:
- в сервисах и API для валидации входных данных
- в доменных моделях — чтобы не допустить невалидного состояния
- в конструкторах и фабриках

Главная мысль:
Guard clauses — это не про «больше проверок»,
а про ранний отказ и чистую архитектуру.

public class Order
{
    public Order(string customerName, decimal amount)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(customerName);
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);

        CustomerName = customerName;
        Amount = amount;
    }

    public string CustomerName { get; }
    public decimal Amount { get; }
}

⚡️ Async-коммуникация ломает интеграционные тесты.

Вы отправляете событие в одном модуле… и что дальше? Ждать?

Если используете Thread.Sleep — готовьтесь к:
- медленным тестам
- flaky-поведению
- падениям в CI/CD

Решение — не ждать. Опрос (Polling).

Я использую паттерн Retry Assertion для тестирования асинхронного взаимодействия между модулями:

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

1. Выполняем команду (Модуль A)
2. Периодически выполняем запрос (Модуль B)
3. Ждём, пока результат появится
4. Делаем assert

Пример:

var userId = await Sender.Send(new RegisterUserCommand(...));

var result = await Poller.WaitAsync(
    TimeSpan.FromSeconds(15),
    async () =>
    {
        return await Sender.Send(new GetCustomerQuery(userId));
    });

result.Should().NotBeNull();
result.IsSuccess.Should().BeTrue();

Динамическая строка подключения в EF Core - когда и зачем это нужно

Факт
В EF Core можно задать connection string динамически при регистрации DbContext. Для этого используется делегат, который выполняется в момент получения контекста из DI.

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

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

Пример

builder.Services.AddDbContext<OrdersDbContext>((sp, o) =>
{
    var tenantProvider = sp.GetRequiredService<TenantProvider>();
    var connectionString = tenantProvider.GetConnectionString();

    o.UseSqlServer(connectionString);
});

Dynamic DbContext configuration - ключевой паттерн для масштабируемых multi-tenant систем.
Если приложение растёт и базы начинают разделяться по клиентам или регионам, этот подход становится стандартом архитектуры.

💡 Soft delete в EF Core без лишней логики в сервисах

Удалять данные физически — не всегда хорошая идея.
Логи, аудит, восстановление, аналитика — всё это требует soft delete.

Вот удобный способ реализовать его через EF Core interceptor.

Что делает перехватчик:

- Проверяет ChangeTracker на сущности с интерфейсом ISoftDeletable
- Если состояние сущности — Deleted
- Меняет его на Modified
- Устанавливает:
- IsDeleted = true
- DeletedOnUtc = DateTime.UtcNow

В итоге:

Вы вызываете обычный:

context.Remove(entity);

А в базе:

- запись не удаляется
- просто помечается как удалённая

Плюсы подхода:

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

Важно:

Если у вас есть связанные сущности (navigation properties),
перехватчик нужно дополнительно расширить — каскадное soft-удаление EF Core не делает автоматически.

Soft delete через interceptor — это один из самых чистых production-подходов для EF Core.

#dotnet #EFCore #Backend #Architecture #CSharp

⚡️ Exceptions - это для действительно исключительных ситуаций.

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

Самый удобный способ в ASP.NET Core - сделать глобальный обработчик через middleware:

- перехватываем любые необработанные исключения
- логируем ошибку
- возвращаем клиенту единый JSON-ответ (ProblemDetails) с 500

Пример:

public class ExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionHandlingMiddleware> _logger;

    public ExceptionHandlingMiddleware(
        RequestDelegate next,
        ILogger<ExceptionHandlingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception exception)
        {
            _logger.LogError(
                exception, "Exception occurred: {Message}", exception.Message);

            var problemDetails = new ProblemDetails
            {
                Status = StatusCodes.Status500InternalServerError,
                Title = "Server Error"
            };

            context.Response.StatusCode =
                StatusCodes.Status500InternalServerError;

            await context.Response.WriteAsJsonAsync(problemDetails);
        }
    }
}

В .NET 8 появился простой способ сделать HttpClient устойчивым к сбоям — буквально одной строкой.

Microsoft добавила библиотеку Microsoft.Extensions.Http.Resilience, в которой уже есть готовые pipeline’ы для обработки ошибок при HTTP-запросах.

Что это даёт из коробки:
- Retry при временных сбоях
- Timeout
- Circuit Breaker
- Rate limiting
- Защиту от перегрузки

Подключается максимально просто:

services.AddHttpClient<GitHubService>(static httpClient =>
{
    httpClient.BaseAddress = new Uri("https://api.github.com/");
})
.AddStandardResilienceHandler();

C# records - идеальный способ создавать value objects.

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

В DDD value object должен:
- быть неизменяемым (immutable)
- сравниваться по значениям, а не по ссылке

Именно это records дают из коробки.

Что получаем:
- неизменяемость через init
- структурное сравнение (Value Equality)
- короткий и чистый синтаксис
- deconstruction
- pattern matching

Пример:

public class Booking
{
    public Address Address { get; init; }
    public DateRange Period { get; init; }
}

public record Address(
    string Street,
    string City,
    string State,
    string Country,
    string ZipCode);

Теперь два Address считаются равными, если совпадают их поля - без переопределения Equals и GetHashCode.

Раньше для value object приходилось писать:
• конструкторы
• Equals
• GetHashCode
• оператор ==

Теперь - одна строка.

Records делают value objects:

• безопаснее
• проще
• ближе к функциональному стилю

Если используете DDD в .NET - records должны быть стандартом для value objects.