C# (C Sharp) programming
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
نمایش بیشتر📈 تحلیل کانال تلگرام C# (C Sharp) programming
کانال C# (C Sharp) programming (@csharp_ci) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 18 129 مشترک است و جایگاه 7 041 را در دسته فناوری و برنامهها و رتبه 36 302 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 18 129 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 29 اوت, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -78 و در ۲۴ ساعت گذشته برابر -7 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 15.03% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 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 и использовать пул подключений, конфигурируя таймауты и политику повторов.
Как думаешь, какой вариант правильный?