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، تحافظ القناة على نشاط مستقر. خلال آخر 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) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
DbContext уже реализует Repository и Unit of Work
- Репозитории со временем превращаются в «монстров» с десятками методов
- Каждый новый фильтр = новая копипаста
В итоге — абстракция над абстракцией и трудности с поддержкой.
---
✅ Что вместо этого? Specification Pattern
Specification = маленький класс, описывающий правило или фильтр.
Вы комбинируете их и получаете сложные запросы без раздутых репозиториев.
Плюсы:
- 🧩 Простая композиция правил
- 🔍 Ясный и читаемый код
- ♻️ Повторное использование условий
- 🧪 Лёгкое тестирование
📌 Пример
// Бизнес-правило: активные клиенты с заказами за последние 30 дней
public sealed class ActiveCustomersSpec : Specification<Customer>
{
public ActiveCustomersSpec(DateTime since)
{
Criteria = c => c.IsActive && c.Orders.Any(o => o.CreatedAt >= since);
AddInclude(c => c.Orders);
}
}
// Применение
var spec = new ActiveCustomersSpec(DateTime.UtcNow.AddDays(-30));
var customers = await db.Set<Customer>().Apply(spec).ToListAsync();
💡 Итог:
EF Core = уже Repository + UoW
Репозитории поверх EF Core → лишняя абстракция
Specification Pattern → гибкость и читаемость без «метод-монстров»ProductStock здесь явно не равен null?
Код:
private static IEnumerable<Error> VerifyProductQuantities(
List<ProductStock> products,
Dictionary<string, Domain.Entities.ProductStock> stocks)
{
foreach (var product in products)
{
if (!stocks.TryGetValue(product.ProductName, out var stock))
{
yield return StockErrors.ProductNotFound(product.ProductName);
}
if (stock.AvailableQuantity < product.Quantity)
{
yield return StockErrors.InsufficientStocks(
product.ProductName, product.Quantity, stock.AvailableQuantity);
}
}
}
Компилятор выдет: «Dereference of a possibly null reference» для переменной stock.
Почему так происходит?
• Метод TryGetValue возвращает false, и тогда stock остаётся равным null.
• Даже если мы отфильтровали это через if (!TryGetValue(...)), компилятор не гарантирует, что в блоке после условия stock точно не null.
• В результате в строке if (stock.AvailableQuantity < product.Quantity) возникает предупреждение.
Как исправить?
1. Добавить continue после yield return внутри блока if (!TryGetValue(...)). Тогда компилятор поймёт, что кода после этой ветки для null не будет.
2. Либо использовать оператор !:
if (stock!.AvailableQuantity < product.Quantity) — но это безопасно только если мы уверены, что значение точно не null.
3. Более читаемый вариант — переписать логику так, чтобы работа с stock была строго в ветке, где оно гарантированно задано.
Вопрос для проверки понимания nullable reference types и поведения компилятора при анализе путей выполнения кода.SELECT до оптимизации запросов и реальных кейсов.
🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course
Сохраняй, проходи и прокачивай SQL 💡List<T>.Find() → O(n) — медленно на больших объёмах
- ✅ Dictionary<K,V> → O(1) — быстрый доступ
2. Вставка в начало списка
- List<T>.Insert(0, item) → O(n) — сдвигает все элементы
- ✅ LinkedList<T> → O(1) — мгновенная вставка
3. Уникальные элементы
- List<T> + Contains() → O(n) на каждую проверку
- ✅ HashSet<T> → O(1) — уникальность проверяется сразу
4. Упорядоченные данные
- List<T> + Sort() → O(n log n) и нужен свой поиск
- ✅ SortedDictionary<K,V> → встроенный порядок и быстрый поиск
5. Кэширование API-ответов
- Static Dictionary → риск утечек памяти и «зависших» данных
- ✅ MemoryCache → встроенная очистка и управление временем жизни
💡 Итог: чаще всего не нужны «хитрые оптимизации». Достаточно выбрать правильную коллекцию — и производительность вырастет кратно.
👉 Вопрос к вам: какая самая серьёзная проблема с производительностью у вас решилась заменой структуры данных?List<T>.Find() → O(n) — медленно на больших объёмах
- ✅ Dictionary<K,V> → O(1) — быстрый доступ
2. Вставка в начало списка
- List<T>.Insert(0, item) → O(n) — сдвигает все элементы
- ✅ LinkedList<T> → O(1) — мгновенная вставка
3. Уникальные элементы
- List<T> + Contains() → O(n) на каждую проверку
- ✅ HashSet<T> → O(1) — уникальность проверяется сразу
4. Упорядоченные данные
- List<T> + Sort() → O(n log n) и нужен свой поиск
- ✅ SortedDictionary<K,V> → встроенный порядок и быстрый поиск
5. Кэширование API-ответов
- Static Dictionary → риск утечек памяти и «зависших» данных
- ✅ MemoryCache → встроенная очистка и управление временем жизни
💡 Итог: чаще всего не нужны «хитрые оптимизации». Достаточно выбрать правильную коллекцию — и производительность вырастет кратно.
👉 Вопрос к вам: какая самая серьёзная проблема с производительностью у вас решилась заменой структуры данных?
# Этап сборки
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish
# Этап финального образа
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]
💡 Преимущества:
- минимальный размер финального контейнера,
- быстрый запуск без SDK, только рантайм,
- меньше уязвимостей благодаря облегчённому окружению.
@csharp_ciIExceptionHandler в .NET 8+ через switch`-выражение и сервис `IProblemDetailsService.
internal sealed class GlobalExceptionHandler(
IProblemDetailsService problemDetailsService,
ILogger<GlobalExceptionHandler> logger) : IExceptionHandler
{
public async ValueTask<bool> TryHandleAsync(
HttpContext httpContext,
Exception exception,
CancellationToken cancellationToken)
{
logger.LogError(exception, "Unhandled exception occurred");
httpContext.Response.StatusCode = exception switch
{
ApplicationException => StatusCodes.Status400BadRequest,
_ => StatusCodes.Status500InternalServerError
};
return await problemDetailsService.TryWriteAsync(new ProblemDetailsContext
{
HttpContext = httpContext,
Exception = exception,
ProblemDetails = new ProblemDetails
{
Type = exception.GetType().Name,
Title = "An error occured",
Detail = exception.Message
}
});
}
}
📌 Что тут важно:
- switch по типу исключения для назначения статуса ответа
- IProblemDetailsService для единообразного формирования ответа
- Логгирование всех необработанных ошибок
🔥 Такой подход делает код чище, централизует обработку ошибок и избавляет от дублирования в middleware.