es
Feedback
Библиотека шарписта | C#, F#, .NET, ASP.NET

Библиотека шарписта | C#, F#, .NET, ASP.NET

Ir al canal en Telegram

Все самое полезное для C#-разработчика в одном канале. По рекламе: @proglib_adv Учиться у нас: https://proglib.io/w/b60af5a4 Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/67a5c81cdc130259d5b7fead

Mostrar más

📈 Análisis del canal de Telegram Библиотека шарписта | C#, F#, .NET, ASP.NET

El canal Библиотека шарписта | C#, F#, .NET, ASP.NET (@csharpproglib) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 21 866 suscriptores, ocupando la posición 6 212 en la categoría Tecnologías y Aplicaciones y el puesto 30 851 en la región Rusia.

📊 Métricas de audiencia y dinámica

Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 21 866 suscriptores.

Según los últimos datos del 10 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -87, y en las últimas 24 horas de -4, conservando un alto alcance.

  • Estado de verificación: No verificado
  • Tasa de interacción (ER): El promedio de interacción de la audiencia es 12.06%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 7.04% de reacciones respecto al total de suscriptores.
  • Alcance de las publicaciones: Cada publicación recibe en promedio 2 638 visualizaciones. En el primer día suele acumular 1 540 visualizaciones.
  • Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 8.
  • Intereses temáticos: El contenido se centra en temas clave como .net, шарписта, навигация, await, string.

📝 Descripción y política de contenido

El autor describe el recurso como un espacio para expresar opiniones subjetivas:
Все самое полезное для C#-разработчика в одном канале. По рекламе: @proglib_adv Учиться у нас: https://proglib.io/w/b60af5a4 Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/67a5c81cdc130259d5b7fead

Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 11 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.

21 866
Suscriptores
-424 horas
-167 días
-8730 días
Archivo de publicaciones
⚡️ Синхронная коммуникация: HTTP/REST и gRPC Когда мы говорим о взаимодействии между сервисами, первое, что приходит в голову — синхронный вызов. Один сервис спрашивает, другой отвечает. Просто, понятно, привычно. Разберёмся, какие инструменты есть в .NET и когда каждый из них уместен. HTTP/REST — разумный дефолт Большинство проектов начинается именно с REST. Низкий порог входа, понятная отладка через браузер или Postman, огромная экосистема. В .NET для этого используют HttpClient через IHttpClientFactory. Создание нового HttpClient на каждый запрос — классическая ошибка, которая приводит к исчерпанию сокетов под нагрузкой.
builder.Services.AddHttpClient<IOrderService, OrderService>(client =>
{
    client.BaseAddress = new Uri("https://orders-api/");
    client.DefaultRequestHeaders.Add("Accept", "application/json");
    client.Timeout = TimeSpan.FromSeconds(30);
});

public class OrderService(HttpClient client) : IOrderService
{
    public async Task<Order?> GetAsync(Guid id, CancellationToken ct)
    {
        var response = await client.GetAsync($"orders/{id}", ct);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadFromJsonAsync<Order>(ct);
    }
}
Сразу добавляйте Polly для повторных попыток и circuit breaker. Без этого первый же временный сбой соседнего сервиса положит весь флоу. Когда не стоит использовать: если между сервисами тысячи вызовов в секунду с жёсткими требованиями по latency — смотрите в сторону gRPC. gRPC — когда миллисекунды на счету gRPC работает поверх HTTP/2, использует бинарную сериализацию через Protocol Buffers и генерирует типизированный клиент из .proto-файла. Это означает меньше трафика, меньше CPU на сериализацию и строгий контракт, нарушение которого не скомпилируется.
// orders.proto
service Orders {
  rpc GetOrder (OrderRequest) returns (OrderReply);
}
message OrderRequest { string id = 1; }
message OrderReply   { string id = 1; string status = 2; }

// в сервисе
builder.Services.AddGrpcClient<OrdersClient>(o =>
    o.Address = new Uri("https://orders-grpc-service"));

public class OrderHandler(OrdersClient grpc)
{
    public async Task<OrderReply> Handle(GetOrderQuery q, CancellationToken ct)
        => await grpc.GetOrderAsync(
               new OrderRequest { Id = q.Id.ToString() },
               cancellationToken: ct);
}
Подводный камень: не тащите gRPC туда, где достаточно REST. Если у вас 10 запросов в минуту — вы просто добавите сложность без выигрыша в производительности. Публичный API или фронтенд — REST без вариантов. Internal-сервисы с высокой нагрузкой и строгим контрактом — gRPC. Если сомневаетесь — начните с REST, профилируйте, и переходите на gRPC там, где это реально болит. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #il_люминатор

