C# Portal | Программирование – Telegram
C# Portal | Программирование
14.9K subscribers
968 photos
118 videos
24 files
811 links
Присоединяйтесь к нашему каналу и погрузитесь в мир для C#-разработчика

Связь: @devmangx

РКН: https://clck.ru/3FocB6
Download Telegram
Что такое JSON Web Token (JWT)?

JWT — это компактный, безопасный для передачи по URL токен, предназначенный для безопасной передачи информации между двумя сторонами — обычно между клиентом и сервером.

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

JWT выглядит так: xxxxx.yyyyy.zzzzz

Он состоит из трёх частей:

🔸Header: указывает тип токена и алгоритм подписи (например, HMAC или RSA)
🔸Payload: содержит claims — данные о пользователе, такие как userId, role и т. д.
🔸Signature: используется для проверки подлинности отправителя и гарантирует, что токен не был изменён

Как это работает:

1. Пользователь входит в систему, вводя логин и пароль.
2. Сервер проверяет учётные данные и генерирует JWT.
3. Сервер отправляет токен обратно клиенту.
4. Клиент сохраняет токен (обычно в localStorage или в cookie).
5. При последующих запросах клиент добавляет JWT в заголовок Authorization

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍11🔥42👏2🐳1
Одна из самых недооценённых возможностей HttpClient?

DelegatingHandler — это middleware для исходящих HTTP-запросов.

Идеально подходит для реализации сквозной логики, такой как:

➣ Аутентификация
➣ Логирование
➣ Аудит
➣ Кэширование
➣ Повторные попытки (Retries)

Вместо того чтобы дублировать этот код в каждом запросе — оформляется единый чистый pipeline.

Вот как использовать DelegatingHandler в .NET

А ты как обрабатываешь сквозную HTTP-логику в своих проектах? 📝

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
8👍4
Исключения это Goto-команды современного .NET-разработчика. 😊
(И это не комплимент)

Многие разработчики выбрасывают исключения как способ по умолчанию для управления поведением приложения.

Но вот в чём проблема:

➣ Они ломают поток выполнения программы.
➣ Заставляют каждый вызывающий код оборачивать логику в try-catch (иначе — падение).
➣ И что хуже всего — при чрезмерном использовании могут влиять на производительность.

Что использовать вместо?

Паттерн Result


Вместо выбрасывания исключения метод возвращает объект-результат, который явно указывает на успех или неудачу.

Плюсы:

Без неожиданностей
Без скрытых переходов
Предсказуемый, читаемый контроль потока

Совершенен ли этот подход? Нет.

Он может показаться многословным, и в C# пока нет нативной поддержки.

Но он даёт чёткость и явность в обработке ошибок.

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

Можно продолжать:

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

Или можно использовать Result pattern:

– проектировать поведение на случай ошибок заранее
– явно различать успех и неудачу

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
1🤨97👍6
This media is not supported in your browser
VIEW IN TELEGRAM
Проект дня: переиспользуемый пайплайн деплоя, написанный на C#, который может взять любой проект на Aspire и задеплоить его на виртуальную машину через SSH и Docker.

➟ Использование C# >>>> shell-скрипты, вперемешку с YAML 🤮
➟ Код пайплайна работает поверх модели. Один и тот же код подходит для любого Aspire-приложения без изменений. Это динамический шаблон пайплайна.
➟ Может запускаться локально или в CI
➟ Построено на новых API, которые появятся в Aspire 9.4 (ты тоже можешь собрать свой пайплайн и задеплоить куда угодно!)

https://github.com/davidfowl/AspirePipelines

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
This media is not supported in your browser
VIEW IN TELEGRAM
Тестировать API, не выходя из VS Code? Да, пожалуйста.

Новое расширение Postman для VS Code переносит разработку API прямо в IDE

Что оно умеет:

➣ Отправка HTTP-, WebSocket- и gRPC-запросов прямо из VS Code
➣ Совместное использование тестовых скриптов через коллекции Postman
➣ Импорт .env-файлов без ручного ввода переменных
➣ Отладка эндпоинтов рядом с кодом, в одном окне

Попробовать можно здесь:

🔸https://fnf.dev/44C6rRm

А вот ещё пара обновлений от Postman, которые стоит заценить:

Интеграция с Jira Cloud

Падаешь на 500-ке при вызове API?

Создавай баг-репорты в Jira за один клик — без переключения между тулзами:

➣ Быстрое создание задач из упавших запросов
➣ Автоматически прикладываются заголовки, токены, тело запроса и ответ
➣ Добавляются конфигурация окружения и шаги воспроизведения

👉 https://fnf.dev/3THdIZM

