Как управлять задержкой в методе Task.Delay в тестах?

Начиная с .NET 8, вы можете передать объект TimeProvider в метод Task.Delay

TimeProvider будет интерпретировать задержку.

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

👉 @KodBlog

AutoMapper и MediatR переходят на коммерческую модель 😡

То есть, проекты больше не будут полностью open source. Джимми пишет, что делает это, чтобы обеспечить долгосрочную устойчивость своих OSS-проектов. Ну и сразу уточняет: «нет, это не первоапрельская шутка».

Короче, ещё один популярный open source — в платку. Тренд последних лет продолжается.

Вот источник

👉 @KodBlog

Этот дашборд для отслеживания цен на акции с использованием Cursor + .NET. 🔥

Использовав вайб-кодинг до того, как это стало модным )

Бэкенд получает начальную цену акции с бесплатного API фондового рынка.

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

UI — это чистый HTML + JavaScript + Tailwind CSS для стилизации

Потребовалось около ~15 секунд, чтобы добавить поддержку темного режима. 😱

Я с нетерпением жду, как будет развиваться Cursor. Это однозначно самый простой способ быстро создать работающее ПО.

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

В целом, код не плохой. Он работает и читаем. Cursor может даже писать комментарии и рефакторить код.

Я получил лучшие результаты, используя Claude Sonnet 3.5.

А ты уже пробовал Cursor?

👉 @KodBlog

"EF Core медленный."

Нет. EF Core, вероятно, лучший фреймворк для доступа к базе данных среди всех языков прямо сейчас.

Но он не исправит плохой код или ваши плохие запросы.

Недавно я разбирал один проект, где тестировщики и разработчики жаловались:
"Наш .NET API тормозит в продакшене. Мы думаем, что EF Core — узкое место."

Я взглянул на код. Вот что я нашёл:

var users = await _context.Users.ToListAsync();

Это использовалось внутри пагинированной конечной точки. Без фильтров. Без Skip(). без Take()
И что ещё хуже — я видел это внутри циклов. API загружал 100 000+ записей на каждый запрос.

Конечно, оно было медленным.

EF Core — мощный инструмент, но он не защищает вас от типичных ошибок. А я их вижу постоянно:

⏩Ранний вызов ToList(), ломающий композицию запроса
⏩Отсутствие AsNoTracking() в сценариях с преобладанием чтения
⏩Ленивые загрузки в циклах, вызывающие проблему N+1
⏩Использование Include() повсюду, даже когда в этом нет нужды
⏩Отсутствие проекции только нужных столбцов через Select()
⏩Регистрация DbContext как Singleton (так делать нельзя)
⏩Отсутствие индексов в базе данных
и тд.

EF Core даёт гибкость, производительность и тесную интеграцию с .NET.

Но он предполагает, что вы знаете, что делаете.

Если ваши запросы EF Core медленные — проблема, скорее всего, в вас.

👉 @KodBlog

Иногда записи архитектурных решений просто огонь 😗

Примечание: AccountState находится в отношении 1:1 с SubnoscriptionState, поэтому оба используют один и тот же SubnoscriptionId в качестве первичного идентификатора.

Слушай, мы могли бы сделать их разными ради "чистого кода" или DDD-мусора, но эти две сущности связаны между собой, и Account будет генерировать события для Subnoscription — так эта штука работает в реальной жизни.

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

👉 @KodBlog

Как с помощью .NET 8 грамотно настроить ролевую авторизацию в многоуровневых приложениях

Всё это — с примерами кода и лучшими практиками, чтобы приложение было и безопасным, и масштабируемым.

⏩Читать тут

👉 @KodBlog | #cтатья

Устали листать запутанный и огромный файл Program.cs?

Вот как сделать его чище и читабельнее

Одно из первых, что мы делаем при создании приложения — это настройка:

⏩Логирования
⏩Базы данных и ORM
⏩CORS
⏩Аутентификации
⏩DI-сервисов
⏩Привязок для API

И всё это сваливается в Program.cs — и быстро превращается в кашу.

Вот тут и приходит на помощь паттерн расширения ServiceCollection

Он помогает организовать конфигурации сервисов в модульные, читабельные и тестируемые куски.
Больше никаких гигантских цепочек методов или запутанных блоков кода настройки.

Читай целый выпуск на эту тему с примерами

👉 @KodBlog

Минимальный пример приложения с поддержкой валидации в Minimal API — тык

Поддержка валидации в Minimal API будет добавлена в dotnet preview 3, который должен выйти совсем скоро

Пример показывает, как использовать атрибуты валидации, такие как Required, Range и StringLength, для проверки входных данных в минимальных API. Для запуска приложения перейдите в каталог api и выполните команду dotnet run

👉 @KodBlog

💡 EF Core Tip

При разработке можно включить EnableSensitiveDataLogging(), чтобы видеть реальные значения параметров в SQL-запросах — это помогает понять, что именно уходит в базу

Никогда не включай это в staging или production!

Функция логирует чувствительные данные (например, пароли, email, токены и т.д.), что может привести к утечке

⏩Можешь подробней почитать здесь

👉 @KodBlog

В C# скоро появятся Dictionary Expressions?

Это как продолжение фичи Collection Expressions из C# 12 — только теперь для словарей. Но пока что на стадии предложения

Как тебе идея? 🤔

👉 @KodBlog

Как проверить, что список не null и содержит элементы?

Существует несколько способов это сделать:

1. Классический способ
2. Способ с List.Count
3. Способ с Enumerable.Any
4. Способ с pattern matching

Какой из них ты предпочитаешь — или используешь другой подход? 🤔

👉 @KodBlog

Наткнулся тут на интересный проект — ReactiveGenerator

Это такой современный C# source generator, который автоматизирует реализацию уведомлений об изменении свойств, поддерживая как стандартный INotifyPropertyChanged, так и паттерны ReactiveUI

Нам, разработчикам, это даёт главное — чистый код без тонны однотипной ручной писанины.

Например, раньше приходилось вручную писать геттеры и сеттеры с вызовами RaiseAndSetIfChanged

Теперь же достаточно использовать атрибуты [Reactive] и [ObservableAsProperty]

👉 @KodBlog

Микросервисы

В правильном контексте они решают реальные проблемы

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

Микросервисы сделали это возможным.

1. У платежей была высокая нагрузка → мы масштабировали только этот сервис
2. Отчётность требовала тяжёлой обработки → мы использовали другой стек
3. Уведомления? Деплоились по нескольку раз в день без влияния на остальное

Это прекрасно работало.

Почему? Потому что проблема была достаточно серьёзной, чтобы оправдать сложность.

Но вот главное:

Микросервисы — не отправная точка

Если вы строите небольшую или среднюю систему с одной командой, чистый монолит с модульными границами будет быстрее, дешевле и проще в управлении

Начните с простоты. Переходите к микросервисам, когда (и только когда) проблема станет реальной

👉 @KodBlog

У нас был один класс под названием UserManager

Он занимался всем:

Регистрацией пользователей. Проверкой паролей. Отправкой приветственных писем. Логированием событий. Обновлением информации профиля. Даже вызовами сторонних API

Он работал. Пока не перестал 😵‍💫

Любое изменение становилось рискованным. Небольшое изменение в одном методе ломало другой. Юнит-тесты были в хаосе.

Никто не хотел к нему прикасаться

Вот тогда я по-настоящему понял принцип единственной ответственности (SRP):

🔜 Класс должен иметь только одну причину для изменения

Не потому что так красиво звучит. А потому что это делает код тестируемым, поддерживаемым и читаемым

Мы разбили UserManager на более мелкие, сфокусированные сервисы:

⏩UserRegistrationService
⏩EmailNotifier
⏩PasswordValidator
⏩AuditLogger

Вдруг всё стало понятно. Тесты стали точечными. Вносить изменения стало проще

SRP — это не просто правило. Это способ сохранить ваш код живым надолго

👉 @KodBlog

💡 В .NET 9 представлено новое поведение GUID, основанное на метке времени и случайности

Теперь GUID стал последовательным, что делает его более подходящим для реляционных баз данных

Также добавлено свойство Version, позволяющее определить версию созданного GUID

👉 @KodBlog

5 причин, почему простые extension-методы в C# чаще всего лучше AutoMapper 👇

1. Простота
Пишешь только то, что нужно и ничего лишнего. Extension-методы дают точное управление маппингом без лишней конфигурации

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

3. Читаемость
Код должен рассказывать историю. Когда другой разработчик читает маппинг, extension-метод чаще всего более прозрачен

4. Гибкость
Это твой код. Можно легко адаптировать логику под конкретные кейсы, не упираясь в ограничения сторонней библиотеки.

5. Отладка
Можно спокойно зайти в свой маппинг-код и сразу увидеть, что и как работает. Без необходимости лезть в внутренности AutoMapper

Простота, производительность и контроль — часто выигрывают, особенно когда пишешь чистую и поддерживаемую архитектуру

👉 @KodBlog

💡 Совет по C#

Используй метод string.Join, чтобы объединить элементы коллекции в одну строку, вставляя указанный разделитель между элементами.

А ты используешь string.Join в своём коде?

👉 @KodBlog

ASP.NET Core Roadmap for .NET 10 — здесь

Команда разработчиков ASP.NET Core изложила основные направления и функции, над которыми они планируют работать в рамках выпуска .NET 10

Этот список является предварительным и может изменяться по мере разработки

👉 @KodBlog

Новый релиз бесплатного инструмента T-SQL Analyzer на .NET для выявления антипаттернов в T-SQL-скриптах — более 140 проверок

НОВОЕ: поддержка форматирования SQL-кода с использованием библиотеки SqlScriptDom

Приводите ваш T-SQL к единообразному и читаемому виду 🍺

👉 @KodBlog

Новинка: HybridCache в .NET наконец-то получил стабильный релиз

HybridCache в ASP.NET Core — новая кэш-библиотека, объединяющая преимущества внутрипроцессного (in-memory) и распределённого кэширования

⏩Узнайте больше: здесь

👉 @KodBlog

Зависимости сетевых протоколов, которые необходимо знать

👉 @KodBlog