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

Связь: @devmangx

РКН: https://clck.ru/3FocB6
Download Telegram
Есть тема, о которой многие разработчики слышали вскользь, но глубоко не погружались, это рефлексия. Рефлексия это способность языка программирования «смотреть на себя», получать информацию о собственных структурах во время выполнения.

Она полезна для динамических валидаций, метапрограммирования и лежит в основе работы ORM, которые строят запросы и мапят объекты, опираясь на знания о типах и структурах.

Пример 1

Класс Beer имеет три свойства: Name, Brewery, Alcohol. Через рефлексию мы получаем их список и типы.

// Смотрим тип объекта
Type type = typeof(Beer);

Console.WriteLine($"Тип: {type}");

// Свойства и их типы
Console.WriteLine("Свойства и типы:");

foreach (var prop in type.GetProperties())
{
Console.WriteLine($"{prop.Name} ({prop.PropertyType})");
}

// Класс для хранения пива
class Beer
{
public string Name { get; set; } = string.Empty;
public string Brewery { get; set; } = string.Empty;
public double Alcohol { get; set; }
}


Вывод в консоль:

Тип: Beer
Свойства и типы:
Name (System.String)
Brewery (System.String)
Alcohol (System.Double)


Во втором примере в класс добавили новое свойство Brand. Код не изменился, но при запуске список свойств автоматически расширился, и на консоли появился ещё один элемент:

// Смотрим тип объекта
Type type = typeof(Beer);

Console.WriteLine($"Тип: {type}");

// Свойства и их типы
Console.WriteLine("Свойства и типы:");

foreach (var prop in type.GetProperties())
{
Console.WriteLine($"{prop.Name} ({prop.PropertyType})");
}

// Класс для хранения пива
class Beer
{
public string Name { get; set; } = string.Empty;
public string Brewery { get; set; } = string.Empty;
public double Alcohol { get; set; }

// Новое свойство
public string Brand { get; set; } = string.Empty;
}


Вывод в консоль:

Тип: Beer
Свойства и типы:
Name (System.String)
Brewery (System.String)
Alcohol (System.Double)
Brand (System.String)


👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍83🔥2
Большинство сеньоров советуют создавать репозитории для EF Core.

Но это не лучший способ писать код.

По мере роста .NET-проекта работа с данными становится все сложнее.

Многие команды начинают с паттерна Repository, оборачивая в него запросы EF Core.

Сначала всё ок. Но со временем ваши репозитории либо делают слишком мало, либо пытаются делать слишком много.

Код становится труднее понимать и менять по мере того, как меняются бизнес-требования.

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

Помните, что DbContext в EF Core уже реализует паттерны Repository и Unit of Work.

Это прямо указано в официальной документации Microsoft по DbContext. Это же видно в summary DbContext в IDE.

Создавая репозиторий поверх EF Core, мы получаем абстракцию поверх абстракции. И часто приходим к переусложнённым решениям.

Как решить проблему? Ответ: паттерн Specification. 😞

Паттерн Specification позволяет описывать, какие данные нужны из базы, с помощью небольших переиспользуемых классов — «спецификаций».

Каждая спецификация это правило или фильтр, который можно применить к запросу. Так можно собирать сложные запросы из простых и понятных блоков.

Полный разбор тут :

→ почему репозитории становятся узким местом в реальных проектах
→ что такое паттерн Specification
→ как внедрять спецификации в EF Core
→ продвинутые приёмы спецификаций

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍95👎2
Паттерн CQRS часто кажется сложным, но на деле он строится вокруг простых принципов.

Разработчики рекомендуют организовывать код вокруг use case'ов, которые отражают конкретный функционал приложения, например получить данные пользователя, добавить товар в корзину или оформить возврат.

То есть можно думать о use case как о бизнес-возможности.

Я строю код вокруг одного конкретного use case.

Есть два типа use case'ов:

Commands → бизнес-логика, работа с базой, побочные эффекты

Queries → возвращают данные в нужном виде для UI


Для реализации часто используют библиотеку MediatR, хотя после перехода проекта на платную модель многие задумываются о собственных решениях или остаются на бесплатной версии.

Подробнее о подходе CQRS можно почитать в блоге Милана Йовановича 💯

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
6😁2
Вместо того чтобы:

→ городить здоровенный метод с 5+ параметрами
→ и постоянно добавлять туда новые параметры

Сделай так:

1. Создай новый класс.
2. Свойства класса — это те же самые параметры метода.
3. Замени параметры метода на новый класс.
4. Поправь вызовы метода.

Этот рефакторинг называется Introduce Parameter Object.

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

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17😁53🤯3
Есть десктопное приложение под Mac, Windows и Linux, которое обучает работе с Git через практику. Никаких лекций, только реальные задания в Git и GitHub. Репозитории создаются прямо в вашем аккаунте, результат сохраняется навсегда. Плюс доступна поддержка разных языков.

Ссылка: https://github.com/jlord/git-it-electron

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥3
Как писать условные и при этом читаемые запросы?

Всё что нужно, это выражение CASE.

Оно работает так же, как if else if else в C#. Как только условие срабатывает, чтение останавливается и возвращается результат, если ни одно условие не выполнилось, возвращается значение из ветки ELSE.

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

Кроме того, CASE полезен, если у вас несколько ORDER BY для многоуровневой сортировки.

Но есть важный момент, который я сам однажды понял на практике, использовать CASE лучше в SELECT, а не в WHERE.

Почему? потому что WHERE почти всегда работает быстрее для фильтрации строк.

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍74🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Карто-ориентированное программирование 😂

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
13😁12🌚3🏆3🔥1
9 паттернов, которые делают приложения реально живучими

В мире распределённых систем падения неизбежны. Вопрос не если, а когда. Но есть проверенные подходы, которые позволяют системе вставать после каждого сбоя.

→ 1. Circuit Breaker

• Работает как электрический предохранитель
• При постоянных сбоях сервис временно отключается от потока запросов
• Даёт возможность восстановиться без перегрузки
• Состояния: Closed — запросы проходят, Open — запросы сразу отваливаются
• Защищает от каскадных фейлов и изолирует проблемные сервисы

→ 2. Retry

• При падении запроса система повторяет его несколько раз
• Помогает при временных проблемах: сетевые глюки, недоступность сервиса
• Повышает доступность и сглаживает сбои
• Важно: избегать retry storm, использовать exponential backoff

→ 3. Timeout

• Ограничивает максимальное время выполнения запроса
• Если ответ не пришёл вовремя, считаем его неудачным

→ 4. Bulkhead

• Делит приложение на изолированные "отсеки" или пулы
• Сбой в одном отсеке не валит всё приложение

→ 5. Rate Limiting

• Контролирует поток входящих запросов
• Защита от перегрузки и DDoS
• Поддерживает стабильность и справедливое использование

→ 6. Fallback

• Возвращает запасной ответ или действие при сбое основного
• Улучшает доступность и UX, лучше частичный сервис, чем ошибка

→ 7. Hedging (Redundancy)

• Отправляет дублирующие запросы в несколько сервисов
• Использует самый быстрый ответ
• Уменьшает влияние медленных откликов и падений

→ 8. Load Shedding

• Отбрасывает второстепенные запросы при перегрузке
• Сохраняет работу ключевых функций
• Держит систему живой в пиковые моменты

→ 9. Backpressure

• Обратная связь между продюсером и консъюмером
• Консъюмер сообщает о своей нагрузке, продюсер регулирует скорость

Стратегии:

• Reactive Pull — консъюмер тянет данные сам
• Rate Limiting — продюсер ограничивает скорость по фидбеку
• Buffering — данные временно хранятся в буфере

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
13👍5🔥2
.NET 9 обошёл всех конкурентов по скорости. Он быстрее Java, Go, Python, Node.js, PHP и ещё десятка популярных фреймворков.

Адаптивный GC, умный JIT, векторизация на AVX10 и Arm SVE, Native AOT для контейнеров и IoT, быстрый System.Text.Json, минимальные аллокации и апгрейд минимальных API. Всё это даёт стабильный отклик и высокую пропускную способность даже под нагрузкой.

По бенчмаркам:

Spring медленнее в 2.5 раза, Fiber — в 1.3, Fastify — в 4, FastAPI — в 10, Rails — в 20, Laravel — в 15. Даже Ktor, Deno, Vapor и Phoenix отстают.

В 2025 .NET 9 позиционируется как лучшая платформа для продакшн-проектов: от микросервисов в Kubernetes до IoT и edge-нагрузок 😎

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
256👍12🔥10
Фича дня в EF Core — алгоритм Hi/Lo.

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

Работает это так. Приложение не берёт каждый новый ID отдельно, а запрашивает у базы целую пачку. В самой базе хранится hi_value, который отражает максимальный выданный идентификатор. Когда приложению нужна новая порция, оно начинает с hi_value + 1.

Минус в том, что могут появиться пропуски в последовательности, если приложение упадёт до того, как израсходует все ID из своей пачки, но это не критично.

Включается всё через метод UseHiLo, который создаёт в базе sequence для выдачи батчей идентификаторов. После этого EF Core может сам задавать все первичные ключи на клиенте, что особенно удобно для parent/child-отношений.

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍3
Цифры задержек, которые стоит знать каждому разработчику:

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Сжать 1K байт с помощью Zippy ............. 3,000 ns = 3 µs
Отправить 2K байт по сети 1 Gbps .......... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Прочитать 1 MB последовательно из памяти .. 250,000 ns = 250 µs
Round trip внутри датацентра ................ 500,000 ns = 0.5 ms
Прочитать 1 MB последовательно с SSD .... 1,000,000 ns = 1 ms
Disk seek ........................... 10,000,000 ns = 10 ms
Прочитать 1 MB последовательно с диска .. 20,000,000 ns = 20 ms
Отправить пакет CA → Netherlands → CA ... 150,000,000 ns = 150 ms


👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥122
Слышал о новом типе UUID?

Я часто использую UUID (Guid в C#) как уникальные идентификаторы в базе.

Они удобны тем, что «рандомные», но есть и минусы.

Во-первых, они занимают много памяти — Guid в C# весит 16 байт.
Кроме того, индексы с такими значениями могут фрагментироваться, так как они не сортируемые.

Теперь появился UUID V7. Он сортируемый, потому что в нем есть компонент времени.

Его можно создать в .NET 9 через Guid.CreateVersion7

Также он будет поддерживаться нативно в PostgreSQL 18.

Ты бы стал его использовать? 🌟

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
17
1 потрясающая функция в Visual Studio, о которой я недавно узнал:

Endpoints Explorer.

Это окно, в котором ты можешь увидеть все свои API-эндпоинты в одном месте:

Просматривать URL эндпоинта и параметры

Открывать эндпоинт в редакторе кода

Выполнять HTTP-запрос

Чтобы открыть окно Endpoints Explorer, нужно перейти в:

View -> Other Windows -> Endpoints Explorer

P.S. Ты уже использовал эту функцию в Visual Studio? 🌟

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
20👍8🙏2
Не пытайся быть умным.

Работа не про то, чтобы писать «умный» код.

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

И про то, чтобы следующий разработчик мог без проблем продолжить твою работу.

Каждый раз, когда пишешь что-то, спрашивай себя:

«Если тот, кто будет поддерживать этот код, окажется психопатом, который знает, где я живу, спокойно ли я оставлю этот код как есть?»


Если нет — упростите. Прямо как будто от этого зависит твоя жизнь.

Будь понимающим коллегой, а не эгоистичным кодером. 🛌

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
15👍8👏2💯2🔥1
Каждый .NET-разработчик должен быть в восторге от этого

Visual Studio 2026 уже вышла.

Она получила новый UI, предлагает новые наборы рабочих нагрузок и делает серьёзный акцент на разработке с поддержкой ИИ.

Что особенно выделяется:

I. .NET 10 и C# 14
II. Новый внешний вид и ощущения от интерфейса
III. Исключение файлов из поиска
IV. Рендеринг диаграмм Mermaid
V. Встроенный инструмент покрытия кода
VI. Шаблон проекта для BenchmarkDotNet
VII. Возможность подключить собственную модель в чат
VIII. Улучшенные элементы редактора
IX. Новый опыт запуска профайлера
X. Пост-return значения inline
XI. Поиск в Text Visualizer
XII. Inline-комментарии к pull request
XIII. Поддержка Podman в Container Tools
XIV. Улучшения Hot Reload
XV. Улучшения редактора Razor
XVI. Copilot и ИИ в контекстном меню, при вставке, в code review, в поиске «Вы имели в виду»... везде

После успешных предшественников VS2026 выходит обновлённой и с акцентом на AI-функции.

Я бы дал ей прозвище: AI Studio 2026 🙄

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
18👍6🤔1
Пагинация с offset подходит для небольших наборов данных.

Для больших лучше использовать другой подход, а именно keyset pagination (она же seek-based pagination). Это гораздо более эффективный способ обхода больших выборок.

Проблема offset-пагинации (skip + take) в том, что база всё равно обрабатывает пропущенные строки, даже если они не возвращаются в результат.

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

Если столбец ID проиндексирован, такие запросы будут очень быстрыми даже на больших объемах данных.

А если у вас в качестве идентификаторов GUID? Тогда используйте UUID версии 7, он глобально уникальный и при этом сортируемый.

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
6
Неправильный выбор структур данных убивает .NET-приложения

Оптимизация 12 корпоративных систем на ASP .NET Core показала одну и ту же проблему -> разработчики часами тюнят запросы, добавляют индексы и кэш, но игнорируют главный фактор производительности —> структуры данных. 👊

Ошибочный выбор коллекций может замедлить приложение в 10 раз.

Вот что стоит использовать в зависимости от операции:

I. Поиск элементов по ключу
List<T>.Find() → O(n) → ужасно на больших объёмах
Dictionary<K,V> → O(1) → молниеносно

II. Частые вставки в начало
List<T>.Insert(0, item) → O(n) → сдвигает все элементы
LinkedList<T> → O(1) → без сдвигов

III. Коллекция с уникальными элементами
List<T> + проверка Contains → O(n) на добавление
HashSet<T> → O(1) → моментальная проверка уникальности

IV. Упорядоченные данные с бинарным поиском
List<T> + Sort → O(n log n) + свой код поиска
SortedDictionary<K,V> → встроенный порядок + O(log n) доступ

V. Кэширование ответов API
Статический Dictionary → утечки памяти и устаревшие данные
MemoryCache с истечением → автоматическая очистка

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

А какую самую серьёзную проблему с производительностью ты решал выбором правильной структуры данных?

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍115🤯4
Простой гид по масштабированию веб-приложений

Система с более чем миллионом пользователей была масштабирована пошагово

I) Начало с простого

