День 1552. #ЗаметкиНаПолях
Проверки Работоспособности в ASP.NET Core. Начало
Мы все хотим создавать надёжные приложения, которые можно бесконечно масштабировать, чтобы обрабатывать любое количество запросов. Крайне важно, чтобы у вас была система для получения быстрой обратной связи о работоспособности приложения. В этом помогут проверки работоспособности (Health Checks).

Они позволяют отслеживать работоспособность различных компонентов, в том числе: баз данных, API, кэша, внешних сервисов. ASP.NET Core имеет встроенную поддержку проверки работоспособности.

Вот базовая конфигурация, которая регистрирует сервис проверки работоспособности:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

var app = builder.Build();

app.MapHealthChecks("/health");

app.Run();

Проверка возвращает значение HealthStatus, которое может быть 3х видов:
- Healthy
- Degraded
- Unhealthy
Например, если приложение работает медленнее обычного, можно возвратить HealthStatus.Degraded.

Специальные проверки
Специальные проверки можно создавать, реализуя интерфейс IHealthCheck. Например, для базы данных SQL, можно использовать запрос, который быстро выполняется, вроде SELECT 1:

public class SqlHealthCheck : IHealthCheck
{
  private readonly string connStr;

  public SqlHealthCheck(IConfiguration cfg)
  {
    connStr = 
     cfg.GetConnectionString("Database");
  }

  public async Task<HealthCheckResult> 
   CheckHealthAsync(
    HealthCheckContext context,
    CancellationToken ct = default)
  {
    try
    {
      using var conn = 
       new SqlConnection(connStr);

      await conn.OpenAsync(ct);
      using var cmd = conn.CreateCommand();
      cmd.CommandText = "SELECT 1";
      await cmd.ExecuteScalarAsync(ct);

      return HealthCheckResult.Healthy();
    }
    catch(Exception ex)
    {
      return HealthCheckResult.Unhealthy(
        context.Registration.FailureStatus,
        exception: ex);
    }
  }
}

Проверку необходимо зарегистрировать, для этого добавим метод к AddHealthChecks:

builder.Services.AddHealthChecks()
  .AddCheck<SqlHealthCheck>(
   "custom-sql",
   HealthStatus.Unhealthy);

Мы задаём имя проверки и устанавливаем, какой статус использовать в качестве результата сбоя.

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

Источник: https://www.milanjovanovic.tech/blog/health-checks-in-asp-net-core

День 1553. #ЗаметкиНаПолях
Проверки Работоспособности в ASP.NET Core. Окончание
Начало

Для многих популярных сервисов реализованы свои проверки работоспособности. Вот несколько примеров:
SQL Server - AspNetCore.HealthChecks.SqlServer
Postgres - AspNetCore.HealthChecks.Npgsql
Redis - AspNetCore.HealthChecks.Redis
RabbitMQ - AspNetCore.HealthChecks.RabbitMQ
AWS S3 - AspNetCore.HealthChecks.Aws.S3
SignalR - AspNetCore.HealthChecks.SignalR

А в репозитории AspNetCore.Diagnostics.HealthChecks их гораздо больше.

Например, вот как добавить проверки для PostgreSQL и RabbitMQ:

builder.Services.AddHealthChecks()
  .AddCheck<SqlHealthCheck>(
    "custom-sql",
    HealthStatus.Unhealthy);
  .AddNpgSql(pgConnectionString)
  .AddRabbitMQ(rabbitConnectionString);

Форматирование ответа
По умолчанию конечная точка, возвращающая статус проверки работоспособности, выдаёт строковое значение, представляющее HealthStatus. Это неудобно, если у вас настроено несколько проверок, поскольку хорошо было бы просматривать состояние отдельно для каждого сервиса. Что ещё хуже, если один из сервисов выходит из строя, проверка просто вернёт Unhealthy, и вы не узнаете, что вызывает проблему.

Эту проблему можно решить, предоставив ResponsWriter, который уже существует в пакете AspNetCore.HealthChecks.UI.Client. После установки пакета надо изменить вызов MapHealthChecks, чтобы использовать ResponseWriter:

app.MapHealthChecks(
  "/health",
  new HealthCheckOptions
  {
    ResponseWriter = 
     UIResponseWriter.WriteHealthCheckUIResponse
  });

Вот пример вывода:

{
  "status": "Unhealthy",
  "totalDuration": "00:00:00.3285211",
  "entries": {
    "npgsql": {
      "data": {},
      "duration": "00:00:00.1183517",
      "status": "Healthy",
      "tags": []
    },
    "rabbitmq": {
      "data": {},
      "duration": "00:00:00.1189561",
      "status": "Healthy",
      "tags": []
    },
    "custom-sql": {
      "data": {},
      "description": "Unable to connect to the database.",
      "duration": "00:00:00.2431813",
      "exception": "Unable to connect to the database.",
      "status": "Unhealthy",
      "tags": []
    }
  }
}

Показано, что из трёх сервисов не работает один, а также показана ошибка.

Итого
Мониторинг приложений важен для отслеживания доступности, использования ресурсов и изменений в производительности. Отслеживать работоспособность ваших приложений ASP.NET Core легко, предоставляя проверки работоспособности для ваших сервисов. Вы можете внедрить пользовательские проверки работоспособности, но сначала проверьте, существуют ли готовые решения.

Источник: https://www.milanjovanovic.tech/blog/health-checks-in-asp-net-core

День 1554. #ЗаметкиНаПолях
Как Исключить Свойства при Сериализации в JSON. Начало
Распространённая проблема при сериализации объектов в JSON в том, что результат содержит множество нежелательных свойств. По умолчанию сериализуются все свойства. Однако очень часто нам не нужна вся информация. Рассмотрим, как убрать ненужные свойства при сериализации объекта на примере двух популярных библиотек сериализации System.Text.Json и Newtonsoft.Json.

1. Игнорируем отдельные свойства
Для отдельных свойств можно использовать атрибут [JsonIgnore], чтобы исключить его из вывода при сериализации объекта. Атрибут доступен в пространстве имен System.Text.Json.Serialization или Newtonsoft.Json соответственно:

public class Person
{
  [JsonIgnore]
  public int Id { get; set; }
  public string? Name { get; set; }
  public string? LastName { get; set; }
}

var person = new Person()
{
  Id = 1,
  Name = "John",
  LastName = "Smith"
};

var json1 = JsonSerializer.Serialize(person);
var json2 = JsonConvert.SerializeObject(person);

