День 2517. #TipsAndTricks
ToArrayAsync или ToListAsync в Entity Framework?
Очевидно, каждый из методов нужно использовать в подходящей для него ситуации. Но если это не важно, какой лучше? Короткий ответ: ToListAsync.

Посмотрим код. ToListAsync реализован следующим образом:

public static async Task<List<TSource>>
 ToListAsync<TSource>(
  this IQueryable<TSource> source,
  CancellationToken cancellationToken = default)
{
  var list = new List<TSource>();
  await foreach (var element in
   source
    .AsAsyncEnumerable()
    .WithCancellation(cancellationToken)
    .ConfigureAwait(false))
  {
    list.Add(element);
  }

  return list;
}

См. источник

А ToArrayAsync реализован так:

public static async Task<TSource[]>
 ToArrayAsync<TSource>(
  this IQueryable<TSource> source,
  CancellationToken cancellationToken = default)
 => (
  await source
   .ToListAsync(cancellationToken)
   .ConfigureAwait(false))
  .ToArray();

См. источник

Таким образом, ToArrayAsync сначала вызывает ToListAsync, а затем преобразует полученный список в массив с помощью ToArray(). В результате возникают накладные расходы на создание списка, его заполнение, а затем создание массива и копирование элементов.

Это не относится к ToHashSetAsync, он реализован аналогично ToListAsync.

Источник: https://steven-giesel.com/blogPost/55dbb67c-cd14-444f-81e8-dec9f5ce1448/one-minute-knowledge-is-toarrayasync-or-tolistasync-faster-for-entity-framework

День 2518. #ЗаметкиНаПолях
Мигрируем на Новый Формат Файлов Решений
Новый формат файлов решений в .NET .slnx появился довольно давно, я уже писал про него. И хотя он до сих пор, по какой-то причине находится в стадии превью, уже сейчас можно обновлять свои решения на новый формат.

Проблема
Классические файлы .sln многословны: записи проекта с большим количеством GUID + блоки конфигурации, которые разрастаются по мере роста вашего решения. Это также частый источник конфликтов слияния.

Новый формат .slnx по сути просто перечисляет проекты решения в формате XML. Он похож на файл .csproj. Гораздо компактнее, понятнее и удобнее в использовании.

Как выполнить миграцию?
Формат .slnx доступен в последних версиях Visual Studio 2022 (v17.13+) и SDK .NET9+. Вот как вы можете перейти на него.

1. Терминал
Если у вас установлен SDK .NET версии 9.0.200 или более поздней, вы можете выполнить миграцию мгновенно через CLI.
- Откройте терминал в папке решения.
- Выполните команду миграции:

dotnet sln migrate

Это создаст новый файл .slnx рядом со старым файлом .sln.
На этом этапе лучше удалить старый файл .sln, чтобы избежать путаницы. Нет смысла хранить оба файла в одном репозитории.

2. Сохранение из Visual Studio
Если вы предпочитаете графический интерфейс, вы можете сделать это непосредственно в Visual Studio 2022 (или 2026).
- Выберите решение в обозревателе решений.
- Перейдите в меню File > Save Solution As… (Файл > Сохранить решение как…).
- Выберите в раскрывающемся списке Save as type (Тип файла) тип Xml Solution File (*.slnx).

Зачем мигрировать?
1. Меньше конфликтов слияния: главное преимущество. Поскольку файл представляет собой простой XML-файл без случайных изменяющихся GUID, слияние в Git становится тривиальным.

2. Удобочитаемость: Вы можете открыть этот файл в блокноте, понять его и отредактировать, не нарушая всю сборку.

3. Согласованность: Наконец-то формат решения приведён в соответствие с форматом проекта (.csproj), который несколько лет назад также был серьёзно упрощён.

4. Производительность: Меньший размер файлов и более простой анализ означают немного более быструю загрузку для масштабных решений.

Можно ли использовать в проде?
По состоянию на конец 2025 - начало 2026 года, .slnx технически остаётся превью-функцией.

