C# (C Sharp) programming
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
Ko'proq ko'rsatish📈 Telegram kanali C# (C Sharp) programming analitikasi
C# (C Sharp) programming (@csharp_ci) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 18 126 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 7 044-o'rinni va Rossiya mintaqasida 36 287-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 18 126 obunachiga ega bo‘ldi.
30 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -65 ga, so‘nggi 24 soatda esa 0 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 15.36% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 7.44% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 784 marta ko‘riladi; birinchi sutkada odatda 1 349 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 0 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent .net, api, логика, архитектура, string kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“По всем вопросам- @notxxx1
Реестр РКН: https://clck.ru/3Fk3kb
#VRHSZ”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 31 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
OpenTelemetry.Extensions.Hosting OpenTelemetry.Instrumentation.AspNetCore OpenTelemetry.Instrumentation.Http OpenTelemetry.Exporter.OpenTelemetryProtocol- В
Program.cs:
builder.Services.AddOpenTelemetry()
.ConfigureResource(r => r.AddService("MyService"))
.WithTracing(t => t
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddOtlpExporter()
);
builder.Logging.AddOpenTelemetry(lo => lo.AddOtlpExporter());
- Настраиваем экспорт через OTLP в Grafana Cloud — задаём endpoint и токен
📊 Что получаем:
- Полный стек наблюдаемости: метрики, логи, трассировки в одном интерфейсе
- Графаны Dashboard — красивые дашборды + оповещения при проблемах
- Глубокий анализ: сквозные запросы, задержки, узкие места
🎯 Почему это стоит использовать:
- Вендорно-нейтральное решение — работает с разными платформами
- Начальный уровень бесплатно в Grafana Cloud
- Настройка занимает минимум времени — максимальная отдача
@csharp_ci
// Проверка: Ticketing-модуль не должен зависеть от Users, Events и т.д.
Types.InAssemblies(ticketingAssemblies)
.That().DoNotHaveDependencyOnAny(otherModules)
.Should().NotHaveDependencyOnAny(otherModules)
.GetResult()
.ShouldBeSuccessful();
// Проверка Clean Architecture:
Types.InAssembly(DomainAssembly)
.Should().NotHaveDependencyOn(ApplicationAssembly.GetName().Name)
.GetResult()
.ShouldBeSuccessful();
✅ Можно проверять любой дизайн:
• Модули — должны вызывать друг друга только через public API
• Слои Clean Architecture — например, Domain не должен ссылаться на Infrastructure
• Правила дизайна — все IDomainEvent должны быть sealed
• Конвенции имен — например, все CommandHandler'ы должны оканчиваться на CommandHandler
🛠 Итого:
• Architecture tests — не просто инструмент, а средство контроля архитектуры
• Работает как компилятор для архитектурных правил — это гарантирует соблюдение структуры
• Идеально подходит для modular monolith, Clean Architecture и крупных систем
• Сдвигает баги из продакшна в CI-пайплайн
🧭 Как начать:
1. Выберите библиотеку (ArchUnitNET, NetArchTest, …)
2. Напишите пару тестов — например, на зависимости между слоями
3. Интегрируйте в CI (GitHub Actions, Azure Pipelines, TeamCity и др.)
4. Соблюдайте — и архитектура останется в целости
🎯 Ключевой вывод
С architecture testing вы не просто «следуете стандартам» — вы автоматизируете дизайн, позволяя команде фокусироваться на логике, а не на структуре. Shift Left не для QA — теперь и архитектура под защитой.
📚 ПодробнееMoney, Email, `Address`)
🛠 В статье:
• Почему использовать Value Objects вместо простых типов
• Как реализовать их в .NET (структура, инварианты, валидация)
• Примеры кода, включая record, struct и кастомные value equality
• Как внедрять их в Entity Framework Core без боли
💡 Отличный материал для тех, кто хочет строить чистую доменную модель и развивать архитектурное мышление.
🔗 Читай статью:
https://www.telerik.com/blogs/domain-driven-design-principles-value-objects-aspnet-core
#DDD #ASPNetCore #ValueObjects #SoftwareArchitecture #Telerik
List<int> numbers = new List<int> { 1, 2, 3, 4 };
foreach (var n in numbers)
{
Console.WriteLine(n);
if (n == 2)
numbers.Remove(n); // 😬
}
❓ Вопрос: Что произойдёт при запуске?
🔍 Разбор
На первый взгляд — ничего особенного. Но при запуске вы получите:
1 2 Unhandled exception. System.InvalidOperationException: Collection was modified; enumeration operation may not execute.💣 Почему так? Потому что `foreach` в C# использует **итератор (Enumerator)**, который **не допускает изменений коллекции во время прохода**. Это встроенная защита от непредсказуемых багов и гонок. ✅ Как можно обойти? Вариант 1 — использовать
for вместо foreach:
for (int i = 0; i < numbers.Count; i++)
{
if (numbers[i] == 2)
{
numbers.RemoveAt(i);
i--; // ⚠️ Обязательно откатить индекс!
}
}
Вариант 2 — создать копию коллекции:
foreach (var n in numbers.ToList())
{
if (n == 2)
numbers.Remove(n);
}
🧠 Вывод:
В C# `foreach` нельзя использовать на коллекциях, которые вы планируете менять в теле цикла. Это распространённая ловушка даже для опытных разработчиков.
📎 Советы:
- При изменениях — лучше for или .ToList()
- Внимательно читайте исключения: InvalidOperationException — ваш друг в отладке
Поделитесь с коллегами — пусть никто не попадается 😊
@csharp_ci@inject или [Inject].
- Service Locator: избегайте этого подхода, так как он усложняет тестирование и нарушает принципы DI.
🔄 Варианты времени жизни сервисов:
- Singleton: один экземпляр на всё приложение.
- Scoped: один экземпляр на сессию пользователя.
- Transient: новый экземпляр при каждом запросе.
💡 Рекомендации:
- Используйте интерфейсы для определения зависимостей.
- Избегайте внедрения Scoped сервисов в Singleton сервисы.
- Для управления временем жизни сервисов используйте OwningComponentBase.
📚 Примеры использования:
- Внедрение HttpClient для выполнения HTTP-запросов.
- Использование NavigationManager для управления навигацией.
- Внедрение IJSRuntime для взаимодействия с JavaScript.
📖 Подробнее читайте в статье
@csharp_cidotnet-counters показывает рост в LOH (Large Object Heap)
- Приложение не падает, но хост начинает свапать и тормозить
- При перезапуске — память очищается, но через 2–3 часа снова заполняется
❗ В логах — тишина, ошибок нет. Библиотеки: Newtonsoft.Json, HttpClient, MemoryCache, EF Core.
---
🧩 Твоя задача:
1. Почему .NET GC может не освобождать LOH, даже при работе GC?
2. Какие действия вызывают накопление в LOH?
3. Как можно отследить, какие объекты скапливаются в памяти?
4. Чем опасен повторный вызов HttpClient или StringBuilder без очистки?
5. Как корректно использовать MemoryCache, чтобы избежать утечек?
💡 Подсказка:
- LOH начинается с объектов > 85,000 байт
- Часто виноваты: большие строки, сериализация, `ToString()`, `MemoryStream`, `Image`, `byte[]`
- `MemoryCache` может хранить сильные ссылки бесконечно, если не задано время жизни
- Частое создание `HttpClient` — может удерживать сокеты в TIME_WAIT и загонять GC в ступор
🛠 Решение:
1. Запускаем профилировщик:
dotnet-gcdump collect -p <PID>
dotnet-gcdump analyze dump.gcdump
2. Смотрим типы с самым большим retained size: List<string>, byte[], MemoryStream
→ В коде — сериализация в JSON огромных объектов без ограничения глубины
3. Находим участок с JsonConvert.SerializeObject(hugeObject) без MaxDepth
4. Исправления:
- Добавить настройки сериализации:
new JsonSerializerSettings { MaxDepth = 5, ReferenceLoopHandling = Ignore }
- Ограничить MemoryCache по размеру:
new MemoryCache(new MemoryCacheOptions { SizeLimit = 100_000_000 });
- Использовать HttpClientFactory вместо new HttpClient() на каждый запрос
5. Альтернатива: перейти на System.Text.Json с Utf8JsonWriter — меньше аллокаций
📌 Вывод:
Даже без явных ошибок .NET-приложение может стабильно "утекать" в LOH — через сериализацию, кэш или неправильную работу с потоками. Только анализ дампа памяти и правильная конфигурация GC и кешей помогут найти такие проблемы.
@csharp_ci