💿 S.M.A.R.T. уже знает, что с вашим диском Диск умирает тихо. Сначала один переназначенный сектор, потом десять, потом в оди
💿 S.M.A.R.T. уже знает, что с вашим диском Диск умирает тихо. Сначала один переназначенный сектор, потом десять, потом в один прекрасный день файлы просто не открываются. Хорошо, если это была музыка. Плохо, если рабочие документы за три года. Как давно вы проверяли свои файловые хранилища? Как раз вышла новая версия CrystalDiskInfo. Ничего революционного — но повод скачать актуальную сборку и наконец запустить её. ➡️ Проверить диск 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #async_news

🆚 Микросервисная архитектура vs Монолит Монолит — это традиционный подход к разработке, где всё приложение представляет собой единое целое. Весь код, бизнес-логика, UI и доступ к данным находятся в одном проекте и деплоятся как единая единица. Микросервисы — это архитектурный подход, при котором приложение разбивается на набор небольших, независимых сервисов. Каждый сервис отвечает за конкретную бизнес-функцию, имеет свою базу данных и может разрабатываться, деплоиться и масштабироваться независимо. Каждый сервис — это отдельное .NET приложение (мини-монолит) со своей БД, API и бизнес-логикой. Ключевые отличия ➡️ Структура и организация кода Монолит: • Один репозиторий, один проект • Общие зависимости для всех модулей • Прямые вызовы методов между компонентами Микросервисы: • Множество репозиториев или монорепозиторий • Независимые зависимости для каждого сервиса • Коммуникация через API: HTTP, gRPC, сообщения ➡️ Развертывание Монолит: • Деплой всего приложения целиком • Один сервер или кластер серверов • Простая инфраструктура Микросервисы: • Независимый деплой каждого сервиса • Контейнеризация и оркестрация • Сложная инфраструктура с API Gateway, Service Discovery ➡️ Масштабирование Монолит: • Вертикальное масштабирование — увеличение ресурсов сервера • Горизонтальное масштабирование всего приложения • Неэффективно, если нагрузка только на одну функцию Микросервисы: • Горизонтальное масштабирование конкретных сервисов • Масштабируются только те части, которым нужно • Оптимизация затрат на инфраструктуру ➡️ База данных Монолит: • Одна общая база данных • ACID транзакции работают нативно • Простота в управлении данными Микросервисы: • База данных на каждый сервис • Распределенные транзакции • Eventual Consistency ➡️ Технологический стек Монолит: • Единый стек технологий • Сложно внедрить новые технологии • Один язык программирования Микросервисы: • Каждый сервис может использовать свой стек • Гибкость в выборе технологий • Можно смешивать .NET, Node.js, Python и др. Микросервисы — не серебряная пуля, а инструмент для решения конкретных проблем масштаба и сложности. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #il_люминатор

😊 Менторство на работе Вас просят поменторить нового разработчика. Давайте разберемся, когда это возможность, а когда — скры
😊 Менторство на работе Вас просят поменторить нового разработчика. Давайте разберемся, когда это возможность, а когда — скрытая эксплуатация. Идеальная ситуация Компания доплачивает 15-20% к зарплате, джун быстро схватывает и задает умные вопросы. Вы получаете деньги, прокачиваете скилл объяснения. Все в плюсе. Ловушка «помоги новенькому» «Покажи, как тут все устроено» может быть и без доплаты, без официального оформления. Вы делаете две работы за одну зарплату. Времени уходит 5-10 часов в неделю, дедлайны остаются прежними. Через месяц выгорание и раздражение на джуна, хотя он не виноват. Выход: либо официальное оформление с корректировкой нагрузки, либо вежливое «сейчас не могу взять это на себя». Человек не понимает базовых вещей после третьего объяснения, не гуглит, не пытается разобраться сам. Вы превращаетесь в костыль, каждый вопрос съедает время, а прогресса нет. Проблема часто не в способностях, а в мотивации или ошибке на этапе найма. Честный разговор с лидом — это нормально. Менторство работает при наличии базы и желания учиться. Если база нулевая, это провал рекрутинга, не ваша ответственность. 💬 Менторили джунов? Как у вас это происходило? Делитесь в комментах 👇 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #entry_point