Вывод:

{
  "Name": "John",
  "LastName": "Smith"
}

2. Условное игнорирование отдельных свойств
Мы также можем применять условия при индивидуальном игнорировании свойства. Для атрибута [JsonIgnore] можно установить свойство Condition . Например,

[JsonIgnore(Condition = JsonIgnoreCondition.Never)]
public int Id { get; set; }

Доступные значения:
- Always — свойство всегда игнорируется (по умолчанию),
- Never — свойство всегда сериализуется и десериализуется, независимо от глобальных параметров DefaultIgnoreCondition, IgnoreReadOnlyProperties и IgnoreReadOnlyFields,
- WhenWritingDefault — свойство не учитывается при сериализации, если содержит значение по умолчанию для типа (default),
- WhenWritingNull — свойство не учитывается при сериализации, если оно равно null.

В Newtonsoft.Json сериализацию свойства можно настроить с помощью JsonPropertyAttribute.

3. Атрибуты DataContract и DataMember
В некоторых сценариях у нас есть классы со многими свойствами, а мы хотим сериализовать только некоторые из них. При использовании Newtonsoft.Json мы можем добавить атрибут класса [DataContract], а для свойств, которые должны оставаться при сериализации - атрибут [DataMember]. Оба доступны в пространстве имен System.Runtime.Serialization.

public class Customer
{
  public int Id { get; set; }
  [DataMember]
  public string? Name { get; set; }
  [DataMember]
  public string? LastName { get; set; }
}

var customer = new Customer()
{
  Id = 1,
  Name = "John",
  LastName = "Smith"
};
var json = JsonConvert.SerializeObject(customer);

Вывод:

{ 
  "Name": "John", 
  "LastName": "Smith" 
}

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

Источник: https://code-maze.com/csharp-exclude-properties-from-json-serialization/

День 1555. #ЗаметкиНаПолях
Как Исключить Свойства при Сериализации в JSON. Окончание
Начало

4. Игнорировать все свойства с null или default
Можно не учитывать при сериализации свойства со значениями null или значениями по умолчанию для типа (default).

public class Book
{
  public int Id { get; set; }
  public string? Title { get; set; }
  public int? Pages { get; set; }
  public int Sells { get; set; }
  public Author? Author { get; set; } 
}

var book = new Book()
{
    Id = 1,
    Title = "Dracula"
};

В System.Text.Json для этого нужно задать опцию DefaultIgnoreCondition со значением WhenWritingNull или WhenWritingDefault соответственно:

var json1 = JsonSerializer.Serialize(book, 
  new JsonSerializerOptions
  {
    DefaultIgnoreCondition 
     = JsonIgnoreCondition.WhenWritingNull
// или JsonIgnoreCondition.WhenWritingDefault
  });

В Newtonsoft.Json нужно задать параметры NullValueHandling или DefaultValueHandling соответственно:

var json2 = JsonConvert.SerializeObject(book,
  new JsonSerializerSettings
  {
    NullValueHandling = NullValueHandling.Ignore
// или
//  DefaultValueHandling = 
//   DefaultValueHandling.Ignore
  });

Вывод:

{
  "Id": 1, 
  "Title": "Dracula", 
  "Sells": 0
}

Если мы зададим игнорирование значений по умолчанию, то свойства "Sells" не будет в выводе.

5. Используем IContractResolver
Newtonsoft.Json предоставляет этот интерфейс для тонкой настройки сериализации. Проще всего создать класс, унаследованный от DefaultContractResolver, в котором либо:
- переопределить метод CreateProperty, который позволяет обратиться к метаданным свойства и задать ему булево значение ShouldSerialize, определяющее, должно ли свойство попасть в вывод при сериализации,
- переопределить метод CreateProperties, который должен вернуть список свойств, попадающих в вывод при сериализации.
После создания класса, реализующего этот интерфейс, его можно подключить в настройках сериализации:

var json = JsonConvert.SerializeObject(book, 
  new JsonSerializerSettings
  {
    ContractResolver = 
     new MyPropertiesResolver()
  });

Пример создания класса ContractResolver можно найти здесь.

Источник: https://code-maze.com/csharp-exclude-properties-from-json-serialization/

День 1556. #ЧтоНовенького
Новые Атрибуты Валидации в .NET 8
В .NET 8 превью 2, представлены несколько новых атрибутов, которые наверняка вызовут интерес у разработчиков.

1. RequiredAttribute.DisallowAllDefaultValues
Атрибут Required используется для пометки свойства или параметра как обязательного, что означает, что он не может быть null. Теперь добавлено свойство DisallowAllDefaultValues, которое позволяет проверять, что структура не равна своему значению по умолчанию. Допустим, у нас есть свойство типа Guid. По умолчанию Guid инициализируется как Guid.Empty. Чтобы гарантировать, что значение этого свойства всегда установлено, мы можем использовать атрибут Required со свойством DisallowAllDefaultValues, установленным в true. Если значение свойства не задано явно и остаётся равным Guid.Empty, валидация завершится ошибкой:

public class MyClass
{
  [Required(DisallowAllDefaultValues = true)]
  public Guid Value { get; set; }
}

Эта особенно полезно в сценариях, где важно убедиться, что значение свойства или параметра задано явно и его нельзя оставить в значении по умолчанию.

2. Явные границы Range
Теперь можно явно указывать границы при проверке диапазона с помощью RangeAttribute. Можно определять диапазоны с границами, которые исключаются из проверки:

[Range(0d, 1d, 
  MinimumIsExclusive = true, 
  MaximumIsExclusive = true)]
public double Sample { get; set; }

Здесь атрибут указывает, что допустимым диапазоном для Sample типа double является любое значение больше 0 и меньше 1, однако граничные значения 0 и 1 исключаются из допустимого диапазона.

3. Атрибут Length
Этот атрибут теперь можно использовать для установки как нижних, так и верхних границ для строк или коллекций, что обеспечивает большую гибкость при проверке:

[Length(10, 20)]
public ICollection<int> Values { get; set; }

Атрибут Length в коде выше гарантирует, что коллекция Values должна содержать не менее 10 и не более 20 элементов.

4. Атрибуты AllowedValues и DeniedValues
Следующие атрибуты можно использовать для проверки свойства по списку разрешённых или запрещённых значений. AllowedValues указывает список допустимых значений. DeniedValues - список запрещённых значений.

[AllowedValues("chocolate", "vanilla")]
public string IceCreamFlavor { get; set; }

