Не засоряй код лишним

До сих пор иногда вижу, как разработчики так делают.

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

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

А теперь посмотри на второй фрагмент — определение и использование стали гораздо чище и понятнее, верно?

Запомни: хороший код задаёт контекст один раз, на нужном уровне абстракции.

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

👉 @KodBlog

EF Core медленный.
ТАКЖЕ ОНИ -> Используют EF Core, чтобы вернуть:

> 25 полей из таблицы,
> 1 000 000 строк за раз,
> включая данные из всех связанных таблиц.

Лучшая оптимизация производительности — это научиться правильно пользоваться инструментами

👉 @KodBlog

Как создать собственную социальную сеть на .NET

Это отличный проект для самостоятельной реализации. 🤓

Базовая реализация платформы может включать следующие сущности:

↳ Пользователи

↳ Посты и категории

↳ Лайки и комментарии

↳ Лента

↳ Уведомления

Рассмотрим реальный кейс:

Пользователь открывает сайт соцсети и видит:

↳ Ленту с актуальными постами

↳ Свои собственные публикации

↳ Уведомления о новых постах, комментариях и лайках к интересующим его записям

Типичное frontend-приложение делает три отдельных запроса к серверу:

Получение ленты

GET /api/feed?userId=1&count=10

Получение уведомлений

GET /api/notifications?userId=1&count=10

Получение постов пользователя

GET /api/users/1/posts?count=10

У этой реализации два ключевых недостатка:

❌Клиенту приходится делать три отдельных запроса к серверу

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

Решение — GraphQL

GraphQL был создан как альтернатива REST, чтобы решить эти проблемы.

Hot Chocolate это самый эффективный и функциональный open-source GraphQL-сервер в экосистеме .NET. Он позволяет легко строить масштабируемые GraphQL API и шлюзы.

Преимущества Hot Chocolate по сравнению с REST API:

✅Клиент сам выбирает, какие поля ему нужны — никакого overfetch/underfetch
✅Все данные можно запросить одним запросом, без лишних round-trip’ов
✅Автогенерация документации, генерация кода и автодополнение в IDE синхронизируют frontend и backend
✅Встроенные фильтрация, сортировка и пагинация — middleware всё берёт на себя, причём делает это лучше и проще, чем OData
✅Интерфейс Nitro GraphQL позволяет визуально исследовать типы, собирать запросы и тестировать их за секунды

Я использую Hot Chocolate GraphQL в продакшене уже более трёх лет, и это сильно прокачало мои подходы к построению API.

Автор собрал простую реализацию социальной сети на базе Hot Chocolate GraphQL, и сегодня поделился пошаговой инструкцией с разработчиками, как сделать это правильно с учётом best practices.

Исходный код доступен бесплатно.

👉 @KodBlog

Как обезопасить свой API?

Вот 5 рекомендаций, которые помогут:

→ Используйте надёжную аутентификацию и авторизацию
→ Валидируйте входные данные и экранируйте выходные
→ Настройте ограничение частоты запросов
→ Шифруйте весь трафик
→ Обеспечьте наблюдаемость

👉 @KodBlog

Жизнь коротка, используй библиотеки .NET

Вот список популярных библиотек, которые стоит рассмотреть:

1. ORM
- EF Core
- Dapper ORM

2. Инструменты для API
- SignalR
- FluentValidation
- MediatR
- YARP

3. Тестирование
- xUnit
- Testcontainers
- FluentAssertions
- Moq
- Verify

4. Логирование и мониторинг
- Serilog
- NLog
- OpenTelemetry

5. Внедрение зависимостей (DI)
- Autofac
- Scrutor

6. Фоновая обработка
- Hangfire
- Quartz .NET

7. Работа с HTTP
- Polly
- RestSharp
- Refit

8. Работа с Office-документами
- ClosedXML
- EPPlus
- Excel-DNA

9. Аутентификация и авторизация
- Microsoft.AspNetCore.Identity
- openiddict
- Keycloak

10. Очереди и брокеры сообщений
- RabbitMQ
- MassTransit
- NServiceBus

P.S. А ты бы какую библиотеку добавил? 🥰

👉 @KodBlog

Изменение стандартного представления класса в режиме отладки

К сведению: мы можем изменить стандартное отображение класса в отладчике C# с помощью атрибута DebuggerDisplay

👉 @KodBlog

Зачем нужны 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