🌐 Forward или Reverse Proxy Forward и Reverse прокси звучат похоже — оба это прокси. Но работают в противоположных направлениях и решают разные задачи. Давайте разберёмся. ➡️ Forward Proxy Представьте, что вы хотите отправить письмо, но не хотите раскрывать свой обратный адрес. Вы отдаёте письмо посреднику. Он отправляет его от своего имени. Получатель видит адрес посредника, а не ваш. Forward прокси — это посредник между вами и интернетом. Главное: целевой сервер не знает, что запрос пришёл от вас. Он видит только прокси. Зачем его используют: • Логирование всех запросов • Блокировка нежелательных сайтов • Экономия трафика через кеширование • Контроль безопасности ➡️ Reverse Proxy — противоположная история Теперь представьте большую компанию с множеством отделов. Когда кто-то звонит в компанию, он попадает на секретаря. Секретарь решает, в какой отдел перенаправить звонок. Звонящий не знает внутреннюю структуру компании. Он общается только с секретарём. Reverse прокси — это секретарь для ваших серверов. Клиент не знает, что за прокси находятся несколько серверов. Он видит только один публичный адрес. ➡️ Реальные примеры использования 1. Балансировка нагрузки У вас 5 серверов с одним приложением:
Клиент → Reverse Proxy → [Сервер 1] → [Сервер 2] → [Сервер 3] → [Сервер 4] → [Сервер 5]
Прокси распределяет запросы между серверами, чтобы ни один не был перегружен. 2. Единая точка входа У вас микросервисная архитектура: • API на порту 5000 • Frontend на порту 3000 • Админ-панель на порту 8080 • WebSocket сервер на порту 4000 Без reverse прокси пользователю нужно знать все эти порты. А с reverse прокси можно сделать так:
https://mysite.com/api → Сервер на :5000 https://mysite.com/ → Сервер на :3000 https://mysite.com/admin → Сервер на :8080 https://mysite.com/ws → Сервер на :4000
3. SSL/TLS Вместо настройки HTTPS на каждом сервере, настраиваете один раз на прокси. Проще управлять сертификатами, меньше нагрузка на бэк. 4. Защита и безопасность Внутренние серверы вообще не видны из интернета. Видна только прокси. 5. Кеширование Статический контент: картинки, CSS и JS; можно кешировать на прокси. Не нужно каждый раз обращаться на бэк. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #sharp_view

❓ Тематика следующей недели
Anonymous voting

🔄 Дайджест недели Коротко про события недели. — Microsoft разрабатывает функцию перемещения панели задач в Windows 11 Функци
🔄 Дайджест недели Коротко про события недели. — Microsoft разрабатывает функцию перемещения панели задач в Windows 11 Функция ожидается летом 2026 года как часть усилий по улучшению репутации ОС. — Linux 6.19Превью .NET 11Бустим рабочее место за 10 шагов 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #async_news

📎 Пропущенный аудит Метод ExecuteUpdate в EF Core ускоряет массовые обновления, но пропускает перехватчики и события SaveChanges. Это может сломать аудит изменений. Перехватчик SaveChanges ловит изменения из трекера. Но ExecuteUpdate работает напрямую с БД и игнорирует его:
public override async Task<int> SaveChangesAsync(CancellationToken ct = default)
{
    // Захватывает изменения от SaveChanges
    var entries = ChangeTracker.Entries()
        .Where(e => e.State == EntityState.Modified);
    
    // Но не от ExecuteUpdate!
}
Решение через ручной аудит Добавляйте аудит вручную перед или после ExecuteUpdate:
await context.Products
    .Where(p => p.CategoryId == categoryId)
    .ExecuteUpdateAsync(s => s
        .SetProperty(p => p.Price, newPrice)
        .SetProperty(p => p.ModifiedAt, DateTime.UtcNow)
        .SetProperty(p => p.ModifiedBy, currentUser));

// Отдельная запись аудита
context.AuditLogs.Add(new AuditLog
{
    Action = "BulkPriceUpdate",
    EntityType = "Product",
    Details = $"Обновил CategoryId={categoryId}, цена={newPrice}"
});
await context.SaveChangesAsync();
Альтернативы для полного аудита • Триггеры на уровне БД ловят все изменения, включая ExecuteUpdate. Минус — сложнее тестировать и отлаживать. • Библиотеки расширения EF предлагают BulkUpdate с встроенным аудитом через опции UseAudit. 📍 Навигация: ВакансииЗадачиСобесы 🐸Библиотека шарписта #sharp_view