[DeniedValues("beetroot", "eggplant")]
public string CakeFlavor { get; set; }

В этом примере для свойства IceCreamFlavor можно задать только значение «шоколад» или «ваниль», а свойству CakeFlavor нельзя задать значение «свекла» или «баклажан». Эти атрибуты могут быть полезны в сценариях, где вы хотите ограничить возможные значения свойства, например, в раскрывающемся списке или наборе флажков.

Источник: https://dev.to/bytehide/net-8-preview-2-unveiled-5-new-features-you-need-to-know-2cof

День 1558. #МоиИнструменты
WireMock.NET
Я как-то рассказывал про библиотеку Alba, которая позволяет проводить интеграционное тестирование API. Сегодня же расскажу вам про утилиту, позволяющую тестировать клиентов API и имитировать HTTP-запросы.

WireMock.NET — это .NET-версия WireMock, библиотеки для заглушек и имитации HTTP-сервисов. С WireMock.NET вы можете определить ожидаемые ответы для конкретных запросов, а библиотека будет перехватывать и управлять этими запросами для вас. Это позволяет легко тестировать код, выполняющий HTTP-запросы, не полагаясь на фактическую доступность внешнего сервиса и не взламывая HttpClient.

После установки nuget-пакета вы можете начать использовать WireMock.NET, создав экземпляр класса WireMockServer и настроив его на желаемое поведение. Это можно легко сделать, вызвав метод WireMockServer.Start или WireMockServer.StartWithAdminInterface:

using var wireMock = 
 WireMockServer.Start(port: 1080, ssl: false);

Теперь можно начать определять моки для внешних HTTP-запросов, в том числе, используя Fluent API:

wireMock
 .Given(
   Request.Create()
    .WithPath("/foo")
    .UsingGet()
 )
 .RespondWith(
   Response.Create()
    .WithStatusCode(200)
    .WithHeader("Content-Type", 
      "application/json; charset=utf-8")
    .WithBodyAsJson(new 
      { msg = "Hello world!" })
 );

В тестах легко написать проверку результатов HTTP-запроса:

[Fact]
public async Task sample_test()
{
  var response = await new HttpClient()
   .GetAsync($"{_wireMock.Urls[0]}/foo");

  Assert.Equal(HttpStatusCode.OK,
   response.StatusCode);
  Assert.Equal(
   """{"msg":"Hello world!"}""", 
   await response.Content.ReadAsStringAsync());
}

Замечание: в реальном приложении, конечно, тестироваться будут не собственно HTTP-ответы, а код, обрабатывающий эти ответы.

WireMock.NET предлагает множество функций, помимо базовых заглушек и имитаций HTTP-запросов:
1. Прокси-запросы к реальному сервису и захват ответов в виде маппинга. Вы можете использовать их в качестве основы для своих заглушек, устраняя необходимость в ручном определении ответов.
2. Чтение маппингов и определение заглушек из статических файлов, вместо того, чтобы определять их программно. Это может быть полезно для совместного использования заглушек в разных тестах или проектах.
3. Создание динамических шаблонов ответов, которые включают данные из запроса. Это позволяет создавать ответы, которые различаются в зависимости от данных запроса, что может быть полезно для тестирования пограничных случаев или моделирования поведения реального сервиса.
4. Моделирование поведения сервиса с помощью сценариев и состояний. Вы можете легко имитировать различные состояния сервиса и переключаться между ними. Это может быть полезно для проверки того, как ваш код обрабатывает различные типы сбоев или ответов от сервиса.

Узнать больше о возможностях WireMock.NET можно на странице WireMock Wiki.

Источник: https://cezarypiatek.github.io/post/mocking-outgoing-http-requests-p1/

День 1559. #Карьера
Вещи, Которые не Стоит Раскрывать на Собеседовании
Нам всем приходится проходить собеседования в течение своей карьеры. Кому-то больше, кому-то меньше. Понять, что стоит говорить на собеседовании, а чего не стоит, можно только с опытом, и во многом это зависит от компании и интервьюера. Но вот универсальные вещи, которые лучше оставить при себе, даже если они на первый взгляд кажутся безобидными.

1. Слишком много фактов о себе
Даже если у вас есть чрезвычайно увлекательная, но длинная история из вашей практики, её лучше сократить, либо вообще не рассказывать. Интервьюер ищет человека, который может кратко и чётко выражать свои мысли. Кроме того, наниматель вольно или невольно может использовать то, что вы скажете, как в вашу пользу, так и против вас. Ваши личные увлечения, пристрастия или тем более политические взгляды могут повлиять на решение о вашем трудоустройстве.

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

3. Карьерные планы, не связанные с текущей вакансией
В продолжение предыдущего пункта. Если вас спросят, где вы видите себя через пять лет, отвечать, что вы хотите сменить сферу деятельности либо открыть собственный бизнес – не лучшая идея. Работодателю нужен ресурс, на который можно рассчитывать в долгосрочной перспективе. А ваше желание в скором времени сменить карьерный путь может означать, что вы не полностью будете отдаваться работе.

4. Факт, что вы ищете любую работу
У любого из нас бывают сложные моменты в жизни. Однако не стоит сообщать потенциальному работодателю, что вы в отчаянии ищете любой способ заработать деньги.

5. Возраст
Да, в ИТ это не главный фактор, и сложно будет уйти от прямого вопроса, но всё-таки, пока не спрашивают, лучше лишний раз не сообщать (что, например, часто встречается в резюме).

6. Сколько вы собираетесь отработать на этом месте
Этот пункт в некотором роде связан с п.3. Не стоит сообщать, что вы собираетесь отработать Х лет и уйти на заслуженный отдых (даже если это так). Многие работодатели ищут кандидатов с потенциалом роста либо на более долгий срок, чем вы рассчитываете, поэтому раскрытие того, что кандидат собирается «отбыть срок» и уйти, может сильно навредить.

7. Проблемы со здоровьем
Понятно, что, если проблема со здоровьем мешает вам выполнять ваши обязанности, о ней стоит сообщить. Об остальном, если вас напрямую не спрашивают, лучше не распространяться, чтобы опять же не вызывать ненужную предвзятость у интервьюера.

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

Источник: https://www.youtube.com/watch?v=eza-l-kBK40

День 1560. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Начало
Кодовая база приложения — живой объект. Она растёт, меняется и приспосабливается. Всегда есть новая функция, которую нужно добавить, ошибки, которые нужно исправить и которые создаются в результате. По мере роста проекта код меняется чаще, появляется все больше функций, больше проблем и больше ошибок. Ручное тестирование становится невозможным. Как убедиться, что приложение остаётся работоспособным, что развёртывание ничего не сломало? Автоматизировать. Вот лучшие практики, позволяющие быстро развёртывать изменения и поддерживать высокое качество приложения.

1. Используйте флаги функций
Флаги функций - это механизм, который позволяет вам отключить функциональность в рабочей среде, если что-то пойдёт не так:

if (IsFeatureFlagEnabled(
  "MyNewFeature",
  defaultValue: false))
{
 //…
}

Фактические значения флагов функций могут находиться в какой-либо удалённой БД или сервисе, которым вы можете управлять. Можно разработать их самостоятельно или использовать инструмент вроде LaunchDarkly, который сохраняет значения флагов функций, предоставляет API для их получения и UI, позволяющий легко их изменять.
Функция может быть защищена флагом «высокого уровня», который отключает всё, и флагами «низкого уровня», которые контролируют более мелкие части функции. Можно ввести политику, согласно которой каждое изменение кода должно быть защищено флагом функции.
Флаги функций упрощают разработку. Вместо того, чтобы иметь побочную ветку, которую команда разработчиков хранит отдельно в течение нескольких месяцев, можно работать в «основной» ветке, но отключить функциональность с помощью флага функции.
Кстати, со временем не забывайте удалять флаги устоявшихся функций, прежде чем код станет нагромождением условных операторов.

2. Добавьте телеметрию для обнаружения регрессий
Ключевой частью понимания того, что приложение работает должным образом, является возможность наблюдать за тем, что происходит. Вы хотите узнать как можно скорее, когда что-то пойдёт не так. Этот вид мониторинга проявляется во многих формах:
- Журналы ошибок. Добавляйте их во все приложения. Если есть исключение или неожиданное поведение регистрируйте его. Всплеск числа ошибок в журнале быстро указывает на наличие проблемы и определяет ее основную причину.
- Телеметрия времени выполнения. Это может быть время выполнения операции, время выполнения запроса или что-либо ещё, что вы можете измерить. Его легко отслеживать, и вы можете быстро обнаруживать аномалии, такие как зависшие запросы и низкая производительность. Кстати, уменьшение времени выполнения также может указывать на то, что что-то пошло не так. Можно регистрировать время выполнения самостоятельно с помощью журналов приложений или использовать счетчики производительности или инструменты вроде Azure Monitor.
- Телеметрия сбоев. Сбои — это плохо, и вы хотите узнавать о них как можно скорее. Надёжная система сообщения о сбоях будет иметь большое значение. Можно разработать собственные или использовать инструменты для создания отчетов о сбоях, такие как Raygun.
- Панели мониторинга приложений. Информационные панели хороши тем, что картинка стоит тысячи слов. Простая информационная панель может быстро показать, что что-то пошло не так. Вы можете отображать время выполнения запроса, использование ЦП и памяти, частоту сбоев и т. д. Чем больше, тем лучше. Если вы можете визуально увидеть всплеск или падение, вы быстро обнаружите проблему, которую можете исправить, прежде чем она серьёзно повлияет на бизнес. Существуют отличные инструменты для создания панелей мониторинга, включая Azure Data Explorer, Grafana и DataDog.

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

Источник: https://michaelscodingspot.com/safe-application-deployment/

День 1561. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Продолжение
Начало

3. Добавьте оповещения телеметрии, когда что-то идёт не так
Добавление журналов и информационных панелей — это здорово, но полагаться на то, что кто-то всегда будет их просматривать, обречено на провал. Лучший способ обеспечить наблюдаемость — автоматизировать аномалии. Автоматизируйте информационные панели, чтобы отправлять оповещения, когда что-то идёт не так. Если есть серьёзное замедление продолжительности запросов, вы захотите узнать об этом как можно скорее. То же касается роста количества записей в журналах ошибок и сбоев процессов. Практически всё, за чем вы стараетесь следить, стоит автоматизировать для уведомлений в случае возникновения проблемы. Большинство инструментов, предоставляющих отчеты и визуализацию информационных панелей, также имеют функции оповещения, включая Kibana, Azure Monitor и Datadog.

4. Добавьте для клиентов простой способ оставить отзыв
Ваши клиенты, помимо оплаты счетов за ваш сервис, могут быть отличными QA-инженерами. Добавьте в приложение лёгкий способ предоставления отзывов. Убедитесь, что вы можете сопоставить соответствующие журналы приложений с заявкой пользователя. Помимо бесплатной гарантии качества, предоставление возможности оставить отзыв — это отличный опыт для клиента.
Да, и как только у вас будет конвейер для получения отзывов клиентов, обязательно добавьте счётчик отзывов в качестве телеметрии, создайте панель мониторинга и оповещение.

5. Дежурные инженеры
Добавление телеметрии, отзывов клиентов и информационных панелей не очень полезно, если за ними никто не следит. На определённом этапе роста компании обычно вводят какую-либо политику ротации дежурств. Это так же просто, как назначить еженедельные или ежемесячные смены среди ваших инженеров. Во время смены дежурный отвечает за любые соответствующие оповещения и уведомления, активно просматривает информационные панели работоспособности приложений и реагирует на аномалии. Обычно дежурный инженер не решает проблему, а только назначает её соответствующему разработчику или устраняет её, отключая некоторые функции или, возможно, перезапуская какой-либо сервер.
Вы можете выбрать альтернативный путь - иметь постоянных инженеров по надёжности (Site Reliability Engineer, SRE). Подход с ротацией предпочтительнее в том, что разработчики лучше знают, что происходит в коде, и одни и те же люди следят за работоспособностью приложения и устраняют проблемы. Это может усилить их чувство ответственности.

6. Используйте канареечные релизы
Как только ваше приложение достаточно разрастётся, вы больше не сможете позволить себе развёртывать изменения для всех клиентов, независимо от того, насколько изменения защищены флагами функций и отличной телеметрией. Риск слишком велик. Чтобы свести его к минимуму, стандартной практикой является использование канареечных выпусков. Вместо того, чтобы выдавать новый код всем, он постепенно выдаётся группам (кольцам) клиентов. Во-первых, новые изменения развёртываются в первом кольце, которое представляет собой небольшое подмножество пользователей, возможно, во внутренней тестовой среде. Затем код передается второму кольцу, которое представляет собой большее подмножество пользователей. Каждый раз, когда код развёртывается в более крупном кольце, вы должны отслеживать журналы приложений, информационные панели и отзывы клиентов, чтобы убедиться, что ничего не сломалось. Если что-то сломалось, вы сможете вовремя это обнаружить с минимальным воздействием на большинство клиентов.

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