Безопасно ли использовать?
Да, формат стабилен.

Поддержка инструментов
Visual Studio 2022, Visual Studio 2026 и Rider хорошо его поддерживают. То же самое относится и к .NET CLI. Некоторые старые конвейеры CI/CD или сторонние инструменты могут пока не распознавать это расширение. Сначала попробуйте его на стороннем проекте или ветке. Если ваш конвейер CI/CD успешно будет с ним работать, то всё отлично.

Источник: https://www.milanjovanovic.tech/blog/the-new-slnx-solution-format-migration-guide

День 2519. #ЗаметкиНаПолях
Разбираем Server-Sent Events в ASP.NET Core и .NET 10. Начало
Обновления UI в реальном времени больше не являются "желательной" функцией. Большинство современных приложений ожидают потоков данных в реальном времени от сервера. В течение многих лет основным решением в экосистеме .NET был SignalR. Хотя он невероятно мощный, приятно иметь другие варианты для более простых сценариев использования.

В ASP.NET Core 10 появился собственный высокоуровневый API для событий, отправляемых сервером (SSE). Он устраняет разрыв между базовым HTTP-опросом и полнодуплексными WebSockets через SignalR.

Зачем?
SignalR — мощный инструмент, который автоматически обрабатывает WebSockets, Long Polling и SSE, обеспечивая полнодуплексный (двусторонний) канал связи. Однако это сопряжено с определёнными затратами: специфический протокол, необходимость в клиентской библиотеке и потребность в «липких сессиях» или бэкэнде (например, Redis) для масштабирования.

В отличие от SignalR, SSE:
- Однонаправленные - разработаны специально для потоковой передачи данных с сервера на клиент.
- Нативны для HTTP - это стандартный HTTP-запрос с типом содержимого text/event-stream. Никаких пользовательских протоколов.
- Поддерживают автоматическое переподключение - браузеры обрабатывают переподключения напрямую через API EventSource.
- Легковесны - нет тяжёлых клиентских библиотек или сложной логики рукопожатия.

Простейшая конечная точка SSE
Мы можем использовать новый объект Results.ServerSentEvents для возврата потока событий из любого IAsyncEnumerable<T>. Поскольку IAsyncEnumerable представляет собой поток данных, который может поступать с течением времени, сервер знает, что нужно поддерживать HTTP-соединение открытым, а не закрывать его после первого «фрагмента» данных.

Вот минимальный пример конечной точки SSE, которая передаёт информацию о размещении заказов в режиме реального времени:

app.MapGet("orders/realtime", (
  ChannelReader<OrderPlacement> reader,
  CancellationToken ct) =>
{
  // ReadAllAsync возвращает IAsyncEnumerable
  // Results.ServerSentEvents заставляет браузер держать подключение открытым
  // Новые данные передаются клиенту по мере поступления из канала
  return Results.ServerSentEvents(
   reader.ReadAllAsync(ct),
   eventType: "orders");
});

Когда клиент обращается к этой конечной точке:
- Сервер отправляет заголовок Content-Type: text/event-stream.
- Соединение остается активным в состоянии ожидания данных.
- Как только приложение отправляет заказ в канал, IAsyncEnumerable возвращает этот элемент, и .NET немедленно отправляет его по открытому HTTP-каналу в браузер.
Это невероятно эффективный способ обработки «push»-уведомлений без накладных расходов, связанных с протоколом с сохранением состояния.

В этом примере используется канал. В реальном приложении у вас может быть фоновый сервис, прослушивающий очередь сообщений (например, RabbitMQ или Azure Service Bus) или канал изменений БД и отправляющий новые события в канал для обработки подключёнными клиентами.

Продолжение следует…

Источник: https://www.milanjovanovic.tech/blog/server-sent-events-in-aspnetcore-and-dotnet-10

День 2520. #ЗаметкиНаПолях
Разбираем Server-Sent Events в ASP.NET Core и .NET 10. Продолжение
Начало

Обработка пропущенных событий
У простой конечной точки, которую мы создали ранее, есть один недостаток: ей не хватает отказоустойчивости.

Одна из самых больших проблем с потоками в реальном времени — это разрывы соединения. К тому времени, когда браузер автоматически переподключится, несколько событий могут быть уже отправлены и потеряны. Для решения этой проблемы в SSE есть встроенный механизм: заголовок Last-Event-ID. Когда браузер переподключается, он отправляет этот ID обратно на сервер.

В .NET 10 мы можем использовать тип SseItem<T> для добавления метаданных к нашим данным (идентификаторы и интервалы повторных попыток).

Можно создать простой буфер OrderEventBuffer в памяти, содержащий объекты типа SseItem<OrderPlacement>, и методом получения всех объектов после Last-Event-ID, который будет предоставляться браузером. Так мы можем «воспроизвести» пропущенные сообщения при переподключении:

app.MapGet("orders/realtime/with-replays", (
  ChannelReader<OrderPlacement> reader,
  OrderEventBuffer buffer,
  [FromHeader(Name = "Last-Event-ID")] 
  string? lastEventId,
  CancellationToken ct) =>
{
  async IAsyncEnumerable<SseItem<OrderPlacement>> 
   StreamEvents()
  {
    // Повторяем пропущенные события
    if (!string.IsNullOrWhiteSpace(lastEventId))
    {
      var missed = buffer.GetEventsAfter(lastEventId);
      foreach (var m in missed)
        yield return m;
    }

    // Выдаём события по мере их поступления в канал
    await foreach (var order in 
     reader.ReadAllAsync(ct))
    {
      // Буфер назначает уникальный ID
      var sseItem = buffer.Add(order);
      yield return sseItem;
    }
  }

  return TypedResults.ServerSentEvents(
   StreamEvents(), "orders");
});

Окончание следует…

Источник: https://www.milanjovanovic.tech/blog/server-sent-events-in-aspnetcore-and-dotnet-10

День 2521. #ЗаметкиНаПолях
Разбираем Server-Sent Events в ASP.NET Core и .NET 10. Окончание
Начало
Продолжение

Фильтрация SSE по пользователю
SSE построены на основе стандартного HTTP. Поскольку это стандартный GET-запрос, вся существующая инфраструктура «просто работает»:
- Безопасность - вы можете передать стандартный JWT в заголовке Authorization.
- Контекст пользователя - вы можете получить доступ к HttpContext.User, чтобы извлечь идентификатор пользователя и отфильтровать поток. Вы отправляете пользователю только те данные, которые ему принадлежат.

Вот пример конечной точки SSE, которая передаёт потоком только заказы для конкретного пользователя:

app.MapGet("orders/realtime", (
  ChannelReader<OrderPlacement> reader,
  // Внедрённый контекст с метаданными пользователя
  IUserContext context,
  CancellationToken ct) =>
{
  // Реализация IUserContext получает UserId из токена доступа JWT
  var userId = context.UserId;

  async IAsyncEnumerable<OrderPlacement>
   GetUserOrders()
  {
   await foreach (var order in
    reader.ReadAllAsync(ct))
   {
     // Выдаём только данные текущего пользователя
     if (order.CustomerId == userId)
       yield return order;
   }
  }
  
  return TypedResults.ServerSentEvents(
   GetUserOrders(),
   "orders");
})
// Стандартная авторизация ASP.NET
.RequireAuthorization();

Обратите внимание, что при отправке сообщения в канал оно транслируется всем подключённым клиентам (ChannelReader<T>). Это вряд ли подойдёт, когда надо разделять сообщения для каждого пользователя. Поэтому в производственной среде понадобится более надёжная логика.

Обработка SSE в JavaScript
На стороне клиента не нужно устанавливать дополнительных npm-пакетов. Нативный API EventSource браузера берёт на себя основную работу, включая логику «повторного подключения и отправки Last-Event-ID», которую мы рассмотрели в предыдущем посте.

const es =
 new EventSource('/orders/realtime/with-replays');