⚡️ C# убил Builder для простых случаев Target-typed new убирает дублирование типов при инициализации, а with-выражения делают иммутабельные обновления одной строкой кода. Раньше при создании объекта приходилось дважды писать тип: var user = new UserDto { ... }. Теперь достаточно User user = new() { ... }. Компилятор выводит тип из контекста — при возврате из методов, в параметрах, элементах коллекций Работа с иммутабельными объектами традиционно требовала copy-конструкторов, Builder'а или AutoMapper. with-выражение создаёт поверхностную копию с изменением указанных свойств: var updated = user with { Age = 31 }. Компилятор генерирует код копирования автоматически. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #sharp_view

Собираем фулл-хаус: 3 курса по цене 1 Хватит выбирать между «полезно», «модно» и «для души». Мы запустили механику, которая п
Собираем фулл-хаус: 3 курса по цене 1 Хватит выбирать между «полезно», «модно» и «для души». Мы запустили механику, которая позволяет собрать кастомный стек навыков без удара по бюджету: покупаете один курс — два других забираете бесплатно. В Enterprise ценится фундаментальность. Углубитесь в архитектуру и шаблоны проектирования для построения сложных систем или подтяните алгоритмы и структуры данных для технических интервью. Для тех, кто хочет понимать математику ML-моделей (вне зависимости от языка) — полный набор по AI: от линала и ML-старта до разработки автономных агентов. Ну и классика: обновлённый Python как второй язык для скриптов. Собрать свой пак

👨‍💻 Span<T> как ref struct Разбираем вопрос с собеса, в этот раз про Span. Span<T> даёт доступ к памяти без копий и аллокаций. Но почему его сделали ref struct с кучей запретов, и когда лучше взять Memory<T>? Ответ лежит в нашем канале с вопросами с собесов 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #dotnet_challenge

🧑‍💻 Когда чистый код всё равно требует комментариев Чистый код делает программу понятной без лишних объяснений. Но иногда к
🧑‍💻 Когда чистый код всё равно требует комментариев Чистый код делает программу понятной без лишних объяснений. Но иногда комментарии необходимы, чтобы передать суть решений, которые не уместить в самих строках. Роберт Мартин в книге «Чистый код» не запрещает комментарии полностью. Он против тех, что дублируют очевидное или устаревают со временем. Когда комментарии спасают ситуацию • Сложная логика или хак:
// Обход бага в IE11 с обработкой форм
if (isIE11()) {
    polyfillFormSubmit();
}
• Предупреждения о рисках:
// Не трогать: изменение сломает кэш в проде до деплоя новой версии
cache.invalidateOnlyOnRestart();
• Указание на патенты, стандарты или тикеты в баг-трекере. 💬 Когда, по вашему мнению, ещё могут пригодиться комментарии в коде 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #il_люминатор

📂 File-Scoped Namespaces Cинтаксис file-scoped namespaces заменяет привычное объявление пространства имён со скобками на одн
📂 File-Scoped Namespaces Cинтаксис file-scoped namespaces заменяет привычное объявление пространства имён со скобками на однострочное с точкой с запятой. Раньше каждый файл в C# проекте начинался с namespace MyApp.Services { ... }, что добавляло один уровень отступа ко всему коду внутри. Теперь достаточно написать namespace MyApp.Services; в начале файла, и всё содержимое автоматически находится в этом пространстве имён без дополнительной вложенности. Код становится более плоским. Вместо того чтобы начинать каждый класс с двух уровней отступа: namespace + class, вы сразу работаете с одним. При рефакторинге, когда нужно переместить класс в другой namespace, старый подход требовал изменения строки с объявлением. В git diff это выглядело как замена всего файла, даже если логика класса не менялась. C новым подходом меняется только одна строка вверху. Компилятор не видит разницы — это чисто синтаксический сахар. IL-код идентичен, производительность не меняется. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #sharp_view