Источник: https://michaelscodingspot.com/safe-application-deployment/

День 1562. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Окончание
Начало
Продолжение

7. Добавьте эксперименты и A/B-тестирование
При добавлении каких-либо изменений, таких как новая функция или изменение UX, отлично подходит A/B-тест, чтобы убедиться, что изменение является положительным и не создаёт никаких проблем. Добавьте механизм для разделения ваших пользователей на 2 или более групп и запускайте для них разный код. Контролируйте обе группы эксперимента: контрольную и экспериментальную (группу A и группу B). Есть ли увеличение в журналах ошибок? Как насчёт всплесков жалоб от клиентов? Проверьте информационные панели, есть ли аномалии?
Такие эксперименты отлично подходят для выявления проблемных изменений, если у вас есть хороший способ сопоставить телеметрию с экспериментальными группами. Нужно просто при запуске сессии регистрировать все сессии экспериментальной группы, а затем сопоставлять их с проблемными сессиями.

8. Проводите пассивное тестирование
Пассивные тесты — отличный способ убедиться, что ваши изменения ведут себя правильно в большой среде, которую вы не до конца понимаете. Учтите, что, когда вы делаете какую-то оптимизацию или рефакторинг в огромном приложении, вы не можете с полной уверенностью предсказать, что ничего не сломали. Конечно, у вас есть набор тестов, но вы никогда не знаете наверняка, что он охватывает все случаи. Вместо этого вы можете сделать пассивный тест. Выполняйте любую оптимизацию или изменение, которое вам нужно, в темноте, работая пассивно, в дополнение к исходной реализации. Запустите как старый (активный) код, так новый (пассивный), а затем сравните результаты в логах. Разверните новый код в производственной среде и убедитесь, что поведение исходного и изменённого кода совпадает. Как только вы увидите, что они идеально совпадают, вы можете уверенно переключиться со старого кода на новый.

9. Тестируйте
Тесты оставлены напоследок, потому это вроде бы и очевидно, но тем не менее важно и о них нужно упомянуть.
Одним из самых важных механизмов, позволяющих убедиться, что следующее развёртывание не сломает ничего существенного, является набор тестов. Это должно быть стандартной практикой в наши дни, но множество проектов даже сейчас всё ещё существуют без них. Когда у вас есть тесты, обязательно применяйте их, что обычно означает добавление политики в пулл-реквесты, которая гарантирует, что все тесты пройдены.
Когда у вас есть непрерывный процесс интеграции, пришло время рассмотреть стратегию тестирования. Вы стремитесь к определённому уровню покрытия кода? Все ли новые функции требуют некоторого количества тестов? Автоматически применять такие правила сложно, но всё же полезно определить политику для команды и попытаться следовать ей самостоятельно и при обзорах кода.
Помимо модульных тестов, хорошо иметь приличное количество интеграционных и сквозных тестов. Они не определят основную причину, если тест не пройдёт, но отлично подойдут для обнаружения ошибок и проверки работоспособности вашей системы в целом. Модульные тесты, как правило, легко ломаются при рефакторинге или изменении поведения, даже если система работает так, как ожидалось, в то время как сквозные тесты обычно остаются нетронутыми, если вы не вносите ошибки. Можно даже удалить некоторые или большинство модульных тестов после завершения разработки и оставить только интеграционные и E2E-тесты. Или, по крайней мере, будьте гибкими, чтобы со временем отказаться от модульных тестов в пользу более глобальных.

Источник: https://michaelscodingspot.com/safe-application-deployment/

День 1563. #Карьера
Совещания Делают Вас Менее Продуктивными?
Согласно исследованию SurveyMonkey, 32% людей считают, что то, что было на совещании, могли бы прислать в e-mail. Скорее всего, где бы вы ни работали, вы не устраивались в эту компанию ради совещаний. Вы хотели создавать ПО. Но митинги стали частью процесса, и чем выше ваша позиция, тем больше встреч вас, вероятно, приглашают посетить. Сегодня рассмотрим влияние совещаний на продуктивность и способы сделать их лучше (или вообще избежать их).

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

Все эти недостатки совещаний могут заставить вас задаться вопросом, зачем вообще их проводить?

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

Многие люди воспринимают нежелание посещать встречи или отказ от неё как оскорбление. Кто-то, возможно, предпочёл бы e-mail с описанием задачи. Но другой человек может рассматривать встречу как способ прощупать идею, найти лучшее решение, работая с экспертом — с вами.

Встречи, которые проходят на стадии планирования, проектирования и определения объёма работ, в итоге оказываются наиболее полезными. Они не отвлекают вас от другой работы. Если все заинтересованные стороны не соберутся вместе и не определят, что необходимо сделать, инженеры не смогут разрабатывать решения вслепую.

Самая важная часть встречи — выделить время и подумать о том, кто там необходим, и создать среду, в которой можно принять решение. Каждый участник после встречи должен иметь представление о том, что делать дальше. По статистике лишь чуть больше половины уходят с собрания, зная, какие действия им нужно предпринять.

Если вам нужно собрание, нужно стать хорошим распорядителем, как и в любом другом проекте. Собрания улучшат чёткая повестка дня и короткое время встречи. Все участники могут повысить эффективность совещаний, если будут честны, ясны и общаться так, чтобы это приводило к принятию решения.

Необходимы перерывы между совещаниями, если их несколько в день. Также исследование Human Factors Lab в Microsoft обнаружило, что дни без совещаний улучшают общую коммуникацию, а продуктивность снижается, если разработчик проводит более двух совещаний в день.

Все исследования свидетельствуют в пользу того, чтобы проводить меньше встреч. Хотя они по-прежнему иногда необходимы. Dropbox использует систему 3D: решения (decisions), дебаты (debates) и обсуждение (discussion). Это действия, для выполнения которых люди должны сотрудничать. Всё остальное можно подать другими способами.

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

Источник: https://stackoverflow.blog/2023/04/12/are-meetings-making-you-less-productive/