Приложение изначально монолит. Один API-сервер, одна база данных. Несколько лет работало стабильно, но с ростом пользователей система начала тормозить

II) Масштабирование API

База данных пока не была узким местом. Масштабирование API и добавление балансировщика нагрузки в Azure позволили обрабатывать больше запросов. Вертикальное масштабирование DB-сервера сработало на время, но позже потребовалось больше

III) Кэширование

Сначала использовался простой in-memory кэш на серверах. Позже внедрён Redis, распределённый кэш снизил нагрузку на базу. Большинство запросов стало обслуживаться из кэша

Главный совет

Решать проблему, которая есть сейчас. Не переусложнять архитектуру раньше времени

Подробнее о масштабировании приложений

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Сегодня отмечается День программиста!

256-й день года выбран не случайно:
Дата праздника объясняется расчетом: 2 (двоичная система исчисления) в степени 8 (количество битов в байте). То есть 2^8= 256. Поэтому в обычный год день программиста 13 сентября, а в високосный — 12 сентября


С праздником, коллеги! ☺️

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
622🔥8👍6
Media is too big
VIEW IN TELEGRAM
Настоящая находка для гейм девелоперов

Это огромная библиотека бесплатных ресурсов. От спрайтов и текстур до 3D-моделей, звуков и шрифтов, включая ассеты для VR и AR. Всё распространяется по лицензии CC0, так что использовать можно где угодно, даже в коммерческих проектах.

Коллекция постоянно пополняется, а для прототипов, инди-игр и учебных проектов это просто незаменимый инструмент.

kenney.nl/assets

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
6👍4
This media is not supported in your browser
VIEW IN TELEGRAM
Интерактивный визуальный гид по математике и алгоритмам через концепты геймдева — https://redblobgames.com

Особое внимание уделите главам про теорию графов 💯

👉 @KodBlog
Please open Telegram to view this post
VIEW IN TELEGRAM
👍104