🧑‍💻 Композиция функций в C# Функциональное программирование — не просто академическая теория. Это парадигма, превращающая императивный спагетти-код в декларативные, тестируемые и поддерживаемые решения. Проблема императивного кода:
// Традиционный подход - может быть трудно читать и сложно тестировать
public OrderDto ProcessOrder(int orderId)
{
    var order = _dbContext.Orders.Find(orderId);
    if (order == null) throw new NotFoundException();
    
    if (order.Status != "Pending") 
        throw new InvalidOperationException();
    
    var customer = _dbContext.Customers.Find(order.CustomerId);
    if (!customer.IsActive) 
        throw new InvalidOperationException();
    
    var discount = customer.IsVip ? 0.1m : 
                   order.Total > 1000 ? 0.05m : 0m;
    
    order.FinalTotal = order.Total * (1 - discount);
    _dbContext.SaveChanges();
    
    return new OrderDto { ... };
}
Проблемы: смешанные обязанности, жёсткая связанность с БД, невозможность переиспользования, хрупкость при изменениях. Композиционное решение:
public class OrderProcessingPipeline
{
    private readonly Func<int, Task<Order?>> _loadOrder;
    private readonly Func<Order, Task<Customer?>> _loadCustomer;
    
    public async Task<Result<OrderDto, Error>> ProcessAsync(int orderId)
    {
        return await Result<Order, Error>
            .FromNullable(await _loadOrder(orderId), Error.OrderNotFound)
            .BindAsync(_loadCustomer)
            .BindAsync(_validateStatus)
            .BindAsync(_calculateDiscount)
            .BindAsync(_persistOrder)
            .MapAsync(_mapToDto);
    }
}
Преимущества: единственная ответственность каждой функции, простота тестирования, композируемость, декларативный флоу. Основа композиции — чистые функции без побочных эффектов:
public static class PricingFunctions
{
    public static decimal CalculateDiscount(CustomerType type, decimal total) => 
        type switch
        {
            CustomerType.Vip => total * 0.15m,
            CustomerType.Premium => total * 0.10m,
            _ => 0m
        };
    
    public static decimal ApplyTax(decimal amount, decimal rate) => 
        amount * (1 + rate);
    
    // Композиция
    public static Func<CustomerType, decimal, decimal> CalculateFinalPrice => 
        (type, total) => ApplyTax(total - CalculateDiscount(type, total), 0.08m);
}
Тест такой функции:
[Theory]
[InlineData(CustomerType.Vip, 1000, 918.00)]
public void CalculateFinalPrice_ReturnsExpected(CustomerType type, decimal total, decimal expected)
{
    Assert.Equal(expected, PricingFunctions.CalculateFinalPrice(type, total));
}
Начните с малого: замените один цикл на Map, один if/throw на Result. Паттерны быстро станут естественными, и ваша кодовая база скажет спасибо. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #il_люминатор

🌼 Бустим рабочее место за 10 шагов Удаленка — это не только про свободу выбора места работы, но и про умение создать условия
+5
🌼 Бустим рабочее место за 10 шагов Удаленка — это не только про свободу выбора места работы, но и про умение создать условия для продуктивности. ➡️ В карточках 5 советов по обустройству рабочего места, а остальные в статье. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта

📂 File-Scoped Namespaces Cинтаксис file-scoped namespaces заменяет привычное объявление пространства имён со скобками на одн
📂 File-Scoped Namespaces Cинтаксис file-scoped namespaces заменяет привычное объявление пространства имён со скобками на однострочное с точкой с запятой. Раньше каждый файл в C# проекте начинался с namespace MyApp.Services { ... }, что добавляло один уровень отступа ко всему коду внутри. Теперь достаточно написать namespace MyApp.Services; в начале файла, и всё содержимое автоматически находится в этом пространстве имён без дополнительной вложенности. Код становится более плоским. Вместо того чтобы начинать каждый класс с двух уровней отступа: namespace + class, вы сразу работаете с одним. При рефакторинге, когда нужно переместить класс в другой namespace, старый подход требовал изменения строки с объявлением. В git diff это выглядело как замена всего файла, даже если логика класса не менялась. C новым подходом меняется только одна строка вверху. Компилятор не видит разницы — это чисто синтаксический сахар. IL-код идентичен, производительность не меняется. 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #sharp_view

📷 Подборка вакансий для шарпистов C#/.NET разработчик — 265 000 ₽. Удалёнка Middle/Senior .NET Developer — от 3 000 до 3 500 $. Удалёнка C#/.NET-разработчик — Удалёнка ➡️ Еще больше топовых вакансий — в нашем канале C# Jobs 🐸 Библиотека шарписта