// Слушаем специальный тип событий 'orders', который определён в коде C# (см. выше)
es.addEventListener('orders', (event) => {
  const payload = JSON.parse(event.data);
  console.log(
   `Новый заказ ${event.lastEventId}:`, payload.data);
});

// При открытии подключения
es.onopen = () => {
  console.log('Connection opened');
};

// Обрабатываем общие сообщения (если есть)
es.onmessage = (event) => {
  console.log('Получено сообщение:', event);
};

// Обрабатываем ошибки и переподключения 
es.onerror = () => {
  if (es.readyState === EventSource.CONNECTING) {
    console.log('Повторное подключение…');
  }
};

Итого
SSE в .NET 10 — это идеальный компромисс для простых односторонних обновлений, таких как панели мониторинга, уведомления и индикаторы выполнения. Они легковесны, работают по протоколу HTTP и легко обеспечивают безопасность с помощью существующего промежуточного ПО.
Однако SignalR остаётся надёжным и проверенным в боевых условиях вариантом для сложных двусторонних коммуникаций или масштабных задач, требующих бэкэнда.
Цель SSE не в замене SignalR, а в предоставлении более простого инструмента для более простых задач. Выбирайте самый простой инструмент, который решает вашу проблему.

Источник: https://www.milanjovanovic.tech/blog/server-sent-events-in-aspnetcore-and-dotnet-10

День 2522. #Карьера
Топ Советов по Повышению Продуктивности. Часть 2
Часть 1

2. Агрессивный таймбоксинг: техника Помодоро для разработчиков (на этот раз действительно работающая)
Да, да, все уже слышали о Помодоро. 25 минут работы, 5 минут перерыва, и так до бесконечности. В теории звучит отлично, а на практике… Вы уже 11 минут сосредоточенно работаете над кодом, когда срабатывает таймер, и вы должны просто… остановиться? На полпути? Когда вы наконец-то вошли в «поток»? Да ни за что!

Тут вот в чём дело: традиционная техника Помодоро не была разработана для творческой работы, требующей глубокой концентрации. Она была создана для продаж и административных задач, где перерывы обходятся дешевле. Разработчикам нужно что-то другое.

Помодоро для разработчиков, или «агрессивный таймбоксинг».
Вместо жестких 25-минутных интервалов используйте таймбоксинг, основанный на естественных границах работы, и поддерживайте строгие правила относительно того, что происходит, когда таймер достигает нуля.

Шаг 1: Определите конкретную, выполнимую задачу. Не «работать над функцией аутентификации», а «реализовать промежуточное ПО для проверки JWT». Что-то, что вы можете закончить или промежуточный этап, на котором сможете чётко остановиться.

Шаг 2: Честно оцените время. Это займёт 30 минут? 45? 90? Будьте реалистичны. Добавьте 25% к тому, что подсказывает интуиция, потому что вы, вероятно, недооцениваете.

Шаг 3: Установите таймер и начните. Важно: не останавливайтесь, когда срабатывает таймер. Вместо этого оцените результат:
- Вы «в потоке»? Добавьте ещё один временной интервал и продолжайте.
- Застряли? Это естественная точка остановки. Сделайте перерыв.
- Слишком часто переключаетесь между задачами? Таймер вас поймал — признайте, что выбились из рабочего ритма, перефокусируйтесь или сделайте перерыв.

Шаг 4: После 2-3 последовательных временных интервалов (90-120 минут) сделайте настоящий перерыв. Не перерыв для проверки мессенджеров. Прогуляйтесь по офису или выйдите на улицу, по-настоящему отключитесь от работы.

Главное: Отслеживайте каждый временной интервал в простом документе. Записывайте, над чем вы работали и закончили ли. Это создаёт подотчетность и, что более важно, данные. Через неделю вы увидите закономерности:
- заметите, что всегда недооцениваете работу с БД на 40%;
- увидите, что дневные/вечерние временные интервалы менее продуктивны.
У вас будут реальные доказательства для улучшения планирования.