Интеграция с GitHub

Держи API-спеки и исходники в синхронизации:

➣ Автокоммит коллекций в репозиторий
➣ Просмотр изменений в API рядом с кодом в pull request
➣ Прогон тестов в CI на тех же коллекциях, с которыми работает команда

Подробнее: https://fnf.dev/4l2905d

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3
Использование nameof вместо ToString() при обращении к имени члена перечисления в .NET — это абсолютно валидная техника оптимизации производительности.

В этом нет ничего надуманного, даже ReSharper содержит инспекцию на этот случай. nameof выносит получение строки в compile-time, тем самым существенно снижает время выполнения и устраняет аллокации — что особенно важно в производительно-критичных hot-path'ах

Reddit тред -> ссылка

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍62🤔1🥴1
Вот как я получаю индекс каждого элемента в .NET 9

Используй метод Index из LINQ.

LINQ всегда был крайне полезным инструментом для .NET-разработчиков.

Но с выходом .NET 9 в LINQ появились три новых метода:

> Index
> CountBy
> AggregateBy

Сконцентрируемся на методе Index.

Метод Index возвращает перечисление (enumerable), в котором каждый элемент представлен в виде кортежа с его индексом.

Это отличный способ, если тебе нужно получить индекс каждого элемента в коллекции.

Пример кода прикрепил 😎

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥6
Как реализовать Refresh Tokens в ASP.NET Core и как отозвать токены пользователя 👇

Настоящая сложность не в базовой реализации аутентификации через JWT, а в том, чтобы обеспечить безопасность и хороший пользовательский опыт при истечении срока действия токенов.

Обычно JWT-аутентификация использует два токена:

● Access token — даёт доступ к защищённым ресурсам и живёт недолго (обычно 5–10 минут).
● Короткий срок жизни снижает риски при компрометации.

Refresh token — нужен для получения нового access token без повторного входа пользователя в систему.

Если access token живёт всего несколько минут — пользователь будет постоянно переавторизовываться. Это ужасный UX.

Здесь и вступает в игру refresh token. Он позволяет «тихо» получить новый access token, когда текущий истёк, не требуя логина.

Refresh token, как правило, живёт дольше — от нескольких дней до недель.

Anton Martyniuk рассказал:

🔸Что такое refresh токены и как они работают
🔸Как реализовать их в ASP.NET Core
🔸Как обеспечить безопасность и соблюдать best practices
🔸Как отзывать refresh токены, чтобы динамически обновлять права доступа пользователя

Хочешь прокачать безопасность в ASP.NET Core по индустриальным стандартам? вот статья

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍4👀2
GitHub Copilot Chat теперь с открытым кодом

Microsoft сделали первый шаг к превращению VS Code в полноценный опенсорс AI-редактор

Теперь можно заглянуть под капот: как работает agent mode, что уходит в LLM, как устроены промпты и даже какую телеметрию они собирают

Код доступен на GitHub ✌️

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥4
C#‑«скрипт» для отправки HTTP-запроса с использованием Flurl.

Эта возможность появится в .NET 10 — подробнее

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍124🤔3😁1
Как быстро расчистить раздутые API-контроллеры:

Используй метод-инъекцию 😨

Это малоизвестная фича в ASP.NET Core, которая позволяет внедрять зависимости не в конструктор, а напрямую в метод-обработчик.

Для этого используется [FromServices] IYourService

Хотя [FromServices] можно и опустить — оно не обязательно.

Когда стоит использовать метод-инъекцию:

🔸когда сервис используется только в одном экшене
🔸когда конструктор начинает превращаться в кашу из зависимостей
🔸когда сервис тяжёлый, и важно контролировать его создание и утилизацию

Да, внедрение через конструктор — это дефолтный подход.
Но метод-инъекция — это удобный инструмент, если ты:

- хочешь придерживаться Single Responsibility Principle

- не хочешь превращать контроллер в свалку зависимостей

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍107
C# наконец-то получает дискриминируемые объединения

Ну, возможно?

Появилось новое предложение по добавлению объединений типов (Type Unions) в C#. И это действительно важно.

Почему?

Это открывает нативную поддержку таких конструкций, как Result и Option.

Больше не нужно городить костыли, оборачивать значения или зависеть от сторонних библиотек, чтобы описать функцию, возвращающую успех или ошибку.

Я уже много лет выступаю за использование паттерна Result. Но до сих пор отсутствие поддержки на уровне языка делало его применение неуклюжим.


Теперь это может измениться.

В предложении описываются нативные union-типы, включая поддержку pattern matching, проверку исчерпывающего перебора (exhaustiveness checks) и другие фичи.

Не хочешь ждать?

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