День 1564. #ЗаметкиНаПолях
Утечки Памяти в C#
Утечка памяти в C# происходит, когда приложение неоднократно выделяет память, но не освобождает её даже после того, как память выполнила своё предназначение. В результате приложение постепенно использует всё больше памяти с течением времени, что в итоге может привести к сбою приложения или прекращению его работы. Ошибки программирования включают в себя неспособность освободить объекты, которые больше не нужны, или хранение ссылок дольше, чем необходимо, что может привести к утечке памяти. Циклические ссылки на объекты, неправильное использование структур данных, таких как списки и словари, а также неправильная обработка исключений — вот лишь некоторые из причин этих ошибок.
Сегодня рассмотрим различные ситуации утечки памяти.

1. Использование статических объектов.
Когда мы используем статический класс, переменные будут доступны на протяжении всего жизненного цикла приложения. Мы должны быть очень осторожны, когда используем статические переменные/классы. Это связано с тем, что сборщик мусора не собирает статические объекты и всё, на что они ссылаются. Не используйте ключевое слово static, если в этом нет необходимости.

2. Длительный поток.
Если мы работаем с долго выполняющимся потоком или бесконечным циклом в потоке, поток будет удерживать объект в течение длительного времени. Если объект хранится долгое время, сборщик мусора думает, что объект используется, и не будет очищать память. Всегда устанавливайте условие выхода из цикла.

3. Кэширование.
Это очень хорошая стратегия для повышения производительности приложения. Но если мы используем кэширование во всех областях приложения, это приведёт к избыточному кэшированию и нехватке памяти. Всегда полезно кэшировать только часто используемые объекты.

4. Использование неуправляемых объектов.
Работа с файловой системой ОС — один из лучших примеров неуправляемых объектов. Если мы собираемся использовать файловую систему, мы должны правильно избавляться от всех объектов после завершения работы. В противном случае, поскольку сборщик мусора не очищает их, это приведёт к утечке памяти.

5. Ручная реализация шаблона IDisposable.
Всегда используйте метод Dispose в классе, который реализует интерфейс IDisposable. В противном случае может произойти утечка памяти. Конструкция using, которая вызывает метод Dispose для каждого экземпляра, является лучшим подходом для достижения этой цели. Если вы не можете использовать оператор using, не забудьте сделать это вручную и подавить метод finalize, так как он не требуется.

GC.SuppressFinalize();

Если мы используем интерфейс IDisposable, мы вручную освобождаем объект с помощью метода Dispose. Finalize — это метод автоматического управления памятью, вызываемый сборщиком мусора для удаления неиспользуемых объектов. Поэтому при ручной очистке он не требуется.

Источник: https://dev.to/arunkumar2331996/memory-leaks-in-c-3koj

День 1565.
Мониторинг и Производительность Entity Framework. Вопросы и Ответы. Начало
ORM-технологии, такие как Entity Framework, могут значительно упростить модель программирования для баз данных, но при небрежном исполнении может пострадать производительность. Чтобы этого не произошло, разработчики используют мониторинг, профилирование взаимодействия с БД и тонкую настройку запросов. Джим Вули, архитектор решений в Slalom Consulting делится своими знаниями о том, как максимально эффективно использовать EF.

1. Как ORM могут упростить модель программирования для баз данных?
Инструменты ORM, такие как EF, избавляют разработчиков от необходимости беспокоиться об управлении коммуникациями между приложением и базой данных и позволяют им сосредоточиться на добавлении ценности для бизнеса безопасным для типов способом (через LINQ). Разработчикам не нужно беспокоиться об управлении подключениями к базе данных, обновлении хранимых процедур для каждой операции или изучении тонких различий между различными диалектами SQL (TSQL, PLSQL, pgSQL и т. д.). Пока необходимо извлечь объект или граф объектов, внести изменения в эту структуру и обновить ее, инструменты OR/M могут легко обрабатывать 80-90% вариантов использования, не вызывая проблем с производительностью. Кроме того, по мере развития платформы находятся всё новые средства оптимизации производительности, и разработчики могут ими воспользоваться, просто обновив версию.

2. Какие распространённые ошибки допускают разработчики при использовании EF?
Инструменты ORM уменьшают потребность в ручном управлении, но по-прежнему необходимо следить за утечками, которые могут вызвать серьёзные проблемы в будущем. Однажды у меня был клиент, который столкнулся с проблемой производительности. Как оказалось, проблема была вызвана ленивой загрузкой дочерних записей на четыре уровня ниже во вложенных циклах. Помните о действиях, вызывающих запросы к базе, таких как foreach, First, Any, Sum, Count. С другой стороны, применяя дополнительную фильтрацию к возвращённому IEnumerable, надо понимать, что она выполняется в памяти, а не в базе данных.
Также нужно немного знать о настройке и индексировании базы данных, а также о влиянии ваших запросов на индексы. Например, если вы используете метод .Include() для выборки связанных дочерних записей, он будет включать все дочерние столбцы как часть запроса и, таким образом, будет игнорировать покрывающие индексы, то есть выполняться неоптимально.
Более тонкие проблемы могут возникнуть, когда разработчики пытаются применить вычисления дат в предложениях Where или не сопоставляют строки ANSI с типами данных varchar. В обоих случаях индексирование, которое, как вы думали, вы используете, может быть недоступно, и в результате вы получаете медленное полное сканирование таблицы.
Во всех этих случаях внимание, выявление плохо работающих запросов и их профилирование для определения необходимых изменений — это первый шаг к обеспечению хорошей работы приложения.

3. Как мониторинг производительности и настройка могут улучшить ситуацию?
Наличие набора тестов, который вы можете использовать для мониторинга производительности, — это первый шаг. Так вы сможете идентифицировать запросы или участки кода, которые плохо работают и нуждаются в настройке. Настройка без мониторинга часто приводит к преждевременной оптимизации. Даже с EF в .Net Framework, хотя запросы, сгенерированные EF, могли выглядеть довольно неприятно, планы выполнения, сгенерированные базой данных, могли генерировать такие же хорошие или, в некоторых случаях, лучшие запросы, чем вы могли бы написать сами.
Только после выявления проблемных запросов вы можете настроить или, в некоторых случаях, переосмыслить задачу для достижения той же конечной цели. Настройка производительности приложений во многом является искусством, и редко существует универсальный подход, который решит эту проблему. Вы должны попробовать несколько стратегий, чтобы выяснить, что лучше всего подходит для данного случая.

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

Источник: https://visualstudiomagazine.com/articles/2023/04/05/ef-performance.aspx

День 1566.
Мониторинг и Производительность Entity Framework. Вопросы и Ответы.
Окончание
Начало