Настоящая польза: дело не в таймере или перерывах. Дело в осознании того, как вы работаете. Как только вы узнаете свои паттерны — когда вы наиболее сосредоточены, как долго можете поддерживать глубокую работу, какие задачи всегда выходят за рамки оценок — вы сможете соответствующим образом планировать свой день: планировать наиболее сложную работу на наиболее продуктивные интервалы. Это не продуктивность, основанная на мотивации; это биология. Вы работаете в соответствии со своими естественными ритмами, а не против них.

Источник: https://dev.to/thebitforge/top-10-productivity-hacks-every-developer-should-know-151h

День 2523. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

14. Внедрение зависимостей в .NET
«Как реализовать внедрение зависимостей (DI) в приложении .NET, и каковы основные преимущества использования DI? Пожалуйста, приведите примеры кода, демонстрирующие, как настроить и использовать DI для управления сервисами и зависимостями».

Хороший ответ
Внедрение зависимостей в .NET — это метод, используемый для достижения слабой связанности между объектами и их зависимостями. Используя DI-контейнер, .NET управляет созданием и внедрением зависимостей вместо того, чтобы классы сами их создавали. Такой подход упрощает проектирование классов, повышает модульность и улучшает тестируемость приложений.

Для реализации DI в .NET обычно определяют сервисы и интерфейсы, а затем регистрируют их во встроенном DI-контейнере в файле Program.cs, как показано в следующем коде:

var builder = WebApplication.CreateBuilder(args);

// Регистрируем Scoped-сервис
builder.Services.AddScoped<IService, MyService>();

var app = builder.Build();

// Используем сервис в компоненте приложения
app.MapGet("/", (IService service) => {
  return service.PerformOperation();
});

app.Run();

В этом примере IService — интерфейс, а MyService — класс, реализующий его. Сервис регистрируется как имеющий область видимости (scoped), то есть для каждого запроса будет создаваться новый экземпляр, но он будет использоваться совместно в рамках одного запроса. Другие распространённые варианты:
- transient - новый экземпляр создаётся при каждом использовании;
- singleton – создаётся один экземпляр на всё время жизни приложения.

Ключевые преимущества использования DI:
- Слабая связанность: Объекты не имеют жёстко заданных зависимостей. Это упрощает модификацию и расширение системы.
- Удобство тестирования: Зависимости можно заменять моками или заглушками во время тестирования, что упрощает написание тестов и повышает их надёжность.
- Централизованная конфигурация: Управление созданием объектов и разрешением зависимостей в одном месте делает код чище, а приложение — более масштабируемым.

Часто встречающийся неверный ответ
«В .NET достаточно добавить сервисы в файл Program.cs, используя builder.Services.AddSingleton() или любой аналогичный метод, и .NET автоматически обработает все требования DI без дополнительной настройки».

Этот ответ демонстрирует неполное понимание DI:
- Недостаток деталей о потреблении зависимостей: В ответе упоминается добавление сервисов в DI-контейнер, но не объясняется, как эти сервисы потребляются в приложении. Простая регистрация сервиса не завершает процесс DI; разработчики также должны внедрять эти сервисы в компоненты, где они необходимы.

- Чрезмерное упрощение DI: Ответ подразумевает, что DI не требует тщательного рассмотрения времени жизни сервисов или того, как зависимости внедряются в потребляющие классы. Он упускает из виду важность выбора правильного времени жизни сервиса (singleton, scoped, transient) в зависимости от варианта использования.

Такая ошибка обычно возникает, когда разработчик знает основы добавления сервисов в контейнер внедрения зависимостей, но ему не хватает более глубокого понимания того, как проектировать приложения, чтобы в полной мере использовать преимущества внедрения зависимостей.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

День 2524. #SystemDesign101
8 Распространённых Проблем Проектирования Систем и их Решения

1. Система с нагрузкой на чтение
- Используйте кэширование для ускорения операций чтения.

2. Большой трафик на запись
- Используйте асинхронные рабочие процессы для обработки операций записи.
- Используйте базы данных на основе LSM-деревьев.

