Какой синтаксис мокинг-библиотеки для dotnet вам больше по душе из примеров выше?

Moq?
NSubstitute?
FakeItEasy?

и какой библиотекой вы пользуетесь сами и почему? 🤵

👉 @KodBlog

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

1. C4 Model
↳ Удобная для разработчиков модель визуализации архитектуры на 4 уровнях: Контекст, Контейнер, Компонент, Код.
🔸icepanel.io или structurizr.com

2. draw.io
↳ Бесплатный open-source веб-инструмент для создания диаграмм. Интегрируется с облачными хранилищами.
🔸drawio.com

3. PlantUML
↳ Текстовый движок для генерации UML и других диаграмм из кода. Идеален для git‑флоу.
🔸plantuml.com

4. Mermaid
↳ Markdown-подобный синтаксис для рендеринга блок-схем, последовательностей и т.д.
🔸mermaid.js.org

5. Excalidraw
↳ Open-source инструмент для совместного рисования в стиле "от руки".
🔸excalidraw.com

6. mingrammer/diagrams
↳ Библиотека на Python: "диаграммы как код". Позволяет описывать cloud-инфраструктуру кодом.
🔸GitHub

7. Archimate
↳ Стандартизированный язык моделирования enterprise-архитектуры.
🔸archimatetool.com

8. Miro
↳ Онлайн-доска для совместной работы: брейншторминг, диаграммы и не только.
🔸miro.com

9. Lucidchart
↳ Облачный инструмент с умными функциями: AI-диаграммы, схемы архитектуры и т.д.
🔸lucidchart.com

10. CloudSkew
↳ Онлайн-редактор с иконками AWS/Azure/GCP/K8s. Идеален для визуализации облачной архитектуры.
🔸cloudskew.com

11. D2
↳ Декларативный язык диаграмм, превращающий текст в структурированные визуализации, подходящие для версионирования.
🔸d2lang.com

12. Cloudcraft
↳ Заточен под диаграммы архитектуры AWS и Azure.
🔸cloudcraft.co

Что бы ты ещё добавил? 🧠

👉 @KodBlog

Большинство разработчиков неправильно понимают DDD.

Они изучают паттерны (Aggregates, Repositories, Value Objects) и применяют их вслепую.

Но суть DDD — не в паттернах, а в глубоком понимании домена.

Я сам совершал эту ошибку на старте. Помогли не паттерны, а выравнивание с бизнесом.

Главная сложность — коммуникация.

Разные команды называли одно и то же по-разному. Всё изменилось, когда мы построили общий язык.

Истинная ценность DDD:

🔸Общее понимание
🔸Чёткая терминология
🔸Точные модели

После 6+ лет работы вот мой совет:

🔸Разговаривай с бизнесом

🔸Учись говорить на их языке

🔸Моделируй то, что действительно важно

Паттерны тебя не спасут. Поможет только понимание.

И нет, DDD — это не архитектура.

А вот архитектура: клик

А как ты подходишь к DDD? 🫥

👉 @KodBlog

Работать с HTTP-заголовками это сложно?

Короткий ответ: нет. И вот почему

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

Это дополнительные данные, передаваемые вместе с запросом или ответом, которые содержат метаинформацию о сообщении.

Заголовки делятся на 4 группы по контексту:

🔸Request headers (заголовки запроса)
🔸Response headers (заголовки ответа)
🔸Representation headers (информация о формате представления)
🔸Payload headers (сведения о теле запроса/ответа)

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

Добавить заголовки в HTTP-запрос можно двумя способами:

🔸Добавить ко всем запросам
🔸Добавить только к конкретному запросу

Если нужно извлечь значение из заголовка , это тоже делается просто.

Оба сценария реализуются достаточно прямолинейно.

HTTP-заголовки повсеместны в современных веб-приложениях, поэтому важно придерживаться лучших практик:

🔸Использовать лаконичные и понятные заголовки
🔸Настраивать кэширование через заголовки (Cache-Control, ETag)
🔸Учитывать CORS (Access-Control-Allow-Origin)
🔸Обеспечивать безопасность уже на уровне заголовков (Strict-Transport-Security, Content-Security-Policy и др.)

👉 @KodBlog

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

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

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

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

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

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

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

👉 @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