🔢 Когда числа становятся понятными

UnitsNet — .NET-библиотека, которая превращает голые числа в осмысленные физические величины.

Пример: вместо double speed = 27.8;
вы пишете Speed speed = Speed.FromMetersPerSecond(27.8);
и работаете уже с километрами в час, милями или узлами — без ручных пересчётов.

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

Ещё один плюс — читаемость кода. Ваши расчёты выглядят как документация: сразу видно, где давление, где скорость, а где длина.

➡️ Попробовать либу

🐸Библиотека шарписта

#sharp_view

💡 Domain Validation в .NET и DDD — просто о сложном

В .NET-проектах часто пишут валидацию прямо в контроллере или сервисе:
— проверили, что поле не пустое,
— число больше нуля,
— email подходит по формату.

Это правильно, но есть проблема — бизнес-правила остаются размазаны по коду.
В итоге можно случайно создать объект в некорректном состоянии (например, заказ без товаров).

В идеале должно быть два уровня валидации Application Validation И Domain Validation. В одном проверяются входные данные, а в другом строится защита сущностей от нарушения бизнес-правил.

Пример проверки на уровне приложения:

public record CreateOrderDto(string CustomerEmail, List<OrderItemDto> Items);

public class OrderApplicationValidator
{
    public static void Validate(CreateOrderDto dto)
    {
        if (string.IsNullOrWhiteSpace(dto.CustomerEmail))
            throw new ArgumentException("Email is required");

        if (!dto.CustomerEmail.Contains("@"))
            throw new ArgumentException("Email format is invalid");

        if (dto.Items == null || dto.Items.Count == 0)
            throw new ArgumentException("Order must contain at least one item");
    }
}

Здесь мы проверяем только корректность ввода.

А вот внутри домена мы защищаем бизнес-правила:

public class OrderItem
{
    public string ProductName { get; }
    public int Quantity { get; }
    public Money Price { get; }

    private OrderItem(string productName, int quantity, Money price)
    {
        ProductName = productName;
        Quantity = quantity;
        Price = price;
    }

    public static OrderItem Create(string productName, int quantity, Money price)
    {
        if (string.IsNullOrWhiteSpace(productName))
            throw new InvalidOperationException("Product name cannot be empty");

        if (quantity <= 0)
            throw new InvalidOperationException("Quantity must be greater than zero");

        return new OrderItem(productName, quantity, price);
    }

    public Money GetTotal() => Money.Create(Quantity * Price.Amount);
}

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

🐸Библиотека шарписта

#il_люминатор

❔ Отдохнуть или покушать

Давайте помечтаем — ваш работодатель даёт вам выбор: 1 sick-day (отгул с сохранением ЗП) в месяц или оплата одного обеда в неделю.

💬 Что вы выберете? Почему? Ждём в комментариях 👇

🐸Библиотека шарписта

#entry_point

⏱️ Как ускорить асинхронный код в C#

Частая ошибка — писать асинхронные вызовы последовательно:

await GetUser();
await GetOrders();
await GetRecommendations();

Каждая операция ждёт предыдущую и если каждый запрос занимает по секунде, общее время = 3 секунды.

А можно иначе:

var userTask = GetUser();
var ordersTask = GetOrders();
var recsTask = GetRecommendations();

await Task.WhenAll(userTask, ordersTask, recsTask);

Все задачи стартуют сразу. Теперь общее время = 1 секунда (ожидание самой длинной операции).

Маленький приём — большая разница во времени выполнения.

🐸Библиотека шарписта

#sharp_view

🔄 Апдейт .NET Aspire

Microsoft представила .NET Aspire 9.5 — свежий релиз для разработки распределённых приложений. Главное новшество — file-based AppHost: теперь можно описать всё приложение в одном файле apphost.cs, без громоздких .csproj. Добавление ресурсов и сервисов делается буквально одной строкой.

Ещё появились улучшения в CLI, новая команда aspire update, упрощающая апгрейд SDK и интеграций, а также обновлённый дэшборд.

➡️ Блог разработчиков

🐸Библиотека шарписта

#async_news

❓ Что выведет код

Пишите свои ответы в комментариях 👇

Для любознательных ответ такой: 333

🐸Библиотека шарписта

#dotnet_challenge

👨‍💻 Каналы в .NET

Когда в приложении нужно обрабатывать поток данных от продюсеров к потребителям, первым делом вспоминают про очереди или ConcurrentQueue. Но в асинхронном мире этого мало. Поэтому в .NET есть каналы.

Канал устроен как пара из продюсера и потребителя. Когда продюсер пишет элемент в канал, он либо сразу уходит к потребителю, либо ждёт, если очередь переполнена. Потребитель, в свою очередь, может ждать новые элементы без блокировки потоков — всё работает на async/await.

Главная сила каналов — балансировка нагрузки.

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

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

Мини-пример:

var channel = Channel.CreateBounded<int>(5);

// producer
_ = Task.Run(async () =>
{
    for (int i = 0; i < 10; i++)
    {
        await channel.Writer.WriteAsync(i);
        Console.WriteLine($"Produced {i}");
    }
    channel.Writer.Complete();
});

// consumer
await foreach (var item in channel.Reader.ReadAllAsync())
{
    Console.WriteLine($"Consumed {item}");
}

Почему это лучше, чем ConcurrentQueue? Потому что Channel создан сразу с учётом асинхронности. Вам не нужно городить блокировки и таймеры ожидания — достаточно написать await reader.ReadAsync(), и код будет сам по себе масштабироваться без блокировки потоков.

🐸Библиотека шарписта

#sharp_view