3. Единая точка отказа
- Внедрите механизмы дублирования и отказоустойчивости для критически важных компонентов, таких как базы данных.

4. Поддержка доступности
- Используйте балансировку нагрузки, чтобы гарантировать, что запросы направляются к работоспособным экземплярам серверов.
- Используйте репликацию базы данных для повышения отказоустойчивости и доступности.

5. Высокие задержки
- Используйте сеть доставки контента (CDN) для уменьшения задержек.

6. Обработка больших файлов
- Используйте блочное и объектное хранилище для обработки больших файлов и сложных данных.

7. Мониторинг и уведомления
- Используйте централизованную систему логирования, например, стек ELK.

8. Медленные запросы к базе данных
- Используйте правильные индексы для оптимизации запросов.
- Используйте шардинг для горизонтального масштабирования базы данных.

Источник: https://bytebytego.com/guides/8-common-system-design-problems-and-solutions/

День 2525. #ЗаметкиНаПолях
Разбираем Веб-Метки Файлов в .NET
Веб-метка (Mark of the Web, MOTW) — это функция безопасности Windows, которая защищает пользователей от потенциально опасных файлов, загружаемых из интернета. При загрузке файла Windows автоматически добавляет специальный метатег, указывающий на то, что файл получен из ненадёжного источника и может содержать вредоносный контент. При попытке открыть файл с MOTW Windows отображает предупреждение или запрашивает подтверждение перед открытием.

Проверка MOTW перед обработкой файлов может помочь защитить приложение от уязвимостей безопасности. Проверяя происхождение файла, вы можете предотвратить выполнение вредоносного кода или открытие файлов, которые могут скомпрометировать систему пользователя.

MOTW реализован как альтернативный поток данных (ADS), прикреплённый к файлу. ADS содержит информацию об источнике файла, включая URL, с которого он был загружен, и его зону безопасности:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.google.com/

ZoneId обозначает зону безопасности:
0 - Local Machine
1 - Intranet
2 - Trusted Sites
3 - Internet
4 - Untrusted

Мы можем использовать интерфейс IInternetSecurityManager для проверки файлов. Создадим консольное приложение.

Нам понадобятся:
- пакет Microsoft.Windows.CsWin32, который содержит генератор кода для работы с Win32;
- файл NativeMethods.txt в корне проекта с перечислением нужных нам API:

CoInternetCreateSecurityManager
MUTZ_NOSAVEDFILECHECK
MUTZ_REQUIRESAVEDFILECHECK

- вспомогательный enum:

enum UrlZone
{
  Invalid = -1,
  LocalMachine = 0,
  Intranet = 1,
  Trusted = 2,
  Internet = 3,
  Untrusted = 4,
}

Создадим статический класс для проверки MOTW:

public static class MOTW
{
  [SupportedOSPlatform("windows")]
  public static bool IsUntrusted(string path)
  {
    path = Path.GetFullPath(path);

    var hr = PInvoke
     .CoInternetCreateSecurityManager(
      null,
      out var secMgr,
      0
     );
    
    if (hr.Failed || secMgr is null)
      return true;

    try
    {
      secMgr.MapUrlToZone(
       path,
       out var zone,
       PInvoke.MUTZ_NOSAVEDFILECHECK);
      if (zone >= (int)UrlZone.Internet)
        return true;

      secMgr.MapUrlToZone(
       path,
       out zone,
       PInvoke.MUTZ_REQUIRESAVEDFILECHECK);
      if (zone >= (int)UrlZone.Internet)
        return true;

      return false;
    }
    finally
    {
      Marshal.ReleaseComObject(secMgr);
    }
  }
}

Мы проверяем и сохраняемые, и уже сохранённые в доверенных зонах файлы.

Использование:

var path = @"C:\Users\user\Downloads\file.txt";
bool isUntrusted = MarkOfTheWeb.IsUntrusted(path);

Полный код, содержащий также методы установки и удаления ADS, см. в GitHub Meziantou.

Источник: https://www.meziantou.net/understanding-and-managing-mark-of-the-web-in-dotnet.htm