⚡️ Почему IQueryable не должен покидать слой данных Разработчики используют EF Core и передают IQueryable по всему приложению, считая это эффективным подходом. Но такая практика создаёт серьёзные проблемы с архитектурой и сопровождением кода. IQueryable позволяет строить динамические SQL-запросы, выполняя фильтрацию на стороне БД, а не в памяти приложения:
var startDate = new DateTime(2023, 1, 1);

// Плохо: загружаем всё в память, затем фильтруем
var allRecords = context.Purchases.ToList();
var filtered = allRecords.Where(p => p.Date > startDate).ToList();

// Хорошо: фильтрация выполняется базой данных
var filtered = context.Purchases
    .Where(p => p.Date > startDate)
    .ToList();
Второй подход быстрее и эффективнее. Но когда IQueryable начинает путешествовать через слои приложения, возникают проблемы. Антипаттерн: распространение IQueryable. Типичный сценарий — IQueryable передаётся через слои:
// Репозиторий
public class PurchaseRepository
{
    public IQueryable<Purchase> GetAll() => 
        _context.Purchases.AsQueryable();
}

// Сервис бизнес-логики
public class PurchaseService
{
    public IQueryable<Purchase> GetActive() => 
        _repository.GetAll().Where(p => p.Status == "Active");
}

// Контроллер
var userPurchases = _service.GetActive()
    .Where(p => p.UserId == currentUserId);

// Представление
@foreach(var item in Model.Where(p => p.IsCompleted)) 
{
    <!-- рендеринг -->
}
Проблемы: • Логика доступа к данным размазана по всему приложению • Нарушен принцип единственной ответственности • IQueryable наследует IEnumerable — код может не знать, что работает с запросом к БД • Исключения в runtime, если EF не может преобразовать код в SQL • Сложное тестирование и отладка Решить эти проблемы можно, к примеру, паттерном спецификация, или, если спецификации избыточны, передавайте выражения:
public interface IPurchaseRepository
{
    Task<List<Purchase>> FindAsync(Expression<Func<Purchase, bool>> predicate);
}

// Использование
var purchases = await _repository.FindAsync(
    p => p.IsCompleted && p.UserId == currentUserId);
Запрос по-прежнему выполняется в БД, но логика доступа к данным инкапсулирована. 💬 Как бы вы решили эту проблему 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #sharp_view

🤩 Свежее превью .NET Microsoft выпустила первую предварительную версию .NET 11 с улучшениями во всех областях: рантайм, SDK,
🤩 Свежее превью .NET Microsoft выпустила первую предварительную версию .NET 11 с улучшениями во всех областях: рантайм, SDK, библиотеки, C#, ASP.NET Core, Blazor и .NET MAUI. ➡️ Библиотеки • Поддержка Zstandard compression для эффективного сжатия • BFloat16 — новый тип с плавающей точкой для ML-сценариев • Улучшения ZipArchiveEntry для работы с архивами • FrozenDictionary теперь поддерживает collection expressions ➡️ API и утилиты: • Расширенная поддержка Rune в String, StringBuilder и TextWriter • MediaTypeMap для определения MIME-типов • API верификации HMAC и KMAC • Создание жёстких ссылок • DivisionRounding для режимов целочисленного деления • Happy Eyeballs в Socket.ConnectAsync для быстрого подключения по IPv4/IPv6 ➡️ Рантайм • Runtime Async — улучшенная асинхронность на уровне рантайма • CoreCLR на WebAssembly — полноценный рантайм в браузере • Расширение интерпретатора • JIT-оптимизации производительности • GC Heap Hard Limit для 32-битных процессов • Поддержка архитектур RISC-V и s390x ➡️ SDKdotnet run теперь интерактивно выбирает целевой фреймворк и устройство • dotnet test поддерживает позиционные аргументы • dotnet watch — горячая перезагрузка для изменений в ссылках и настраиваемые порты ➡️ C# и F# • C#: передача коллекций как аргументов • C# расширенная поддержка раскладки памяти • F#: параллельная компиляция включена по умолчанию, ускорение компиляции вычислительных выражений, новые флаги --disableLanguageFeature и --typecheck-only для FSI. ➡️ Блог разработчиков 📍 Навигация: ВакансииЗадачиСобесы 🐸 Библиотека шарписта #async_news