Если предпочитаешь бросать исключения — можешь это пропустить. 🤵

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
10
Миф о том, что Dapper на 50% быстрее EF Core — это неправда

Ты наверняка слышал, как говорят, что Dapper на 30%, 50% или даже в 2 раза быстрее, чем EF Core?

Это утверждение гуляет повсюду.

Но проведя реальный бенчмарк на .NET 8, с таким запросом:

"Получить топ-5 пользователей, которые оставили больше всего комментариев за последние 7 дней к постам в категории '.NET'"


Результаты удивили:

🔸Dapper: 2.07 мс
🔸EF Core: 2.43 мс
(см. скриншот для деталей)

Разница — всего 0.36 мс, или 14%.

Да, Dapper выделяет меньше памяти, но для большинства приложений эта разница мизерная.

Что это значит?

↳ Для 80% проектов такая разница в производительности вообще не критична.
> Поэтому EF Core — мой выбор по умолчанию.

12 причин выбрать EF Core вместо Dapper в реальной разработке:

1. Автоматическое отслеживание изменений сущностей — меньше ручного кода для insert, update, delete.

2. LINQ-запросы с проверкой на этапе компиляции, которые трансформируются в SQL.

3. Code-First миграции упрощают эволюцию схемы базы данных.

4. Возможность реверс-инжиниринга существующей базы в модели.

5. Навигационные свойства позволяют работать с отношениями без ручных join-ов.

6. Поддержка eager, lazy и explicit загрузки данных.

7. Глобальные фильтры запросов для soft delete и мультиарендности.

8. Value Conversions — удобное отображение кастомных типов на столбцы в БД.

9. Встроенные политики повторных попыток (retry) делают соединения с БД более устойчивыми.

10. Interceptors — можно реализовать аудит, логирование, кастомные поведения.

11. Один и тот же запрос работает с множеством провайдеров: SQL Server, PostgreSQL, MySQL, Oracle, SQLite и др.

12. Поддержка миграций сразу для нескольких БД из одного кода.

Важно:

EF Core может не быть самым быстрым в микробенчмарках, но его возможности экономят часы и дни в реальных проектах.

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

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥13👍75🍌1
Как реализовать ограничение частоты запросов для аутентифицированных пользователей?

Можно использовать ID пользователя в качестве ключа разбиения (partition key) для лимитирования.

В .NET есть механизм partitioned rate limiter, который позволяет это настроить.

ID пользователя можно получить из claim'а в JWT или из cookie.

Такую политику лимитирования можно применить:

🔸На уровне API — для простых сценариев
🔸На уровне reverse proxy — при масштабировании

Хочешь узнать о более продвинутых сценариях лимитирования?

Начни отсюда: тык

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍112🍌2
𝟵𝟬% API не являются настоящими RESTful

Веб-API нельзя считать полностью RESTful без "GPS"

Согласно модели зрелости REST по Ричардсону, существует 4 уровня REST-архитектуры:

> Уровень 0 (Swamp of POX): один endpoint, передача XML или JSON без структуры
> Уровень 1 (Resources): выделенные ресурсы с уникальными URI
> Уровень 2 (HTTP-глаголы): корректное использование методов HTTP (GET, POST, PUT, DELETE, PATCH)
> Уровень 3 (HATEOAS): API динамически предоставляет ссылки, направляя клиента по возможным действиям и состояниям

Большинство API застряли на уровне 2, не реализуя HATEOAS.

Что такое HATEOAS?

Hypermedia as the Engine of Application State — "гипермедиа как движок состояния приложения"

Это как GPS для клиента API:

🔸API динамически вшивает ссылки, которые подсказывают клиенту, какие действия доступны
🔸Клиент не хардкодит маршруты, а получает их от сервера
🔸Это делает API гибким и устойчивым к изменениям — даже при эволюции контракта

Почему это важно?

Без HATEOAS:

> Frontend дублирует бизнес-логику с backend'а (например, решает, показывать ли кнопку "Обновить")
> Это приводит к рассинхрону и багам

С HATEOAS:

> Сервер сам отправляет клиенту ссылку на обновление ресурса
> Frontend просто следует ссылке — никакой лишней логики

Такой подход переносит всю сложность туда, где ей место — на backend.

Ты уже используешь HATEOAS в своих API, или твой проект всё ещё застрял на уровне 2?

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍54🥴2🐳2
Какой синтаксис мокинг-библиотеки для dotnet вам больше по душе из примеров выше?

Moq?
NSubstitute?
FakeItEasy?

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

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
7🤨2
Вот 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍72
Большинство разработчиков неправильно понимают DDD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
6😁1
Работать с 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥53