Зачем нужны health checks и мониторинг?

Если в приложении что-то ломается - ты должен узнать об этом сразу.

Health checks сокращают цикл обратной связи:

ты получаешь уведомление в ту же секунду, как только что-то пошло не так.

Health checks в ASP.NET Core:

> Реализуешь IHealthCheck
> Кастомные проверки пишутся просто
> Есть готовые проверки из коробки
> Гибко настраиваемый формат ответа
> Можно интегрировать с любым инструментом мониторинга или алертинга

Вот как начать использовать Health Checks: тут 🤨

👉 @KodBlog

Как EF Core стал ближе к Dapper?

Всё благодаря одной фиче:

Сырые SQL-запросы к неотражённым типам (unmapped types).

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

Рекомендуемый способ использования это метод SqlQuery<T> для параметризованных запросов.

Ключевые особенности этой фичи:

> Поддержка представлений , хранимых процедур и функций
> Комбинирование SQL и LINQ в одном запросе
> Защита от SQL-инъекций

В одном из проектов мы внедрили 3 таких запроса в прод, и сразу заметили, что код стал чище и легче в поддержке.

Надеюсь, это поможет и вам в проектах. 😎

👉 @KodBlog

Как заставить код соблюдать архитектурные правила?

Компилятор такие нарушения не поймает. Код-ревью то работает, то нет.

Есть решение получше — архитектурные тесты.

Это автоматические проверки, которые валидируют структуру и дизайн. Пишутся на C#.

С их помощью можно:

• контролировать зависимостями между проектами
• ограничивать связанность между компонентами
• применять нейминг по правилам

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

И помни: архитектура должна ускорять разработку, а не ставить в рамки. 🤠

👉 @KodBlog

Фишка в Visual Studio, которую я использую для преобразования JSON в C# классы:

(никаких онлайн-сервисов не нужно)

Вставить JSON как классы

Скопируйте JSON-объект, а затем просто вставьте его в Visual Studio — и он автоматически сгенерирует C# класс на основе структуры JSON.

Доступно через меню:

Edit -> Paste Special -> Paste JSON as Classes

Работает даже с вложенными объектами.

P.S. Пользовались этим приёмом? 🤨

👉 @KodBlog

Топ 10 ошибок .NET-разработчиков

1. Использовать Blazor вместо React
2. Использовать Azure Functions в serverless-стиле, хотя они все крутятся на одном App Service Plan, и называть это "масштабируемым решением"
3. Писать свой самодельный MVC-фреймворк поверх Minimal APIs ради "структурности", вместо того чтобы просто использовать стандартный MVC
4. Использовать хранимки (stored procedures) для обычных CRUD-операций
5. Называть "юнит-тестами" тесты, которым нужна база данных
6. Использовать AutoMapper
7. Игнорировать Microsoft Orleans при разработке real-time приложений
8. Начинать проект сразу с "микросервисов"
9. Тратить время на gRPC для фронтовых API, которые в итоге всё равно превращаются в JSON, закодированный в base64
10. Использовать Razor Pages вместо MVC

👉 @KodBlog

Забирай мой подход к упрощению управления потоками:

(в .NET 9)

Вместо использования классического System.Threading.Monitor, в .NET 9 появился новый тип — System.Threading.Lock.

Вместе с ним добавлен метод Lock.EnterScope(), который создаёт эксклюзивную область и автоматически освобождает блокировку в конце блока кода.

Этот тип даёт более удобную и безопасную синхронизацию потоков за счёт нового API.

Оператор lock в C# теперь сам распознаёт, если ты передаёшь объект типа Lock.

В этом случае он использует новый API, а не старый Monitor.

Пример кода выше.

Что думаешь об этом обновлении? 🥺

👉 @KodBlog

Вопрос по системному дизайну.

Как бы вы реализовали сервис сокращения ссылок?

У такого сервиса две основные функции:

> Генерация уникального кода для заданного URL

> Редирект пользователей с короткой ссылки на исходный URL

Как бы вы это реализовали на .NET?

Полный разбор системы можно посмотреть здесь 🍿

👉 @KodBlog

Вместо того чтобы:

→ писать огромный метод с 5+ параметрами
→ и продолжать добавлять всё больше новых параметров

Сделай так:

1. Создай новый класс.

2. Его свойства должны соответствовать параметрам метода.

3. Замени параметры метода на один объект нового класса.

4. Обнови все места, где вызывается этот метод.

Этот приём называется Introduce Parameter Object — вынесение параметров в объект.

Он быстро повышает читаемость и поддерживаемость кода.

👉 @KodBlog

LeftJoin будет поддерживаться в Entity Framework 10.

👉 @KodBlog

Каждый разработчик допускал эту ошибку.

Что не так с этим кодом?

На первый взгляд всё кажется логичным:

🔸API-эндпоинт регистрации пользователя вызывает UserService
🔸UserService сохраняет пользователя в базу и вызывает EmailService
🔸EmailService через SmtpClient отправляет письмо

Но если присмотреться, метод SendWelcomeEmail объявлен как async void.

В чём проблема с async void?