4. Профилирование взаимодействий с базой данных с помощью EF: что нужно и как это помогает?
В зависимости от вашей платформы и среды существует ряд бесплатных и коммерческих инструментов профилирования. От SQL Profiler (или соответствующего расширения для Azure Data Studio), Intellitrace и Application Insights до сторонних модулей, таких как EPFrof, OrmProfiler и MiniProfiler.
В некоторых случаях поддержка инструментов может быть добавлена без изменения кода вашего приложения, в других случаях требуется разместить в приложении небольшие хуки для перехвата. Кроме того, некоторые из более поздних инструментов облегчают нахождение строки кода, вызывающей запрос. Это может быть неоценимо при попытке выяснить, откуда взялся надоедливый плохо выполняющийся запрос.

5. Каковы плюсы и минусы работы без хранимых процедур?
Многие сторонники хранимых процедур рекламируют возможности, которые они привносят с точки зрения компиляции и кэширования запросов, а также параметризации. При этом они создавали динамические запросы внутри хранимых процедур, полностью нивелируя эти преимущества. EF генерирует запросы, которые можно кэшировать и которые гарантированно будут параметризованы (если только вы не используете FromSqlRaw). В результате использование EF может быть столь же эффективным и безопасным, как и хранимые процедуры.
Кроме того, вы получаете возможность менять провайдера базы данных, не переписывая все запросы. Или при добавлении столбца в таблицу, с EF вы добавляете только свойство в модель объекта. Для хранимых процедур также потребуется управление изменениями схемы таблиц и несколько изменений хранимых процедур (для операций CRUD).
Иногда необходимо использовать хранимые процедуры. Некоторые платформы предлагают определённые функции, которые LINQ может не поддерживать (подсказки запросов, иерархии, геопространственные данные, массовое копирование и т. д.), и для них может потребоваться нативный код. В более новых версиях EF устранены некоторые из этих пробелов. Если вы будете следовать правилу 80/20, используя EF, где это возможно, а где необходимо - хранимые процедуры или другие функции, специфичные для платформы, вы часто сможете найти подход, который хорошо работает для всех сценариев приложений.

6. С какими проблемами сталкиваются организации или команды при начале работы с EF?
Проблема чаще всего не технологическая, а человеческая. Для новых приложений внедрение новых технологий часто проще. Для существующих, которые создавались годами, часто приходится полагаться на то, что универсальная среда может быть такой же хорошей (или лучше), чем созданная командой за эти годы. Некоторые из таких приложений были специально созданы для передачи таких структур ADO, как DataSets и DataTables, в пользовательский интерфейс. Попытка обосновать рентабельность инвестиций в модернизацию уровня данных в таких обстоятельствах часто может быть затруднена.
Другая типичная проблема также сводится к доверию между инженерными командами и группами поддержки (часто между разработчиками и администраторами баз данных). Группы поддержки вызываются в 3 часа ночи, когда система даёт сбой из-за плохо выполняющегося запроса, который загружает ЦП сервера базы данных. Аргумент здесь в том, что, если бы запрос был абстрагирован в хранимую процедуру, они имели бы контроль над его изменением, а не заставляли разработчиков вносить изменения в код. Это можно смягчить, используя наборы тестов производительности с соответствующим охватом и просматривая сгенерированные запросы в течение циклов разработки. Этот подход требует общения между командами для установления большего доверия с течением времени.

Источник: https://visualstudiomagazine.com/articles/2023/04/05/ef-performance.aspx

День 1567. #ЗаметкиНаПолях
Проверяем Правильность Архитектуры ПО с Помощью Тестов
Архитектура ПО — это план того, как структурировать систему. Вы можете строго или не очень строго следовать ему. Но когда сроки поджимают, и вы начинаете срезать углы, созданная вами прекрасная программная архитектура рассыпается, как карточный домик.

Архитектурные тесты — это автоматизированные тесты, которые проверяют структуру и дизайн кода. Вы можете использовать их для проверки соблюдения архитектуры ПО или направления зависимостей ваших проектов.

Архитектурные тесты пишутся так же, как и любой модульный тест. Есть отличная библиотека для создания архитектурных тестов, в которой уже реализован шаблонный код - NetArchTest.Rules.

Отправной точкой для написания архитектурных тестов является статический класс Types, который можно использовать для загрузки набора типов. После этого их можно дополнительно отфильтровать. Некоторые из доступных методов фильтрации:
- ResideInNamespace
- AreClasses
- AreInterfaces
- HaveNameStartingWith
- HaveNameEndingWith

Наконец, вы можете написать правило, которое хотите применить, вызвав Should или ShouldNot и применив условие, которое хотите проверить. Вот пример проверки того, что все классы домена запечатаны:

var result = Types
  .InAssembly(DomainAssembly)
  .That()
  .AreClasses()
  .Should()
  .BeSealed()
  .GetResult();
Assert.True(result.IsSuccessful);

Архитектурные тесты особенно полезны для проверки соблюдения правил архитектуры ПО в многоуровневой архитектуре или модульном монолите.
- Домен не должен иметь никаких зависимостей:

var result = Types
  .InAssembly(DomainAssembly)
  .ShouldNot()
  .HaveDependencyOnAny("Application", "Infrastructure")
  .GetResult();
Assert.True(result.IsSuccessful);

- Приложение не должно зависеть от Инфраструктуры:

var result = Types
  .InAssembly(AplicationAssembly)
  .Should()
  .NotHaveDependencyOn("Infrastructure")
  .GetResult();
Assert.True(result.IsSuccessful);

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

var result = Types
  .InAssembly(InfrastructureAssembly)
  .HaveNameEndingWith("Repository")
  .Should()
  .HaveDependencyOn("Domain")
  .GetResult();
Assert.True(result.IsSuccessful);

Ещё один ценный вариант использования — проверка соблюдения правил проектирования. Правила проектирования более конкретны и сосредоточены на деталях реализации классов. Например:
- Сервисы должны быть internal-классами,
- Сущности и объекты-значения должны быть запечатаны,
- Контроллеры не могут напрямую зависеть от репозиториев:

var result = Types
  .InAssembly(ApiAssembly)
  .That()
  .HaveNameEndingWith("Controller")
  .ShouldNot()
  .HaveDependencyOn("Infrastructure.Repositories")
  .GetResult();
Assert.True(result.IsSuccessful);

