📦 Всё ещё не используешь Central Package Management в .NET?
Открой свой
Пакеты обычно выглядят так:
<PackageReference Include="Serilog" Version="4.3.0" />
<PackageReference Include="WolverineFx" Version="5.6.0" />
И в итоге проект превращается в мусорку из версий.
А теперь представь, что это будет так:
<PackageReference Include="Serilog" />
<PackageReference Include="WolverineFx" />
Вот в этом и кайф Central Package Management.
Что он даёт:
✅
✅ никто случайно не поставит “левую” версию пакета
✅ вся команда работает на одинаковых версиях библиотек
✅ сборка становится предсказуемой и детерминированной
Как работает:
Ты управляешь версиями централизованно через файл
То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version.
Если у тебя монорепа или несколько проектов - это must-have.
Открой свой
.csproj прямо сейчас.Пакеты обычно выглядят так:
<PackageReference Include="Serilog" Version="4.3.0" />
<PackageReference Include="WolverineFx" Version="5.6.0" />
И в итоге проект превращается в мусорку из версий.
А теперь представь, что это будет так:
<PackageReference Include="Serilog" />
<PackageReference Include="WolverineFx" />
Вот в этом и кайф Central Package Management.
Что он даёт:
✅
.csproj становится чистым и читаемым ✅ никто случайно не поставит “левую” версию пакета
✅ вся команда работает на одинаковых версиях библиотек
✅ сборка становится предсказуемой и детерминированной
Как работает:
Ты управляешь версиями централизованно через файл
Directory.Packages.props в корне репозитория.То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version.
Если у тебя монорепа или несколько проектов - это must-have.
$ ls -a
А как смотрю я:
$ echo */ *. *
Этот трюк выводит всё “простым” способом через glob-расширение:
- */ покажет папки
- * покажет обычные файлы
- .* покажет скрытые файлы
Плюс это удобно тем, что результат можно сразу передавать дальше в команды, не парся вывод ls.
Please open Telegram to view this post
VIEW IN TELEGRAM
Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️
Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу.
Идея простая:
Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат.
Что происходит в примере:
— В DI регистрируется Resilience Pipeline
— Добавляется FallbackStrategy
— Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения
Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline:
pipeline.ExecuteAsync(...)
И если API:
❌ упало
❌ вернуло ошибку
❌ словило таймаут
Пользователь не увидит 500. Он получит контролируемый ответ.
Это особенно важно для:
- внешних API
- микросервисов
- нестабильных сетей
- интеграций с SaaS
Fallback — это не про «скрыть ошибку».
Это про graceful degradation, когда система продолжает жить даже при частичных сбоях.
Надёжность — это архитектура, а не try/catch в каждом методе.
#dotnet #backend #architecture
Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу.
Идея простая:
Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат.
Что происходит в примере:
— В DI регистрируется Resilience Pipeline
— Добавляется FallbackStrategy
— Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения
Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline:
pipeline.ExecuteAsync(...)
И если API:
❌ упало
❌ вернуло ошибку
❌ словило таймаут
Пользователь не увидит 500. Он получит контролируемый ответ.
Это особенно важно для:
- внешних API
- микросервисов
- нестабильных сетей
- интеграций с SaaS
Fallback — это не про «скрыть ошибку».
Это про graceful degradation, когда система продолжает жить даже при частичных сбоях.
Надёжность — это архитектура, а не try/catch в каждом методе.
#dotnet #backend #architecture
🏗️ Пытаться вытаскивать микросервисы из “спагетти-монолита” - почти всегда плохая идея.
Вместо красивой архитектуры ты получишь распределённую кашу, ещё больше зависимостей, ошибок и боли при поддержке.
Самый безопасный путь миграции - паттерн Strangler Fig:
выносить функциональность по кускам, постепенно “замещая” монолит.
Но есть важное условие:
сначала нужно привести систему к Modular Monolith.
То есть:
- чётко выделить границы модулей
- изолировать данные
- оставить только чистые публичные API для общения между модулями
И только после этого выбирать, какой модуль выносить первым.
Как выбрать правильного кандидата на первый микросервис?
Ищи 4 “зелёных флага”:
1) Low Coupling - минимум зависимостей от других модулей
2) High Cohesion - логика внутри модуля максимально связная и цельная
3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”)
4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе
Если модуль соответствует этим критериям - его можно вынести относительно безопасно,
не превращая архитектуру в распределённый хаос.
Вместо красивой архитектуры ты получишь распределённую кашу, ещё больше зависимостей, ошибок и боли при поддержке.
Самый безопасный путь миграции - паттерн Strangler Fig:
выносить функциональность по кускам, постепенно “замещая” монолит.
Но есть важное условие:
сначала нужно привести систему к Modular Monolith.
То есть:
- чётко выделить границы модулей
- изолировать данные
- оставить только чистые публичные API для общения между модулями
И только после этого выбирать, какой модуль выносить первым.
Как выбрать правильного кандидата на первый микросервис?
Ищи 4 “зелёных флага”:
1) Low Coupling - минимум зависимостей от других модулей
2) High Cohesion - логика внутри модуля максимально связная и цельная
3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”)
4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе
Если модуль соответствует этим критериям - его можно вынести относительно безопасно,
не превращая архитектуру в распределённый хаос.
Что выведет на экран этот код?
Anonymous Quiz
5%
False False
31%
False True
31%
True True
5%
True False
21%
Возникнет исключение при обращении к disposed структуре.
8%
⚡️ 10 причин перейти на .NET 10 (чтобы это одобрил руководитель)
.NET 10 и C# 14 вышли 11 ноября 2025. Ниже - 10 причин, почему апгрейд реально стоит запланировать.
1) LTS-релиз
- .NET 10 - Long-Term Support, поддержка до 14 ноября 2028
- поддержка .NET 8 заканчивается 10 ноября 2026 → лучше не тянуть
2) Быстрее ASP.NET Core
- до +15% RPS по сравнению с .NET 8
- до -93% потребления памяти → меньше нагрузка и дешевле инфраструктура
3) Общий прирост производительности .NET
- сотни улучшений “из коробки” просто после апгрейда проекта
4) File-Based Apps (один .cs файл)
- можно сделать один файл *.cs и запускать напрямую
- удобно для CLI, автоматизации и утилит без создания проекта
5) Server-Sent Events (SSE)
- лёгкий способ стримить данные на клиента
- идеален для real-time обновлений без сложности WebSocket
6) Extension Members в C# 14
- более удобный синтаксис расширений
- можно расширять свойства и static members
7) Minimal APIs: Validation + JSON Patch
- встроенная валидация для Minimal APIs
- JSON Patch доступен из коробки
8) EF 10: LeftJoin / RightJoin в LINQ
- наконец-то нормальные LeftJoin/RightJoin
- запросы становятся проще и читаемее
9) EF 10: Named Query Filters
- можно заводить несколько фильтров на одну сущность
- включать/выключать их независимо
10) Улучшения Blazor
- Hot Reload для Blazor WASM и .NET on WASM
- профилирование производительности + диагностические счётчики
Источник/подробности:
antondevtips.com/draft/10-reasons-to-upgrade-to-dotnet-10/
.NET 10 и C# 14 вышли 11 ноября 2025. Ниже - 10 причин, почему апгрейд реально стоит запланировать.
1) LTS-релиз
- .NET 10 - Long-Term Support, поддержка до 14 ноября 2028
- поддержка .NET 8 заканчивается 10 ноября 2026 → лучше не тянуть
2) Быстрее ASP.NET Core
- до +15% RPS по сравнению с .NET 8
- до -93% потребления памяти → меньше нагрузка и дешевле инфраструктура
3) Общий прирост производительности .NET
- сотни улучшений “из коробки” просто после апгрейда проекта
4) File-Based Apps (один .cs файл)
- можно сделать один файл *.cs и запускать напрямую
- удобно для CLI, автоматизации и утилит без создания проекта
5) Server-Sent Events (SSE)
- лёгкий способ стримить данные на клиента
- идеален для real-time обновлений без сложности WebSocket
6) Extension Members в C# 14
- более удобный синтаксис расширений
- можно расширять свойства и static members
7) Minimal APIs: Validation + JSON Patch
- встроенная валидация для Minimal APIs
- JSON Patch доступен из коробки
8) EF 10: LeftJoin / RightJoin в LINQ
- наконец-то нормальные LeftJoin/RightJoin
- запросы становятся проще и читаемее
9) EF 10: Named Query Filters
- можно заводить несколько фильтров на одну сущность
- включать/выключать их независимо
10) Улучшения Blazor
- Hot Reload для Blazor WASM и .NET on WASM
- профилирование производительности + диагностические счётчики
Источник/подробности:
antondevtips.com/draft/10-reasons-to-upgrade-to-dotnet-10/
Если Module A может “по-тихому” лезть в базу Module B - у тебя не модули.
У тебя хаос, просто внутри одного репозитория.
Самое сложное в модульной архитектуре - не “разбить на папки”, а решить, что модуль вообще имеет право показывать наружу.
Моё правило для Public API:
1) Начинай с нуля
Считай, что любой класс должен быть приватным по умолчанию.
2) Открывай только по необходимости
Доступ даётся не “на будущее”, а только если другой модуль реально просит функциональность.
3) Экспортируй возможности, а не данные
API должно отражать сценарии (use-cases), а не “вот тебе таблица/репозиторий/DTO”.
И главное - просто договориться недостаточно.
Границы нужно технически запрещать нарушать: модификаторы, сборки, internal, анализаторы, тесты на зависимости.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если вы не используете OpenTelemetry, вы буквально летите вслепую в продакшене.
И хорошая новость — вам не нужно переписывать код, чтобы получить “рентген-зрение” для своих сервисов.
Достаточно подключить правильные пакеты авто-инструментирования.
Вот базовый стартовый набор для .NET:
- AspNetCore — автоматически трейсит все входящие HTTP-запросы
- HttpClient — показывает тайминги и статусы всех исходящих API-вызовов
- EF Core — логирует реальные SQL-запросы и их длительность
- Npgsql — добавляет глубокий трейсинг для PostgreSQL
- StackExchange.Redis — помогает увидеть cache hits, misses и скачки латентности
После установки вы начинаете видеть полный жизненный цикл запроса через все микросервисы — от входящего HTTP до базы, кэша и внешних API.
Это уже не “логи и надежда”.
Это наблюдаемость продакшен-уровня.
Я разобрал, как всё это подключить к Grafana или Jaeger и получить полноценную визуализацию трейсов.
Полный гайд по настройке:
https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet?utm_source=X&utm_medium=social&utm_campaign=19.01.2026
И хорошая новость — вам не нужно переписывать код, чтобы получить “рентген-зрение” для своих сервисов.
Достаточно подключить правильные пакеты авто-инструментирования.
Вот базовый стартовый набор для .NET:
- AspNetCore — автоматически трейсит все входящие HTTP-запросы
- HttpClient — показывает тайминги и статусы всех исходящих API-вызовов
- EF Core — логирует реальные SQL-запросы и их длительность
- Npgsql — добавляет глубокий трейсинг для PostgreSQL
- StackExchange.Redis — помогает увидеть cache hits, misses и скачки латентности
После установки вы начинаете видеть полный жизненный цикл запроса через все микросервисы — от входящего HTTP до базы, кэша и внешних API.
Это уже не “логи и надежда”.
Это наблюдаемость продакшен-уровня.
Я разобрал, как всё это подключить к Grafana или Jaeger и получить полноценную визуализацию трейсов.
Полный гайд по настройке:
https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet?utm_source=X&utm_medium=social&utm_campaign=19.01.2026
This media is not supported in your browser
VIEW IN TELEGRAM
🟥 Утечки данных в .NET-приложениях чаще происходят не из-за хакеров, а из-за неверной работы с ключами, конфигурациями и базовой криптографией. Ошибки на уровне кода быстро превращаются в инциденты.
На открытом уроке разберём практическое применение System.Security.Cryptography: AES, RSA, хеширование и цифровые подписи. Поговорим о безопасном хранении и передаче секретов, управлении ключами и принципе наименьших привилегий.
❗️ Вы системно разберёте уязвимости OWASP Top-10 для .NET: инъекции, небезопасную десериализацию, XSS, CSRF — и способы их нейтрализации на уровне кода и архитектуры. Отдельно обсудим шифрование данных в БД, защиту строк подключения и безопасное логирование без утечек токенов.
🟥Встречаемся 10 февраля в 20:00 МСК в преддверии старта курса «C# Developer. Professional».
Зарегистрируйтесь, чтобы не пропустить: https://tglink.io/73e7493a7d6ff1?erid=2W5zFGXFxba
#реклама
О рекламодателе
На открытом уроке разберём практическое применение System.Security.Cryptography: AES, RSA, хеширование и цифровые подписи. Поговорим о безопасном хранении и передаче секретов, управлении ключами и принципе наименьших привилегий.
❗️ Вы системно разберёте уязвимости OWASP Top-10 для .NET: инъекции, небезопасную десериализацию, XSS, CSRF — и способы их нейтрализации на уровне кода и архитектуры. Отдельно обсудим шифрование данных в БД, защиту строк подключения и безопасное логирование без утечек токенов.
🟥Встречаемся 10 февраля в 20:00 МСК в преддверии старта курса «C# Developer. Professional».
Зарегистрируйтесь, чтобы не пропустить: https://tglink.io/73e7493a7d6ff1?erid=2W5zFGXFxba
#реклама
О рекламодателе
🔥 Полезная подборка каналов только код, практика и самые передовые инструменты, которые используют разработчики прямо сейчас.👇
🖥 C#: t.me/csharp_1001_notes
🖥 ИИ: t.me/ai_machinelearning_big_data
🖥 Python: t.me/pythonl
🖥 Linux: t.me/linuxacademiya
🖥 C++ t.me/cpluspluc
🖥 Docker: t.me/DevopsDocker
🖥 Хакинг: t.me/linuxkalii
🖥 Devops: t.me/DevOPSitsec
👣 Golang: t.me/Golang_google
🖥 Аналитика: t.me/data_analysis_ml
🖥 Javascript: t.me/javascriptv
🖥 Java: t.me/javatg
🖥 Базы данных: t.me/sqlhub
👣 Rust: t.me/rust_code
🤖 Технологии: t.me/vistehno
💰 Экономика и инвестиции в ИИ t.me/financeStable
💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi
🖥 Chatgpt бот в тг: t.me/Chatgpturbobot
📚 Бесплатные ит-книги: https://t.me/addlist/HwywK4fErd8wYzQy
🖥 Подборка по Golang: https://t.me/addlist/MUtJEeJSxeY2YTFi
⚡️ Лучшие ИИ ресурсы: https://t.me/addlist/2Ls-snqEeytkMDgy
Самое лучшее в этом: ты учишься даже тогда, когда “нет времени, просто потому что читаешь правильную ленту.
💰 Экономика и инвестиции в ИИ t.me/financeStable
💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi
📚 Бесплатные ит-книги: https://t.me/addlist/HwywK4fErd8wYzQy
⚡️ Лучшие ИИ ресурсы: https://t.me/addlist/2Ls-snqEeytkMDgy
Самое лучшее в этом: ты учишься даже тогда, когда “нет времени, просто потому что читаешь правильную ленту.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если вы думаете, что EF Core «медленный» в 2026 — вы просто живёте в прошлом.
Одна из мощных современных фич — bulk-операции, в том числе массовое удаление.
Теперь можно удалить любое количество записей одним запросом к базе.
Пример: e-commerce платформа хочет удалить все корзины, созданные более года назад. Раньше это выглядело так: загрузили сущности в память, RemoveRange, SaveChanges — лишние аллокации, трафик и нагрузка.
Теперь достаточно:
В результате выполняется один SQL DELETE, который напрямую удаляет старые записи в базе — быстро и без промежуточных объектов в памяти.
⚠️ Важно: bulk-операции обходят change tracker EF. Если в контексте уже есть отслеживаемые сущности, состояние может рассинхронизироваться — учитывайте это в логике.
EF Core давно уже не просто ORM, а полноценный инструмент для высоконагруженных систем. И у него есть ещё много фич, которые серьёзно упрощают жизнь разработчику.
Подробнее
Одна из мощных современных фич — bulk-операции, в том числе массовое удаление.
Теперь можно удалить любое количество записей одним запросом к базе.
Пример: e-commerce платформа хочет удалить все корзины, созданные более года назад. Раньше это выглядело так: загрузили сущности в память, RemoveRange, SaveChanges — лишние аллокации, трафик и нагрузка.
Теперь достаточно:
context.Carts
.Where(o => o.CreatedOn < DateTime.Now.AddYears(-1))
.ExecuteDelete();
В результате выполняется один SQL DELETE, который напрямую удаляет старые записи в базе — быстро и без промежуточных объектов в памяти.
⚠️ Важно: bulk-операции обходят change tracker EF. Если в контексте уже есть отслеживаемые сущности, состояние может рассинхронизироваться — учитывайте это в логике.
EF Core давно уже не просто ORM, а полноценный инструмент для высоконагруженных систем. И у него есть ещё много фич, которые серьёзно упрощают жизнь разработчику.
Подробнее
This media is not supported in your browser
VIEW IN TELEGRAM
👨💻 Ручная сборка, деплой по инструкции в Confluence и ночные правки на сервере — частая реальность ASP.NET-проектов. Пока система доставки не автоматизирована, скорость разработки и стабильность всегда под угрозой.
На открытом уроке разберём, как выстроить рабочий pipeline от коммита до деплоя. Покажем типовую цепочку: сборка, тесты, упаковка в Docker-образ, публикация в реестр и автоматическое развертывание.
❗️ Вы увидите CI/CD не как абстрактную DevOps-теорию, а как воспроизводимый процесс, который можно применить в собственном проекте. Это фундамент для перехода к микросервисам и контейнерной инфраструктуре без лишней сложности.
🗓 Встречаемся 11 февраля в 20:00 МСК в преддверии старта курса «C# ASP.NET Core-разработчик».
➡️ Регистрация открыта: https://tglink.io/3e020aa35caaf6?erid=2W5zFGkbWek
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
#реклама
О рекламодателе
На открытом уроке разберём, как выстроить рабочий pipeline от коммита до деплоя. Покажем типовую цепочку: сборка, тесты, упаковка в Docker-образ, публикация в реестр и автоматическое развертывание.
❗️ Вы увидите CI/CD не как абстрактную DevOps-теорию, а как воспроизводимый процесс, который можно применить в собственном проекте. Это фундамент для перехода к микросервисам и контейнерной инфраструктуре без лишней сложности.
🗓 Встречаемся 11 февраля в 20:00 МСК в преддверии старта курса «C# ASP.NET Core-разработчик».
➡️ Регистрация открыта: https://tglink.io/3e020aa35caaf6?erid=2W5zFGkbWek
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
#реклама
О рекламодателе
В .NET всё настраивается один раз через
IHttpClientFactory (и Aspire, если используешь его):• Service discovery для service-to-service вызовов
• Встроенная устойчивость к сбоям (retry, handling transient errors)
После этого ты просто инжектишь клиент и пишешь бизнес-логику — без ручной магии с сокетами, таймаутами и DNS.
Чистый код. Меньше багов. Больше фокуса на логике.
Полный разбор
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Научитесь создавать AI-проекты и зарабатывать на них
🦾🦾 Сегодня ценится не умение «пользоваться ChatGPT», а навык проектировать и запускать полноценные AI-решения под реальные задачи бизнеса
🤖 Университет искусственного интеллекта - один из самых крупных образовательных проектов в сфере AI:
7 лет на рынке, более 11 000 студентов, практические программы и стажировки в реальных компаниях
🔥🔥 Сейчас открыт доступ к презентации программы GPT Engineer - обучения, где показывают путь от базы до разработки AI-приложений и сервисов
Что вы узнаете из презентации:
🔹 Программа курса по занятиям
🔹 Необходимый уровень для поступления
🔹 Тарифы и цены
🔹 Описание формата практики на стажировках
🔹 Обзор процесса трудоустройства
🔹 Разбор программы поддержки студентов
👉 Если планируете развиваться в сфере искусственного интеллекта или хотите перейти в новую востребованную профессию - обязательно посмотрите презентацию
🦾🦾 Сегодня ценится не умение «пользоваться ChatGPT», а навык проектировать и запускать полноценные AI-решения под реальные задачи бизнеса
🤖 Университет искусственного интеллекта - один из самых крупных образовательных проектов в сфере AI:
7 лет на рынке, более 11 000 студентов, практические программы и стажировки в реальных компаниях
🔥🔥 Сейчас открыт доступ к презентации программы GPT Engineer - обучения, где показывают путь от базы до разработки AI-приложений и сервисов
Что вы узнаете из презентации:
🔹 Программа курса по занятиям
🔹 Необходимый уровень для поступления
🔹 Тарифы и цены
🔹 Описание формата практики на стажировках
🔹 Обзор процесса трудоустройства
🔹 Разбор программы поддержки студентов
👉 Если планируете развиваться в сфере искусственного интеллекта или хотите перейти в новую востребованную профессию - обязательно посмотрите презентацию
Вы регистрируете пользователя и сразу вызываете внешние сервисы:
- сохраняете пользователя в БД
- отправляете welcome-email
- публикуете событие в event bus
public async Task RegisterUserAsync(User user, CancellationToken token)
{
_userRepository.Insert(user);
await _unitOfWork.SaveChangesAsync(token);
await _emailService.SendWelcomeEmailAsync(user, token);
await _eventBus.PublishAsync(new UserRegisteredEvent(user.Id), token);
}
Вопрос
Что здесь может пойти не так?
Проблемы
— Пользователь сохранён, но email не отправился
— Email отправился, но событие не опубликовалось
— Событие ушло, а транзакция в БД откатилась
— При ретраях возможны дубли
Чем больше внешних вызовов, тем больше точек отказа и сложнее обработка ошибок.
Решение — Outbox Pattern
Сохраняем пользователя и событие в одной атомарной транзакции:
public async Task RegisterUserAsync(User user, CancellationToken token)
{
_userRepository.Insert(user);
_outbox.Insert(new UserRegisteredEvent(user.Id));
await _unitOfWork.SaveChangesAsync(token);
}
Дальше отдельный процесс:
• читает сообщения из Outbox
• отправляет email
• публикует события
• помечает как обработанные
Результат
— Нет рассинхронизации между БД и внешними сервисами
— Гарантированная доставка событий
— Возможность безопасных повторов
— Простая и надёжная архитектура для распределённых систем
Please open Telegram to view this post
VIEW IN TELEGRAM