Вот суть:
❌ async void делает невозможным отлов исключений.

Если внутри SendEmailAsync() произойдёт исключение — catch его не перехватит.
Вместо этого приложение может тихо упасть или начать вести себя непредсказуемо.

Почему так происходит?

Методы async void не возвращают Task, поэтому вызывающий код не может их await-ить и обрабатывать ошибки.
Исключения из async void проходят мимо стандартных механизмов обработки.

Правильный подход:

✅Всегда возвращай Task

Запомни: async void допустим только для обработчиков событий, где возвращаемый void обязателен.

Ты сталкивался с проблемами из-за async void? Поделись опытом или советами 😳

👉 @KodBlog

😂😂😂

👉 @KodBlog

Как сделать ужасный API-дизайн:

- Возвращай 200 OK с телом {"success": false}

А как лучше?

Используй Problem Details для обработки ошибок в API.

Хотя бы договоритесь в команде о едином формате ответов при ошибках.

Я видел API, которые возвращают 200 OK даже при ошибке в теле (да, это в сторону GraphQL-разработчиков).

Problem Details — это стандарт для описания ошибок в HTTP-ответах.

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

Реализовать Problem Details в .NET — на самом деле просто.

Вот гайд: читать

Как ты обрабатываешь ошибки в своём API?

👉 @KodBlog

Несколько недель назад мне нужно было найти самый маленький документ в списке.

Первая реализация — отсортировать документы по размеру, а потом взять первый элемент.

Решение сработало. Но Rider подсказал более элегантный вариант:

использовать MinBy()

Это метод LINQ, появившийся в .NET 6.

Он упрощает получение минимального элемента из коллекции.

Смотрите пример 👍

👉 @KodBlog

Слой Domain должен отражать бизнес-логику, а не технические детали.

Несколько лет назад я этого не понимал.

В старых проектах у меня структура Domain выглядела так:

🔸Entities
🔸Repositories
🔸ValueObjects
🔸Enumerations
🔸Exceptions

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

Теряется связанность — чтобы понять один use case, приходится скакать по разным папкам.

Сейчас я группирую связанные концепции по фичам, а не по типам.

Что в итоге?

🔸Лучше связанность
🔸Проще навигация
🔸Быстрее онбординг
🔸Код проще поддерживать

👉 @KodBlog

Как защитить приложение от уязвимостей:

(всего в 4 строках кода)

Используйте ASP.NET Core 8 Identity

ASP.NET Core 8 Identity вводит новые API, упрощающие реализацию входа и управление учетными записями.

С минимальными усилиями вы можете защитить Web API, добавив аутентификацию и авторизацию.

После быстрой настройки (всего в несколько строк кода) вы автоматически получаете готовые эндпоинты для:

✅двухфакторной аутентификации
✅входа в систему
✅регистрации
✅сброса пароля
✅подтверждения email

Безопасность это не то, что стоит реализовывать с нуля самостоятельно.

Выше пример, как это настроить

👉 @KodBlog

Одна из полезных фич — collection expressions.

С ними:

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

Фича небольшая, но сильно улучшает читаемость.
Если не пробовал, стоит глянуть. 🎧

Посмотри, как это работает + ещё 8 советов по чистому коду: читать

👉 @KodBlog

Если ты всё ещё пишешь фабрики в 2025 — ты оверинжинириш.

В .NET 8 появились Keyed Services более чистый и быстрый способ разрешать зависимости с минимумом шаблонного кода.

✅Без кастомных фабрик
✅Без if-else или switch
✅Нативная поддержка в DI-контейнере

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

Без лишнего кода. Без лишней абстракции. Просто чистый DI.

👉 @KodBlog

Dapper быстрый, но отображение отношений "один ко многим" может вызвать проблемы.

В чём проблема?

SQL-join возвращает дублированные данные с "одной" стороны, а Dapper отдаёт по одной строке за раз.

Как решить?

Используйте Dictionary<TKey, TEntity>, чтобы отслеживать и повторно использовать родительские объекты при добавлении дочерних элементов.

Это просто, как только вы освоите шаблон.

Вот чистый пример: ссылка на статью

Вы сталкивались с этой проблемой при использовании Dapper? 🥰

👉 @KodBlog

Как перестать усложнять проверки типов:

(и назначать переменные с ненулевыми значениями)

Используйте шаблон объявления (declaration pattern).

Шаблон объявления позволяет проверить, совместим ли тип выражения во время выполнения с указанным типом.

Также можно объявить локальную переменную как результат этой проверки.

Пример использования шаблона объявления в коде выше.

👉 @KodBlog

Хватит загружать строки в память только ради их удаления.

В EF Core теперь есть поддержка массового удаления через ExecuteDelete().

- Пиши LINQ-запрос для фильтрации записей
- Чейни несколько Where-условий
- Вызывай ExecuteDelete(), чтобы выполнить один SQL DELETE

Без трекинга, без материализации. Только SQL.

👉 Как это использовать (и на что стоит обратить внимание) — читать

Ты уже используешь массовое удаление (или обновление) в своих проектах?

👉 @KodBlog