День 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