Итого
Архитектурные тесты — это простой способ проверить правильность архитектуры ПО и выполнения правил проектирования с помощью автоматизированных тестов. Вы можете быстро написать их и кардинально снизить затраты на проверки соблюдения правил архитектуры ПО, которые в противном случае выполнялись бы вручную через парное программирование или обзоры кода.

Источник: https://www.milanjovanovic.tech/blog/enforcing-software-architecture-with-architecture-tests

День 1569. #ЗаметкиНаПолях
Избегайте Распространения DbContext или IQueryable в Приложениях. Начало
Большинство приложений .NET используют EF Core и DbContext для доступа к данным, но удобство сопровождения может пострадать, если использование DbContext или производного от него IQueryable распространяется по всему приложению.

Интерфейсы IQueryable и IQueryable<T> в .NET позволяют описывать запросы в виде деревьев выражений, которые при выполнении преобразуются провайдером в запросы к БД. В EF IQueryable используется, чтобы создавать динамические SQL-запросы, что позволяет выполнять детальные и эффективные запросы к базе данных, а не извлекать больше данных, чем необходимо, в память приложения, а затем фильтровать результат в памяти.

Ниже создаётся набор заказов, отфильтрованных по дате. В первом примере все заказы из БД передаются в приложение, а затем фильтруются. Во втором используется динамический SQL-запрос, позволяющий БД возвращать только совпадающие записи:

var since = new DateTime(2023,1,1);

// фильтрация в памяти
var all = dbContext.Orders.ToList();
var recent1 = all
  .Where(o.Date > since)
  .ToList();

// фильтрация в БД
var recent2 = dbContext.Orders
  .Where(o.Date > since)
  .ToList();

Очевидно, что скорость и эффективность второго подхода почти всегда делают его предпочтительным методом.

Можно создать выражение IQueryable с помощью серии операторов, даже в разных функциях, классах или проектах. Когда об этом было впервые объявлено, в Microsoft высоко оценили эту возможность, т.к. разработчики могли создавать нужный запрос «по требованию», где бы им это ни требовалось, гарантируя, что при окончательном выполнении запроса будут возвращены только необходимые данные. У вас может быть сервис, возвращающий «чистые» данные:

public class DataService
{
  public async 
   Task<IQueryable<Order>> List()
  {
    return await 
     _dbContext.Orders.AsQueryable();
  }
}

Сервис бизнес-логики, который накладывает некоторые ограничения на выборку:

public class OrderService
{
  // сервис данных внедряется в _dataService
  public async 
   Task<IQueryable<Order>> ActiveOrders()
  {
    var all = await _dataService.List();
    return await all
      .Where(o => !o.Canceled)
      .AsQueryable();
  }
}

Затем в контроллере добавляется фильтр текущего пользователя:

var viewModel =
  await _orderSvc.ActiveOrders()
    .Where(o => o.CreatedBy = username)
    .AsQueryable();

Наконец, на странице в коде Razor мы генерируем окончательный список:

foreach(var ord in
 model.Orders.Where(o => o.Shipped()))
{
  // список в HTML
}

В итоге у нас получается следующий запрос, который будет выполнен:

_dbContext.Orders
  .Where(o => !o.Canceled &&
    o.CreatedBy == username &&
    o.Shipped);

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

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

Источник: https://ardalis.com/avoid-dbcontext-iqueryable-proliferation/

День 1570. #ЗаметкиНаПолях
Избегайте Распространения DbContext или IQueryable в Приложениях. Окончание
Начало

Когда вы везде передаёте IQueryable, вы позволяете логике доступа к данным распространяться по всей кодовой базе. Нет никакой инкапсуляции логики и правил доступа к данным. Приложение не следует принципу разделения ответственности, поскольку позволяет логике данных «протекать» в каждую часть системы.

Более того, код за пределами уровня данных может даже не знать, что он имеет дело с IQueryable, потому что IQueryable наследует IEnumerable. Методы могут работать с IEnumerable, ожидая поведения только в памяти, но на самом деле манипулируя деревом выражений IQueryable. Это может привести к неожиданным исключениям во время выполнения, особенно если результаты фильтруются с использованием кода, который EF не может преобразовать в SQL (например, пользовательской функции). Страдает понимание кода, а также отладка, устранение неполадок и тестирование. Место IQueryable - на уровне данных. В репозитории допустимо использование IQueryable, при условии, что он не является частью абстракции или публичного интерфейса типа.

Поскольку DbContext или DbSet<T> можно использовать для получения IQueryable в любое время, передача их за пределы уровня данных имеет такое же (негативное) влияние на разделение ответственности и инкапсуляцию, что и передача IQueryable<T>.

Какая есть альтернатива?
Во-первых, вы можно передавать дерево выражений в сервис данных и использовать его:

public IOrderRepository
{
  List<Order> List(
   Expression<Func<Order,bool>> filter);
}

Вы создаёте фильтр заранее, он исполняется в сервисе данных, а возвращаемый результат – данные в памяти.

Ещё лучше использовать паттерн Спецификация. В этом случае вместо передачи LINQ-выражения вы передаёте экземпляр спецификации, а выражение строится в ней:

public IOrderRepository
{
  List<Order> List(
   Specification<Order> spec);
}

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

public class ShippedOrdersForUserSpec :
 Specification<Order>
{
  public ShippedOrdersForUserSpec(
   string username)
  {
    Query.Where(o => !o.Canceled &&
      o.CreatedBy == username &&
      o.Shipped);
  }
}

// в контроллере/на странице
var spec = new ShippedOrdersForUserSpec(username);
var viewModel = await _repo.ListAsync(spec);

Таким образом запрос по-прежнему выполняется в базе данных, но IQueryable больше не используется нигде за пределами реализации репозитория. Вы можете посмотреть на использование этого паттерна в примере eShopOnWeb (см. папку /src/ApplicationCore/Specifications/).

Итого
Распространение IQueryable по всему приложению позволяет расширять запросы к БД из любого места. Это и хорошо, и плохо, и соответствует определению антипаттерна, поскольку сначала кажется чем-то стоящим, но на практике приводит к проблемам. Решение состоит не в том, чтобы получать нефильтрованные данные и затем фильтровать их на сервере приложений, а в том, чтобы идентифицировать конкретные запросы, которые потребуются отдельным страницам или конечным точкам, и определять их как первоклассные абстракции в модели предметной области приложения. Паттерны Спецификация и Репозиторий прекрасно подходят для достижения такого дизайна и обеспечивают гораздо более удобный и тестируемый результат.

Источник: https://ardalis.com/avoid-dbcontext-iqueryable-proliferation/