C# (C Sharp) programming
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
Показати більше📈 Аналітичний огляд Telegram-каналу C# (C Sharp) programming
Канал C# (C Sharp) programming (@csharp_ci) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 18 127 підписників, посідаючи 7 041 місце в категорії Технології та додатки та 36 302 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 18 127 підписників.
За останніми даними від 29 серпня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -78, а за останні 24 години на -7, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 15.03%. Протягом перших 24 годин після публікації контент зазвичай збирає 7.44% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 725 переглядів. Протягом першої доби публікація в середньому набирає 1 348 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 0.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як .net, api, логика, архитектура, string.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“По всем вопросам- @notxxx1
Реестр РКН: https://clck.ru/3Fk3kb
#VRHSZ”
Завдяки високій частоті оновлень (останні дані отримано 30 серпня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
CommandHandler. Если кто-то добавит класс с неправильным именем, тест упадёт, и проблема решится ещё до ревью.
Такую технику можно использовать для:
- сервисов (`...Service`)
- хендлеров (`...Handler`)
- репозиториев (`...Repository`)
- DTO/Queries/Commands
- модульных границ и зависимости между слоями
Это простой способ навести порядок в архитектуре, а не надеяться только на дисциплину команды.
Пример теста (C#):
public void CommandHandler_ShouldHave_NameEndingWith_CommandHandler()
{
Types.InAssembly(ApplicationAssembly)
.That()
.ImplementInterface(typeof(ICommandHandler<>))
.Or()
.ImplementInterface(typeof(ICommandHandler<,>))
.Should()
.HaveNameEndingWith("CommandHandler")
.GetResult()
.ShouldBeSuccessful();
}
Такие архитектурные проверки избавляют от стихийных ошибок и делают кодовую базу предсказуемой — особенно в больших командах и долгоживущих проектах.
/// Пример класса контекста пользователя
internal sealed class UserContext(IHttpContextAccessor httpContextAccessor)
: IUserContext
{
public Guid UserId =>
httpContextAccessor
.HttpContext?
.User
.GetUserId() ??
throw new ApplicationException("User context is unavailable");
public bool IsAuthenticated =>
httpContextAccessor
.HttpContext?
.User
.Identity?
.IsAuthenticated ??
throw new ApplicationException("User context is unavailable");
}
if (user != null &&
user.Name.Length > 0 &&
user.Subscription != null)
{
// ...
}
C# позволяет писать проще и выразительнее:
if (user is { Name.Length > 0, Subscription: not null })
{
// ...
}
✨ Что изменилось?
✔️ Нет ручных проверок на null - компилятор сам учитывает это в выражении
✔️ Условие читается как описание объекта, а не как набор проверок
✔️ Логика становится компактнее и легче сопровождается
Используйте pattern matching, чтобы избавляться от лишнего шума и писать более понятный код.DbContext как scoped и считают что этого достаточно.
На деле всё сложнее.
- DbContext не потокобезопасен.
Делить один экземпляр между потоками приводит к исключениям.
- DbContext лёгкий и должен жить недолго.
Создавай его часто, освобождай сразу.
- Неверная работа с контекстом ведёт к росту памяти и утечкам.
✅ Решения которые уже есть в EF Core
IDbContextFactory
Позволяет безопасно создавать контексты по запросу.
Подходит для фоновых задач, многопоточности и десктоп приложений.
DbContext Pooling
Переиспользует заранее подготовленные экземпляры.
Сбрасывает состояние после использования, снижает нагрузку на память и процессор.
Pooled DbContextFactory
Комбинирует фабрику и пул.
Даёт контексты по запросу и эффективно их переиспользует.
⚠️ Правила которые нельзя нарушать
- Никогда не дели DbContext между потоками.
- Всегда освобождай контекст с помощью using или возврата в пул.
Грамотное управление жизненным циклом DbContext повышает стабильность и масштабируемость и убирает скрытые утечки памяти которые годами портят EF Core проекты.
https://antondevtips.com/blog/top-10-mistakes-developers-make-in-ef-core/lock не работает с async/await, и многие пытаются заменить его чем угодно, лишь бы компилилось. Правильный путь — использовать SemaphoreSlim с WaitAsync, как на примере: он позволяет ограничивать конкуренцию и работает корректно в асинхронном коде.
Главное — всегда освобождать семафор в finally и не забывать про таймауты, чтобы не создавать висячие блокировки.
Асинхронная синхронизация — это не магия, а аккуратность и понимание того, как работает планировщик задач в .NET.Handle<ConflictException>()
— Делаем паузу между попытками (`Delay = 1 сек`)
— Используем экспоненциальный backoff
— Добавляем jitter, чтобы избежать «шторма» повторов
— Ограничиваем количество попыток (`MaxRetryAttempts = 2`)
2) Timeout (ограничение времени выполнения)
— Ставим таймаут в 10 секунд на сетевой запрос
Далее создаётся pipeline и выполняется HTTP-запрос:
await pipeline.ExecuteAsync(async ct ⇒ await httpClient.GetAsync("https://modularmonolith.com", ct));
Эти две стратегии уже дают серьёзную устойчивость:
запросы не зависают, ошибки перехватываются, приложение остаётся стабильным даже при нестабильных сервисах.
https://github.com/App-vNext/Polly
public class PaymentClient
{
private readonly string _baseUrl;
public PaymentClient(string baseUrl)
{
_baseUrl = baseUrl;
}
public async Task<bool> ChargeAsync(ChargeRequest request)
{
using var http = new HttpClient();
http.BaseAddress = new Uri(_baseUrl);
var response = await http.PostAsJsonAsync("/charge", request);
return response.IsSuccessStatusCode;
}
}
Под нагрузкой:
- растёт количество TIME_WAIT соединений
- часть запросов получает timeout
- p95 и p99 по этому методу улетают в космос
Какой вариант исправления правильный?
1. Увеличить Timeout у HttpClient и ServicePointManager.DefaultConnectionLimit.
2. Сделать HttpClient статическим полем и переиспользовать его во всех запросах.
3. Зарегистрировать HttpClient через IHttpClientFactory и использовать пул подключений, конфигурируя таймауты и политику повторов.
Как думаешь, какой вариант правильный?