Обложка канала

.NET Разработчик. Страница 3

Опытный разработчик не так давно зашёл в .Net и поставил цель получить сертификат Microsoft. Свой ежедневный прогресс он описывает на канале .Net Разработчик. Заметки об изученном материале, советы по повышению производительности и поддержке мотивации, ин

  • .NET Разработчик

    День 1614. #ЧтоНовенького Новинки Превью 5 .NET 8 Продолжаем рассматривать, что нового появилось в превью 5 8й версии .NET. 1. IHttpSysRequestTimingFeature Новый интерфейс IHttpSysRequestTimingFeature предоставляет подробные данные о временных метках, связанных с обработкой запросов при использовании сервера HTTP.sys. Раньше информация о запросе HTTP.sys предоставлялась через интерфейс IHttpSysRequestInfoFeature. С добавлением IHttpSysRequestTimingFeature мы движемся к более чётко определённым API, которые обеспечивают лучший доступ к данным о времени запроса.
    namespace Microsoft.AspNetCore.Server.HttpSys
    {
      public interface IHttpSysRequestTimingFeature
      {
        ReadOnlySpan<long> Timestamps { get; }
        bool TryGetTimestamp(
         HttpSysRequestTimingType timestampType,
         out long timestamp);
        bool TryGetElapsedTime(
         HttpSysRequestTimingType startingTimestampType,
         HttpSysRequestTimingType endingTimestampType,
         out TimeSpan elapsed);
      }
    }
    
    
    Свойство Timestamps предоставляет доступ ко всем временным меткам HTTP.sys. Временные метки получаются с помощью QueryPerformanceCounter, а частота временных меток может быть определена с помощью QueryPerformanceFrequency. Метод TryGetTimestamp извлекает метку времени для предоставленного типа времени, а метод TryGetElapsedTime даёт время, прошедшее между двумя указанными временами. Это усовершенствование предоставляет разработчикам: - Более детальное понимание различных этапов обработки запросов. - Возможности точной диагностики производительности. - Улучшенный доступ к данным о времени запросов HTTP.sys и контроль над ними. 2. Имя хоста в ITlsHandshakeFeature Имя хоста Server Name Indication (SNI) теперь доступно в интерфейсе ITlsHandshakeFeature.
    /// <summary>
    /// Gets the host name from the "server_name" (SNI) extension of the client hello if present.
    /// See <see href="https://www.rfc-editor.org/rfc/rfc6066#section-3">RFC 6066</see>.
    /// </summary>
    string? HostName => null;
    
    
    SNI является частью процесса TLS-рукопожатия и позволяет клиентам указывать имя хоста, к которому они пытаются подключиться. Это позволяет серверам, на которых размещается несколько виртуальных хостов или доменов, предоставлять правильный сертификат безопасности во время процесса установки связи, следовательно, позволяет работать нескольким HTTPS-сайтам (или другим сервисам поверх TLS) на одном IP-адресе без использования одного и того же сертификата для всех сайтов. Обычно SNI обрабатывается только в стеке TLS и используется для выбора соответствующего сертификата, но теперь раскрытие имени хоста позволяет другим компонентам приложения использовать эту информацию для диагностики, ограничения скорости, маршрутизации и т. д. Предоставление имени хоста особенно полезно для крупномасштабных сервисов, управляющих тысячами привязок SNI. С помощью этой функции вы получаете ценную информацию о выбранном SNI во время TLS-рукопожатия, тем самым значительно улучшая свои возможности отладки при росте количества клиентов. Это позволяет быстрее решать проблемы и повышать надёжность обслуживания. Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-5/#servers
  • .NET Разработчик

    День 1613. #ЗаметкиНаПолях Сжатие Ответов в ASP.NET Core Уменьшение размера ответа API может заметно повысить производительность вашего приложения. А поскольку пропускная способность сети является ограниченным ресурсом, следует, по крайней мере, рассмотреть преимущества сжатия ответов. Использовать сжатие ответов в приложениях .NET очень просто. Нужно вызвать два метода: - AddResponseCompression – для настройки сервисов сжатия ответа; - UseResponseCompression – для добавления промежуточного ПО сжатия ответа в конвейер. Сжатие ответов по умолчанию отключено в HTTPS, поэтому его надо явно включить:
    builder.Services
     .AddResponseCompression(opts =>
    {
      opts.EnableForHttps = true;
    });
    
    
    Когда использовать В идеале лучше использовать серверное сжатие ответа, если ваш сервер приложений (IIS, Apache, Nginx) поддерживает его. Если сервер не поддерживает сжатие ответов, то оправдано использование промежуточного ПО. Однако т.к. оно происходит на уровне приложения, производительность обычно падает. Еще одной проблемой является безопасность, т.к. использование сжатия ответов в HTTPS может подвергнуть вас атакам CRIME и BREACH. Вот что можно сделать, чтобы защититься от них: - Добавить токены защиты от подделки (anti-forgery). - Не отправлять секреты приложения в теле запроса. - Добавить ограничитель трафика Настройка провайдеров сжатия При вызове AddResponseCompression по умолчанию добавляются два провайдера сжатия (но можно добавить свои в настройках AddResponseCompression): - BrotliCompressionProvider - GzipCompressionProvider По умолчанию используется сжатие Brotli, если оно поддерживается клиентом. В противном случае будет использоваться Gzip. Можно настроить уровень сжатия для Brotli и Gzip: - Optimal, - Fastest (по умолчанию), - NoCompression, - SmallestSize.
    builder.Services
     .Configure<BrotliCompressionProviderOptions>(opts =>
    {
      opts.Level = CompressionLevel.Optimal;
    });
    
    Заметим, что уровень SmallestSize ожидаемо имеет сильное негативное влияние на время ответа. Итого Сжатие ответов — хороший метод повышения производительности API и снижения сетевых затрат. В идеале желательно использовать серверное сжатие ответов, если оно поддерживается вашим сервером приложений. Если нет, сжатие ответов в приложении доступно в .NET через промежуточное ПО. Это увеличивает нагрузку на ЦП и может подвергнуть HTTPS некоторым рискам безопасности, но есть способы смягчить это. Обычно конфигурации по умолчанию для провайдера сжатия и уровня сжатия дают отличные результаты. Вы можете протестировать значение сжатия ответа в своём приложении и изучить изменения в размере и времени ответа. Попробуйте разные провайдеры сжатия, изменяя заголовок Accept-Encoding клиента, а также настраивая разные уровни сжатия в приложении. Источник: https://www.milanjovanovic.tech/blog/response-compression-in-aspnetcore
  • .NET Разработчик

    День 1612. #Карьера Парное Программирование: Лучшие Практики и Инструменты. Окончание Начало Лучшие практики 1. Чёткое определение ролей Чётко определите роли водителя и штурмана. Водитель пишет код, а штурман проверяет и даёт обратную связь. Часто меняйтесь ролями, чтобы оба разработчика были вовлечены. 2. Эффективная коммуникация Оба разработчика должны активно участвовать, выражать свои мысли и внимательно слушать. Делитесь идеями, задавайте вопросы и обсуждайте код. Используйте инструменты для совместной работы. 3. Уважение и эмпатия Цените мнения, идеи и опыт друг друга. Будьте открыты для конструктивной критики и избегайте личных нападок. Создайте среду, которая поощряет сотрудничество и обучение. 4. Перерывы Важно делать регулярные перерывы, чтобы предотвратить усталость и сохранить продуктивность. Используйте перерывы, чтобы поразмышлять о прогрессе, обсудить проблемы и спланировать следующие шаги. Учитывайте уровень энергии друг друга и соответственно планируйте перерывы. 5. Возможности обучения Делитесь знаниями и опытом с партнёром. Будьте открыты для новых идей и подходов. Поощряйте непрерывное обучение и рост обоих разработчиков. 6. Активные обзоры кода Обсуждайте возможные улучшения, заблаговременно выявляйте дефекты и устраняйте недостатки дизайна. 7. Планирование Перед началом сеанса обсудите и согласуйте цели и задачи. Разбейте работу на более мелкие, управляемые части. Установите сроки и приоритеты задач, чтобы сохранять концентрацию и прогресс. 8. Документирование Делайте заметки, записывайте важные обсуждения, решения и идеи. Создавайте документацию, которой можно поделиться с командой, помогая распространять знания и обеспечивать согласованность по всему проекту. 9. Выводы После завершения сеанса найдите время, чтобы обдумать свой опыт. Обсудите, что получилось, а что можно улучшить. Постоянно совершенствуйтесь на основе извлечённых уроков. Инструменты Live Share Расширение VS и VS Code, которое позволяет разработчикам сотрудничать в режиме реального времени. Replit Онлайн-инструмент, позволяющий сотрудничать с другими разработчиками в браузере, без необходимости загружать или устанавливать какое-либо дополнительное ПО. Идеален, когда просто нужно отредактировать код вместе с другими в режиме реального времени. Поддерживает более 50 языков программирования. CodeSandbox Live Позволяет нескольким разработчикам одновременно работать над одной кодовой базой, что упрощает совместную работу над сложными проектами. Codeanywhere Облачная IDE, которая позволяет писать код, сотрудничать и управлять проектами из любого места, используя любое устройство с подключением к Интернету. Предоставляет полный набор инструментов и функций для облегчения написания кода и оптимизации процесса разработки. CodeTogether Позволяет создавать и присоединяться к совместным сеансам кодирования из Eclipse, IntelliJ или VS Code. Гости могут присоединиться к сеансу из любой поддерживаемой IDE или из браузера. Источник: https://dev.to/documatic/pair-programming-best-practices-and-tools-154j
  • Реклама

  • .NET Разработчик

    День 1611. #Карьера Парное Программирование: Лучшие Практики и Инструменты. Начало В этой серии рассмотрим концепцию парного программирования, его преимущества и полезные инструменты, а также развеем несколько распространённых мифов. Парное программирование — это метод, при котором два разработчика работают вместе над одной и той же задачей. При этом один человек пишет код (водитель), а другой просматривает каждую строку и даёт обратную связь (штурман). Этот подход отличается от традиционного сольного программирования и имеет некоторые преимущества. Обязанность водителя - работа с компьютером и ввод кода. Обязанность штурмана — думать о том, что нужно делать и в каком направлении двигаться. Они постоянно общаются и меняются ролями обычно каждые несколько минут. Преимущества 1. Улучшенное качество кода Два программиста могут быстро выявлять ошибки друг друга, что улучшает качество кода и значительно снижает вероятность пропуска ошибок. Партнёры могут предлагать друг другу ценную информацию, улучшения и получать отзывы о своих идеях, прежде чем приступить к их реализации. Таким образом, команда может создавать более чистый, функциональный и оптимизированный код. 2. Расширение сотрудничества и коммуникации Парное программирование помогает коллегам работать над одной кодовой базой и делиться своими знаниями и навыками, что приводит к лучшему решению проблем, а также устраняет разрыв в общении между коллегами, поскольку способствует общению, позволяя быстро и легко обмениваться информацией. Например, во время работы над новой функцией один программист может объяснить свой мыслительный процесс и идеи, а другой – дать отзыв и задать вопросы, чтобы прояснить, что нужно сделать. Таким образом, команда может работать вместе, чтобы найти лучшее решение и избежать недоразумений. 3. Повышение продуктивности Когда два программиста работают вместе, они могут быстрее выполнять задачи, разделяя ответственность. Один может работать над проблемой, а другой - искать потенциальные ошибки. Таким образом, команда может более эффективно работать и решать проблемы. Хотя это зависит от конкретного человека, некоторые программисты более продуктивны, работая в одиночку. Например, пара, работающая над проектом, может потратить 1-2 часа на выполнение задачи, на выполнение которой у одиночного разработчика ушло бы 3-4 часа. Вторая пара может сосредоточиться на поиске ошибок или других проблем в коде. Это означает, что команда выполнит задачу за меньшее время и с меньшими усилиями, повышая общую продуктивность. Мифы 1. Это дорого На самом деле повышенная стоимость - это инвестиции в продуктивность команды, качество кода и инновации. В долгосрочной перспективе это экономит время и снижает затраты, вследствие обнаружения ошибок на ранних стадиях. 2. Это медленно Парное программирование может быть быстрее, чем другие подходы к кодированию, потому что оно позволяет быстро вносить исправления. Когда два разработчика сотрудничают, они могут избежать многих ошибок и ускорить решение проблем. 3. Это давит на разработчиков Некоторые считают, что парное программирование может оказывать слишком большое давление на разработчиков, что приводит к конфликтам. Однако это происходит только при плохом атмосфере в команде. Так что всё зависит от того, какие у вас отношения с вашим партнёром. Если хорошие, то вас это не коснётся. Окончание следует… Источник: https://dev.to/documatic/pair-programming-best-practices-and-tools-154j
  • .NET Разработчик

    День 1610. #ЗаметкиНаПолях Отключаем HSTS для Локального Хоста в Браузерах на Движке Chromium Http Strict Transport Security (HSTS) — это механизм безопасности, который предписывает браузеру автоматически перенаправлять http-запросы на https перед отправкой запроса на сервер. При разработке веб-приложения иногда полезно отключить HSTS для локального хоста. Это связано с тем, что включение HSTS на локальном хосте влияет на другие приложения. Например, некоторые приложения запускают локальный веб-сервер и открывают браузер. Однако, если они не могут использовать сертификат безопасности, то не могут использовать https. Если веб-сайт один раз активирует HSTS на локальном хосте, эти приложения перестанут работать, поскольку они не прослушивают https. ASP.NET Core достаточно умён, чтобы не отправлять заголовок HSTS, когда приложение работает на локальном хосте. Однако это может быть не так для других веб-фреймворков. Отключение политики HSTS вручную Вы можете открыть страницу about://net-internals/#hsts в браузере, работающем на движке Chromium (Chrome, Edge и т.п.) и удалить политику безопасности домена для localhost в разделе "Delete domain security policies". Использование другого домена для разработки HSTS применяется отдельно для каждого домена. Поэтому вы можете использовать другой домен для вашего приложения, например, myapp.local вместо localhost. Таким образом, даже если приложение использует HSTS, это не повлияет на другие приложения, использующие localhost. Чтобы настроить домен, нужно отредактировать файл hosts (C:\Windows\System32\drivers\etc\hosts), добавив туда запись вроде:
    127.0.0.1 myapp.local
    
    
    Затем, измените applicationUrl в файле launchSettings.json вашего приложения на использование https://myapp.local, и можно использовать https://myapp.local в браузере. См. также «Принудительный HTTPS в Приложениях ASP.NET Core» Источник: https://www.meziantou.net/disabling-hsts-for-localhost-on-chromium-based-browsers.htm
  • .NET Разработчик

    День 1550. #Карьера Создание Асинхронной Рабочей Среды «Вопросик к тебе…» — есть ли что-то более раздражающее, когда ты с головой погружён в отладку? А чтобы вернуться к сложной проблеме после того, как вас отвлекли, может потребоваться уйма времени. Поэтому, всё более популярной становится форма асинхронной удалённой работы. Вся или большая часть работы выполняется в удобное для сотрудников время. Сотрудники используют асинхронные инструменты для общения, а совещаний в реальном времени очень мало. Вероятно, самая распространенная причина – сотрудники в разных часовых поясах. Это даёт компаниям доступ к глобальному рынку кадров. Кроме того, сотрудники могут не только работать, когда им удобно, но и так, как они работают лучше всего. Люди счастливее, когда у них есть гибкость, а когда они счастливее, они более продуктивны. Менее очевидным преимуществом является запись почти каждого разговора. Распространённое возражение против асинхронной работы заключается в том, что усложняется совместная работа, но практика показывает, что асинхронное сотрудничество намного лучше. У каждого есть время подумать и сформулировать мысль. Все сообщения регистрируются, поэтому легко найти, кто что сказал и избежать потери важных знаний. Для менеджера наличие асинхронной команды означает, что нельзя полагаться на такие показатели, как количество отработанных часов. Нужно использовать метрики на основе результатов, которые побуждают членов команды работать более эффективно. Также невозможно сразу получить ответы на все свои вопросы. Вот ещё несколько достойных внимания вещей: 1. Навыки письма Письмо занимает больше времени, чем речь, но оно помогает выразить мысль по-другому. У всех был момент озарения, пока мы печатали мысль, которая нас смущала. 2. Процессы документации Вполне естественно, что часть письменных обсуждений превратится в документацию. Конечно, не вся документация пишется специально. Возможно записывать созвоны и встречи. Эти записи затем служат контекстом для людей, которые не смогли прийти. 3. Правильные инструменты Есть несколько всем известных инструментов: Zoom, Slack, Google Docs и т. д. Но есть инструменты, которые особенно хорошо подходят для асинхронных команд. Например, Stack Overflow for Teams предоставляет командам место для совместной работы, где они могут задавать вопросы и отвечать на них, не прерывая друг друга в чатах реального времени. Проблемы с асинхронной работой 1. Доверие является ключевым Если сотрудникам разрешено работать, когда, где и как они хотят, вы должны им доверять. Некоторым менеджерам может быть трудно это принять. Но главное иметь меры по отслеживанию результатов. Одни отчитываются о своих часах еженедельно, другим платят по результатам. Это позволяет объективно сравнивать производительность. Но сотрудники также должны уметь доверять друг другу. Если вы не можете доверять своим коллегам по команде или своим сотрудникам, асинхронная работа вам не подойдет. 2. Изменение мышления Новым сотрудникам требуется время, чтобы понять, как работать асинхронно, например, переносить длинные обсуждения из почты на соответствующий форум. Часто приходится напоминать членам команды не тратить дополнительное время в выходные или по вечерам. Тот факт, что работа всегда доступна, не означает, что вы должны постоянно работать. 3. Задачи реального времени Некоторые задачи, вроде мозгового штурма, просто не подходят для асинхронной работы. Главное – честно объяснить новым сотрудникам, что без некоторой работы в реальном времени не обойтись. Итого Для технических работников удалённая работа становится нормой. Этот стиль работы требует полной поддержки всей компании и высокой степени доверия между сотрудниками и менеджерами, поэтому он никогда не станет стандартом. Тем не менее, у него есть преимущества, особенно для работников умственного труда, которым нужно тратить много времени на глубокую работу. Источник: https://stackoverflow.blog/2023/03/27/building-a-collaborative-asynchronous-work-environment/
  • .NET Разработчик

    День 1549. #ЗаметкиНаПолях Используем Группы Конечных Точек для Версионирования Минимальных API В ASP.NET Core 7 значительно улучшены минимальные API, в частности добавлена функция групп конечных точек. Это способ объявить некоторую общую информацию о маршрутизации для нескольких конечных точек, а также добавить общие ограничения, такие как авторизация, правила CORS и т. д. Группы конечных точек позволяют управлять версиями API. Просто добавляем базовый маршрут в метод MapGroup, например: MapGroup("/v1") или MapGroup("/v2"). ASP.NET Core 7 предоставляет класс RouteGroupBuilder для создания правил и группировки конечных точек. Создадим две группы конечных точек:
    public static class MyGroups
    {
      public static RouteGroupBuilder 
       Group1(this RouteGroupBuilder g)
      {
        g.MapGet("/", () => 
         Results.Ok(new List<int> { 1, 2, 3 }));
        g.MapGet("/{id}", (int id) => 
         Results.Ok(id));
    
        return g;
      }
    
      public static RouteGroupBuilder 
       Group2(this RouteGroupBuilder g)
      {
        g.MapGet("/", () => 
         Results.Ok(new List<int> { 4, 5, 6 }));
        g.MapGet("/{id}", (int id) => 
         Results.Ok(id + 1));
    
        return g;
      }
    }
    
    
    Для удобства мы сгруппировали конечные точки в отдельных методах расширения. Теперь добавим ограничения и базовый маршрут к каждой группе в основном файле Program.cs. Кроме того, для демонстрации различий добавим Swagger, установив NuGet пакет Microsoft.AspNetCore.OpenApi и добавив необходимые методы расширения:
    var builder = WebApplication.CreateBuilder(args);
    
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
    
    var app = builder.Build();
    
    app.UseSwagger();
    app.UseSwaggerUI();
    
    // Demo group endpoints
    app.MapGroup("/v1")
        .Group1()
        .RequireCors("CorsPolicy1")
        .AllowAnonymous()
        .WithTags("v1");
    
    app.MapGroup("/v2")
        .Group2()
        .RequireCors("CorsPolicy2")
        .RequireAuthorization()
        .RequireRateLimiting("LimitPolicy")
        .WithTags("v2");
    
    app.Run();
    
    
    Как видите, к первой группе применена одна политика CORS, а ко второй группе — другая, а также правила авторизации и ограничения скорости https://t.me/NetDeveloperDiary/1487. Также для удобства отображения в SwaggerUI каждой группе добавлены теги с помощью метода WithTags(…). Результат на картинке ниже. Источник: https://anthonygiretti.com/2023/03/16/asp-net-core7-use-endpoint-groups-to-manage-minimal-apis-versioning/
  • .NET Разработчик

    День 1548. #ЗаметкиНаПолях Управление Контейнерами в .NET 7 SDK В .NET SDK 7.0.200 представлена новая функция, которая позволяет создавать и публиковать образы контейнеров непосредственно из файла проекта. Для этого в файл проекта надо добавить:
    <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
    
    
    Теперь с помощью dotnet publish можно создавать и публиковать приложения .NET в виде образов Docker: - Создавать образ Docker для приложения, не создавая Dockerfile. - Публиковать образ в реестре контейнеров. - Указывать переменные, такие как базовый образ, тег образа и имя реестра в файле проекта. Важно отметить, что устанавливать докер на компьютере не нужно. Пакет SDK для .NET может создать образ, а затем отправить его в удалённый реестр.
    dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release
    
    
    По умолчанию dotnet publish публикует образ в локальном демоне Docker. Чтобы опубликовать образ в реестре контейнеров, нужно добавить новое свойство в файл .csproj:
    <ContainerRegistry>myregistry.azurecr.io</ContainerRegistry>
    
    
    Другой, возможно более предпочтительный, вариант – не засорять файл проекта, а использовать профили публикации, файлы .pubxml в папке /Properties/PublishProfiles:
    <Project>
      <PropertyGroup>
        <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
        <WebPublishMethod>Container</WebPublishMethod>
      </PropertyGroup>
    </Project>
    
    
    Вы можете определить несколько профилей и использовать их для публикации в разных реестрах контейнеров. .NET SDK был протестирован в следующих реестрах: Azure Container Registry, GitLab Container Registry, Google Cloud Artifact Registry, Quay.io, AWS Elastic Container Registry, GitHub Package Registry, and Docker Hub. Перед публикацией потребуется пройти аутентификацию в реестре контейнеров. Подробнее об этом здесь. Указание параметров контейнера По умолчанию SDK определяет лучший базовый образ для использования. Он может использовать значения свойств вашего проекта, таких как TargetFramework, или проверять, является ли приложение автономным или приложением ASP.NET Core. Тем не менее, вы можете переопределить базовый образ по умолчанию, порт, имя контейнера, тэг и т.п.:
    <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:7.0</ContainerBaseImage>
    <ContainerImageName>mycompany/my-awesome-webapp</ContainerImageName>
    <ContainerImageTag>1.2.3-alpha2</ContainerImageTag>
    <ItemGroup>
      <ContainerPort Include="80" Type="tcp" />
    </ItemGroup>
    
    
    Про другие настройки контейнера можно почитать здесь. Источник: https://laurentkempe.com/2023/03/13/dotnet-7-sdk-built-in-container-improvements/
  • .NET Разработчик

    День 1547. #Microservices 12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Окончание Начало Продолжение 10. Сделайте монолит модульным Если ваш монолит представляет собой запутанный клубок кода, вы вполне можете получить запутанный клубок распределённого кода после завершения миграции. Подобно уборке дома перед капитальным ремонтом, модульность монолита является необходимым подготовительным этапом. Модульный монолит — это паттерн разработки ПО, представляющий собой вертикально расположенные модули, независимые и взаимозаменяемые. Противоположностью является классический N-уровневый монолит, в коде которого слишком много зависимостей (иногда циклических), что затрудняет внесение изменений. Модульный монолит — ступенька к микросервисам. Модули могут обмениваться данными только через общедоступные API и по умолчанию всё приватно. В результате код менее переплетён, отношения легко идентифицировать, а зависимости чётко очерчены. Два паттерна могут помочь вам провести рефакторинг монолита: 1) Душитель Проводится рефакторинг монолита от края к центру, постепенно переписывая отдельные функции, пока монолит не будет полностью переделан. Подробнее о паттерне «Душитель». 2) Слой защиты от повреждений Вы обнаружите, что в некоторых случаях изменения в одном модуле распространяются на другие по мере рефакторинга монолита. Чтобы бороться с этим, вы можете создать слой перевода между быстро меняющимися модулями. Этот слой защиты предотвращает влияние изменений в одном модуле на остальные. Подробнее о паттерне «Слой защиты от повреждений». 11. Разделите данные Сила микросервисов в возможности развёртывать любой микросервис в любое время практически без координации с другими микросервисами. Вот почему следует любой ценой избегать связывания данных, поскольку оно создаёт зависимости между сервисами. Каждый микросервис должен иметь отдельную и независимую базу данных. Может быть шокирующим осознание того, что вам нужно денормализировать общую базу данных монолита на (часто избыточные) меньшие базы данных. Но локальность данных — это то, что в итоге позволит микросервисам работать автономно. После разделения нужно будет установить механизмы для синхронизации старых и новых данных во время перехода. Вы можете, например, настроить сервис зеркалирования данных или изменить код, чтобы транзакции записывались в оба набора баз данных. 12. Улучшите наблюдение Новая система должна быть быстрее, производительнее и масштабируемее, чем старая. Иначе зачем возиться с микросервисами? Нужен базовый уровень для сравнения старого с новым. Перед началом миграции убедитесь, что у вас есть хорошие метрики и журналы. Может быть хорошей идеей установить какую-нибудь централизованную службу ведения журналов и мониторинга, так как это ключевой компонент для наблюдения за любым микросервисным приложением. Итого Путь к микросервисам никогда не бывает лёгким. Но я надеюсь, что с помощью этих советов вы сможете сэкономить время и нервы. Не забывайте выполнять итерации небольшими шагами, использовать CI/CD, чтобы гарантировать, что монолит тестируется на регрессии, и хранить всё в одном репозитории, чтобы вы всегда могли отмотать назад, если что-то пойдет не так. Источник: https://semaphoreci.com/blog/monolith-microservices
  • .NET Разработчик

    День 1546. #Microservices 12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Продолжение Начало 6. Установите API-шлюз или обратный HTTP-прокси. По мере развёртывания микросервисов необходимо разделять входящий трафик. Мигрированные функции предоставляются новыми сервисами, а старая функциональность обслуживается монолитом. Существует несколько способов маршрутизации запросов в зависимости от их характера: - API-шлюз https://t.me/NetDeveloperDiary/1106 позволяет перенаправлять вызовы API на основе таких условий, как аутентифицированность пользователя, файлы cookie, флаги функций или шаблоны URI. - Обратный HTTP-прокси делает то же самое, но для HTTP-запросов. В большинстве случаев монолит реализует пользовательский интерфейс, поэтому большая часть трафика будет идти туда, по крайней мере, поначалу. Используйте API-шлюзы и обратные прокси для маршрутизации запросов к соответствующей конечной точке. Вы можете переключаться между монолитом и микросервисами на очень мелком уровне. После завершения миграции шлюзы и прокси-серверы останутся: они являются стандартным компонентом любого микросервисного приложения, поскольку обеспечивают переадресацию и балансировку нагрузки. Они также могут функционировать как автоматические выключатели, если сервис выходит из строя. 7. Рассмотрите паттерн «монолит в коробке» (monolith-in-the-box) Это применимо только в том случае, если вы планируете использовать контейнеры или Kubernetes для микросервисов. В этом случае контейнеризация может помочь вам гомогенизировать вашу инфраструктуру. Паттерн «монолит в коробке» заключается в запуске монолита внутри контейнера. Если вы никогда раньше не работали с контейнерами, это хорошая возможность познакомиться с этой технологией. Нужно многому научиться, поэтому спланируйте обучение: 1) Изучите Docker и контейнеры. 2) Запустите свой монолит в контейнере. 3) Разрабатывайте и запускайте микросервисы в контейнере. 4) После завершения миграции и освоения контейнеров изучите Kubernetes. 5) По ходу работы можно масштабировать микросервисы и постепенно переводить на них трафик. 8. Подготовьтесь к изменениям Чтобы изучить микросервисы, требуется время, поэтому лучше начать с малого и привыкнуть к новой парадигме. Оставьте достаточно времени для того, чтобы каждый разработчик мог перестроиться, повысить свою квалификацию и учиться на ошибках, не ограничивая себя дедлайнами. Во время этих первых пробных шагов вы многое узнаете о распределённых вычислениях. Вам придётся иметь дело с облачным соглашением об уровне обслуживания, настраивать соглашения об уровне обслуживания для собственных сервисов, внедрять мониторинг и оповещения, определять каналы связи между группами разработчиков и выбирать стратегию развёртывания. Выберите что-нибудь лёгкое для начала, например пограничные сервисы, которые мало пересекаются с остальной частью монолита. Например, в качестве первого шага вы можете создать микросервис аутентификации и маршрутизировать запросы на вход в систему. 9. Используйте флаги функций Флаги функций — это программный метод изменения функциональности системы без её повторного развёртывания. Вы можете использовать флаги функций, чтобы включать и выключать части монолита по мере их миграции, экспериментировать с альтернативными конфигурациями или проводить A/B-тестирование. Типичный рабочий процесс для миграции с флагом функции: 1) Определите часть функциональности монолита для переноса на микросервис. 2) Оберните функциональность флагом функции. Повторно разверните монолит. 3) Создайте и разверните микросервис. 4) Протестируйте микросервис. 5) Когда всё будет готово, отключите функцию на монолите, выключив флаг. 6) Повторяйте, пока миграция не будет завершена. Поскольку флаги функций позволяют развёртывать неактивный код в рабочей среде и включать/выключать его в любое время, мы можем отделить выпуски функций от фактического развёртывания. Это даёт разработчикам огромную степень гибкости и контроля. Окончание следует… Источник: https://semaphoreci.com/blog/monolith-microservices
  • .NET Разработчик

    День 1545. #Microservices 12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Начало Вы наконец решили, что пришло время избавиться от старого, неуклюжего монолита. Над ним долго работали, но он стал настолько большим, что больше усилий тратится на его обслуживание, чем на добавление функций. Пришло время попробовать другой подход, например, микросервисы. Совет: не списывайте со счетов монолит. При некоторой подготовке он может сослужить вам хорошую службу на протяжении всего перехода. Вот 12 советов, как сделать переход на микросервисы максимально плавным. 1. Убедитесь, что вы знаете, во что ввязываетесь Переходя от монолита к микросервисам, вы меняете не только способ написания кода, но и операционную модель компании. Мало того, что придётся изучить новый, более сложный технологический стек, менеджменту потребуется скорректировать культуру работы и реорганизовать людей в более мелкие кросс-функциональные команды. Важно как можно лучше изучить компромиссы, связанные с внедрением микросервисов, ещё до начала работы. Вы должны быть абсолютно уверены, что именно микросервисы являются правильным решением для вас. Начните с изучения как можно большего об архитектуре микросервисов и просмотрите несколько примеров проектов, например, здесь или здесь. 2. Составьте план Старая система должна оставаться работоспособной во время перехода. Шаги миграции можно отслеживать с помощью тикетов. Это не только помогает придерживаться плана, но и даёт владельцам бизнеса прозрачность относительно вашего прогресса. При планировании необходимо: - Распутать зависимости внутри монолита. - Определить необходимые микросервисы. - Разработать модели данных для микросервисов. - Разработать метод переноса и синхронизации данных между базой данных монолита и базами данных микросервисов. - Разработать API и спланировать обратную совместимость. - Измерить базовую производительность монолита. - Установить цели для доступности и производительности новой системы. 3. Поместите всё в монорепозиторий Когда вы разбиваете монолит, большая часть кода будет перемещена из него в новые микросервисы. Используйте общий монорепозиторий для размещения кода микросервисов вместе с монолитом. Монорепозиторий поможет отслеживать подобные изменения. Кроме того, наличие всего в одном месте поможет быстрее восстанавливаться после сбоев. Вероятно, ваш монолит уже содержится в одном репозитории, поэтому вопрос сводится к созданию новых папок для микросервисов. 4. Используйте общий конвейер CI Во время разработки вы будете не только постоянно выпускать новые микросервисы, но и развёртывать необходимые текущие изменения в монолите. Чем быстрее и безболезненнее будет этот процесс, тем быстрее вы сможете прогрессировать. Настройте непрерывную интеграцию и доставку (CI/CD) для автоматического тестирования и развёртывания кода. Если вы используете монорепозиторий, настройте раздельные конвейеры для развёртывания монолита и микросервисов, а также убедитесь в том, что вы получаете полноценные отчёты о тестировании и развёртывании, чтобы быстро обнаруживать и устранять сбои. 5. Убедитесь, что у вас достаточно тестов Рефакторинг гораздо более эффективен и приносит больше удовлетворения, когда мы уверены, что в коде нет регрессий. Автоматизированные тесты дают уверенность в непрерывном выпуске обновлений. Отличным местом для начала является пирамида тестирования. Она может помочь разработать тесты для микросервисов. Старайтесь запускать тесты на локальном компьютере разработки так же часто, как и в конвейере непрерывной интеграции. Продолжение следует… Источник: https://semaphoreci.com/blog/monolith-microservices
  • .NET Разработчик

    День 1544. #ЧтоНовенького Microsoft Представляет Нативный AOT для ASP.NET Core В новой версии .NET 8 Preview 3 Microsoft представила первоначальную поддержку нативной компиляции Ahead-of-Time (AOT) в компоненте веб-разработки ASP.NET Core. Хотя выбор варианта публикации AOT обеспечивает множество преимуществ в определенных сценариях, он также приводит к проблемам совместимости, поэтому команда разработчиков добавляет функциональные возможности постепенно. В руководстве по развёртыванию Microsoft Native AOT объясняется, что поддержка AOT позволяет разработчикам создавать автономные приложения, скомпилированные с помощью AOT в машинный код, которые могут работать на компьютерах, где не установлена среда выполнения .NET, что приводит к преимуществам, в том числе сокращению времени запуска до 80 процентов и уменьшению размера приложения до 87 процентов. Microsoft представила список преимуществ AOT: 1. Уменьшение занимаемого места на диске. AOT создаёт один исполняемый файл, содержащий программу вместе с подмножеством кода из внешних зависимостей, которые использует программа. Уменьшение размера исполняемого файла может привести к: - Меньшему размеру образов контейнеров в сценариях контейнерного развертывания. - Сокращению времени развертывания из-за меньшего размера образов. 2. Сокращение времени запуска. Отчасти из-за удаления JIT-компиляции. Это означает, что: - Приложение будет быстрее готово обслуживать запросы. - Улучшится развёртывание с помощью оркестраторов, которые управляют переходами от одной версии приложения к другой. 3. Снижение потребности в памяти. Нативные AOT-приложения могут иметь меньшую потребность в памяти в зависимости от работы, выполняемой приложением. Уменьшение потребления памяти может привести к большей плотности развертывания и улучшению масштабируемости. Однако, поскольку не все функции ASP.NET Core или часто используемые библиотеки ASP.NET Core совместимы с нативным AOT (см. диаграмму), первоначальная работа сосредоточена на включении поддержки приложений, использующих минимальные API или gRPC и развёрнутых в облаке. Таким образом, Preview 3 включает новый параметр Enable native AOT publish (Включить нативную публикацию AOT) в шаблоне проекта «ASP.NET Core gRPC Service», а также новый шаблон проекта «ASP.NET Core API», который также включает этот параметр для проектов, ориентированных на API в облаке. Microsoft перечислила некоторые ключевые требования совместимости для нативных AOT-приложений: - Отсутствие динамической загрузки (например, Assembly.LoadFile) - Отсутствие кодогенерации через JIT (System.Reflection.Emit) - Отсутствие C++/CLI - Отсутствие встроенного COM (для Windows) - Обязательный тримминг, который имеет ограничения - Компиляция в один файл (с известными проблемами совместимости) - Приложения должны включать необходимые библиотеки среды выполнения, что приведёт к увеличению размера исполняемого файла по сравнению с приложениями, зависящими от наличия среды выполнения. «Нативное развёртывание AOT подходит не для каждого приложения, но в сценариях, где преимущества, предлагаемые AOT, существенны, оно может оказать огромное влияние», — говорится в сообщении Microsoft, — «В будущих предварительных версиях мы поработаем над тем, чтобы включить больше функций ASP.NET Core и поддерживать в нативном AOT такие технологии, как аутентификация JWT, валидация параметров, доступ к данным ADO.NET для SQLite и PostgreSQL и OpenTelemetry. Мы также работаем над улучшением возможностей Visual Studio для настройки и работы над проектами ASP.NET Core, предназначенными для нативного AOT». Источник: https://visualstudiomagazine.com/articles/2023/04/17/aot-aspnet-core.aspx?m=1
  • .NET Разработчик

    День 1543. #Курсы Сегодня порекомендую вам ютуб канал Зонара Хорвата (Zoran Horvat) Зоран - консультант, разработчик и архитектор ПО, автор на Pluralsight, Udemy и YouTube. На его канале вы найдёте советы по разработке и архитектуре, паттернах проектирования, чистом коде, новинкам языка C# и т.п. Видео, которое попалось мне, вышло совсем недавно и называется Are Design Patterns Dead in C#? (Паттерны Проектирования в C# Умерли?) В нём Зоран на примере оригинальной книги «Паттерны Проектирования» банды четырёх рассуждает, полезна ли до сих пор информация о паттернах проектирования и применимы ли они в современной разработке в .NET. Не буду спойлерить, смотрите до конца))) Кстати, про паттерны проектирования вы можете почитать на канале по тегу #DesignPatterns.
    Are Design Patterns Dead in C#?

    When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper, complex design pattern! If it was long ago, then you are not alone. Think of all the decorators, adapters, builders, chains of responsibility, observers, states, and visitors you never made. You never made... because they were there. This video will show you a glimpse of modern code which will incorporate no design patterns at all. And yet, it will mostly consist of design patterns. How come? The answer is in libraries, the framework, the language syntax, in all the elements we use when writing code. Those elements are built on top of numerous patterns and they are exposing interfaces and methods that are so simple, that consuming any of these design patterns takes no more than a single method call or instantiation of a single object. By the end of this video, you will learn that design patterns are still everywhere in our code, the same as they ever were, but that we are not responsible to implement them in most cases. Corner cases will remain, though. If you are writing low-level library code, extensions, and frameworks, then you will likely keep implementing all those design patterns over and over again. But keep this principle in mind: implement the design patterns in your library, so that its users won't have to. Information about source code: The source will soon be available to registered members on this channel. More information coming soon! ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Thank you so much for watching! Please like, comment & share this video as it helps me a ton!! Don't forget to subscribe to my channel for more amazing videos and make sure to hit the bell icon to never miss any updates.🔥❤️ ✅🔔 Subscribe ► https://www.youtube.com/channel/UCxsWfh8LCcn55mFB6zGBT1g?sub_confirmation=1 ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ⭐ CONNECT WITH ME 📱👨 🌐Buy me a Coffee ► https://ko-fi.com/zoranhorvat 🗳 Pluralsight Courses ► https://codinghelmet.com/go/pluralsight 📸 Udemy Courses ► https://codinghelmet.com/go/udemy 📸 Join me on Twitter ► https://twitter.com/zoranh75 🌐 Read my Articles ► https://codinghelmet.com/articles 📸 Join me on LinkedIn ► https://www.linkedin.com/in/zoran-horvat/ For collaboration or any queries: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 👨 About Me 👨 Hi, I’m Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my YouTube channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications. ❤️ ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ⚡️RIGHT NOTICE: The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above. ⭐For copyright or any inquiries, please contact us via a comment #designpatterns #dotnet #csharp

    YouTube
  • .NET Разработчик

    День 1542. #Книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка» (Клеппман М. — СПб.: Питер, 2022). Осилил «кабанчика»! Многие называют эту книгу одной из обязательных к прочтению для разработчика ПО. Первые главы читались удивительно легко. В них описывались основные принципы создания ПО (надёжность, масштабируемость и удобство сопровождения), модели данных и способы их хранения, кодирование и т.п. Затем, видимо, сказалось отсутствие опыта работы с распределёнными системами, потому что, когда разговор пошёл про репликации, секционирование, распределённые транзакции и консенсус, приходилось просто продираться сквозь главы. Я уже давно понял, что информация, которую я не могу соотнести со своим опытом, у меня усваивается очень тяжело. И если, читая первые главы, я постоянно думал: «Вот это мы используем, а вот это можно применить там-то», то дальше пошёл вакуум чисто теоретической информации, для которой не было контекста, да и особенных знаний предмета. Третья часть книги рассказывает о пакетной и потоковой обработке. Тут было что-то среднее, потому что с MapReduce, Hadoop, RabbitMQ и Kafka я не работал, но хотя бы что-то о них слышал. Итого Книга действительно очень крутая, даёт теоретическую базу для множества аспектов разработки больших масштабируемых приложений, а также сотни ссылок на источники, в которых можно узнать детали. Однако совсем уж «мастридом» я бы её не назвал. Она, наверное, даже не для сеньоров, а для архитекторов ПО. Читать её кому-то уровнем ниже просто «для общего развития» я бы не советовал. Всё-таки, она скорее обо всём понемногу, поэтому вряд ли поможет, если вы хотите изучить какую-то конкретную область в конкретном стеке технологий. Но это мой личный опыт. Кто читал, оставляйте мнения в комментариях.
  • .NET Разработчик

    День 1541. #МоиИнструменты Обфускаторы в .NET Распространенным подходом к защите интеллектуальной собственности является обфускация) символов и сокрытие кода IL. Веб-разработчики должны уделить особое внимание обфускации, поскольку код отправляется в браузер клиента. На самом деле обфускаторов для .NET десятки и помимо перечисленных ниже. Многие из этих проектов так или иначе заброшены. Создание обфускатора для .NET — популярная и интересная задача, которую упростили библиотеки, такие как проект Mono.Cecil. Однако создать функциональный обфускатор, который должным образом запутывает код, не добавляя ошибок, сложно. Работающие обфускаторы .NET являются скорее исключением, чем нормой. 1. Preemptive Dotfuscator Microsoft продвигала Dotfuscator как обфускатор для .NET, но, скорее всего, они никогда не собирались его предоставлять как утилиту. Разработчики, переходящие с C++ и VB6 на .NET, не осознавали, что их код может быть раскрыт, и это считалось недостатком новой платформы. Несмотря на то, что Preemptive Dotfuscator является функциональным продуктом, недавно они на 50% увеличили плату за подписку, что вряд ли обосновано. 2. Eazfuscator.NET Eazfuscator.NET имеет хорошую репутацию, доступные цены и множество поклонников в Интернете. Однако инструмент не предоставляет файлы сопоставления. Сопоставление файлов сборок, сгенерированных Dotfuscator, позволяет декодировать трассировки производственного стека, что необходимо для отслеживания проблем в производственном коде и их устранения. Eazfuscator.NET шифрует обфусцированные символы с помощью закрытого ключа. Таким образом, трассировки производственного стека могут быть декодированы и их возможно расшифровать, как показано в этой статье. 3. Obfuscar Обфускатор с открытым исходным кодом. К сожалению, не всегда может генерировать код без ошибок из-за известных недостатков, таких как TypeLoadExceptions и невозможность обфусцировать все значения перечислений. 4. .NET Reactor Понятный пользовательский интерфейс .NET Reactor, полный всплывающих подсказок и ссылок на обширную документацию, - то, что нужно для сложных инструментов, таких как обфускаторы. Полезно иметь описания функций, встроенные в UI, чтобы пользователям не приходилось снова и снова просматривать документацию или обращаться за поддержкой. Хотя поддержка у .NET Reactor быстрая и эффективная. Итого Чтобы найти лучший инструмент для ваших нужд, важно начать с использования инструмента, который хорошо поддерживается последними обновлениями и коммитами. Важный аспект обфускаторов, не рассмотренный в этом посте, - различные дополнительные функции защиты, такие как виртуализация, шифрование строк, защита от несанкционированного доступа… Кроме того, рекомендуется уделить внимание специальной защите при разработке вашего кода, помимо обфускатора. Имейте в виду, что существуют проекты, подобные de4dot, для обратного проектирования кода, сгенерированного популярными обфускаторами. Источник: https://blog.ndepend.com/in-the-jungle-of-net-obfuscator-tools/
  • Реклама

  • .NET Разработчик

    День 1540. #ЧтоНовенького GitHub Представил Правила Репозитория Правила для репозиториев — это следующая ступень эволюции защиты веток GitHub, которая поможет сделать репозитории более безопасными и совместимыми. Правила позволяют легко определять средства защиты для веток и тегов в ваших репозиториях и, если вы являетесь клиентом GitHub Enterprise Cloud, применять их в своей организации. Кроме того, всем, кто работает с вашими репозиториями, проще узнать, какие правила действуют. В основе лежит возможность определять наборы правил (правила, которые применяются совместно). Например, вы можете потребовать, чтобы все коммиты в ветке были подписаны и чтобы у этих коммитов было два рецензента. Наборы правил также можно применять к тегам, что позволяет применять правила к релизам. Страница набора правил — это центральное место для просмотра и управления всеми правилами репозитория. Она показывает действующие правила и позволяет добавлять новые наборы правил или редактировать существующие. При создании набора правил вы определяете его статус: активный (active) или отключенный (disabled). Для слияния коммита, все активные наборы правил должны проходить, в то время как отключенные наборы правил не применяются. Отключенные наборы не будут препятствовать слияниям, но позволят администраторам создавать правила перед их применением. Клиентам Enterprise Cloud также доступен статус «оценка» (evaluate) для наборов правил: режим «пробного запуска» для понимания влияния новых правил до того, как они будут активны и применены. Правила можно применить к ветке или тегу с возможностью выбора ветки по умолчанию, всех веток, а также веток или тегов, соответствующих шаблону fnmatch. Вы можете добавить несколько шаблонов в набор правил, чтобы применить его к различным стилям именования веток и тегов. Вы всегда можете узнать, какие правила действуют для репозитория. Любой, у кого есть доступ на чтение к репозиторию, может просматривать его правила и их значение. К обзору наборов правил можно перейти со страницы веток, щёлкнув на значок щита, а также из пулл-реквеста и из выходных данных Git CLI, когда правила блокируют отправку. Подробности использования правил репозитория доступны в документации. Кроме того, авторы ждут ваших отзывов в обсуждении. Источник: https://github.blog/changelog/2023-04-17-introducing-repository-rules-public-beta/
  • .NET Разработчик

    День 1539. #ЗаметкиНаПолях Чистые SQL-запросы в EF Core В EF7 появилась поддержка возврата скалярных типов с помощью SQL-запросов. В EF8 появилась поддержка запросов несопоставленных (unmapped) типов с помощью чистого SQL. Это то, что Dapper предлагает по умолчанию, и приятно видеть, что EF Core догоняет его. EF Core и SQL В EF8 чистые SQL-запросы могут возвращать любой тип без необходимости включать его в модель EF. Вы можете запрашивать несопоставленные типы с помощью методов SqlQuery и SqlQueryRaw. Метод SqlQuery использует интерполяцию строк для параметризации запроса, защищая от атак SQL-инъекцией. Вот пример запроса, возвращающего список OrderSummary:
    var start = new DateOnly(2023, 1, 1);
    var orders = await dbContext
      .Database
      .SqlQuery<Order>(
       @$"SELECT * FROM Orders 
          AS o WHERE o.Created >= {start}")
      .ToListAsync();
    
    
    В БД будет отправлен следующий запрос:
    SELECT * FROM Orders AS o WHERE o.Created >= @p0
    
    
    Тип, используемый для результата запроса, может иметь параметризованный конструктор. Имена свойств не обязательно должны совпадать с именами столбцов в базе данных, но они должны совпадать с именами полей в результирующем наборе. Вы также можете выполнять чистые SQL-запросы к представлениям, функциям и хранимым процедурам. SQL + LINQ Интересной особенностью SqlQuery является то, что он возвращает IQueryable, который можно дополнить с помощью LINQ. Можно добавить оператор Where после вызова SqlQuery:
    var orders = await dbContext
      .Database
      .SqlQuery<Order>(
        "SELECT * FROM Orders AS o")
      .Where(o => o.Created >= start)
      .ToListAsync();
    
    Однако, в результате получится неоптимальный запрос:
    SELECT s.Id, s.CustomerId, s.Price, s.Created
    FROM (
      SELECT * FROM Orders AS o
    ) AS s
    WHERE s.Created >= @p0
    
    
    Также возможно добавить OrderBy, Skip и Take:
    var orders = await dbContext
      .Database
      .SqlQuery<Order>(
        @$"SELECT * FROM Orders AS o 
          WHERE o.Created >= {start}")
        .OrderBy(o => o.Id)
        .Skip(10)
        .Take(5)
        .ToListAsync();
    
    
    Получим следующий запрос:
    SELECT s.Id, s.CustomerId, s.Price, s.Created
    FROM (
      SELECT * FROM Orders AS o WHERE o.Created >= @p0
    ) AS s
    ORDER BY s.Id
    OFFSET @p1 ROWS FETCH NEXT @p2 ROWS ONLY
    
    
    Производительность аналогична LINQ-запросам с проекцией с помощью Select. SQL-запросы для модификации данных Если вы хотите изменить данные в базе данных с помощью SQL, вы обычно пишете запрос, который не возвращает результата. Запрос может быть UPDATE, DELETE или вызовом хранимой процедуры. Для этого можно использовать метод ExecuteSql:
    dbContext.Database.ExecuteSql(
      @$"UPDATE Orders SET Status = 5 
         WHERE Created >= {start}");
    
    
    ExecuteSql также защищает от SQL-инъекций путем параметризации аргументов, как и SqlQuery. В EF7 можно написать приведённый выше запрос с помощью LINQ и метода ExecuteUpdate. Также есть метод ExecuteDelete для удаления записей. Источник: https://www.milanjovanovic.tech/blog/ef-core-raw-sql-queries
  • .NET Разработчик

    День 1538. #ЧтоНовенького Новые Функции C#12. Окончание В недавно выпущенном превью 3 .NET 8 добавили несколько интересных новых функций C#. Начало. Первичные конструкторы 2. Директивы using для дополнительных типов Добавлен ещё один вариант использования ключевого слова using. Теперь с помощью него можно объявить дополнительный тип:
    using Measurement = (string, int);
    using PathOfPoints = int[];
    using DatabaseInt = int?;
    
    
    Вы можете использовать псевдоним практически для любого типа. Можно создавать псевдонимы для обнуляемых типов-значений, однако нельзя использовать псевдонимы для обнуляемых ссылочных типов. Кортежи особенно интересны, потому что вы можете включать имена и типы элементов:
    using Measurement = (string Units, int Distance);
    
    
    Псевдонимы можно использовать так же, как любые типы:
    public void F(Measurement x)
    { }
    
    
    Псевдонимы типов позволяют абстрагироваться от фактических типов, которые вы используете, и позволяют давать понятные имена запутанным или длинным общим именам, что улучшает читаемость кода. Вы можете оставить отзыв о первичных конструкторах на GitHub в обсуждении Preview Feedback: C# 12 Alias any type. 3. Значения по умолчанию для лямбда-выражений Синтаксис такой же, как и для других параметров по умолчанию:
    var addWithDefault = 
     (int addTo = 2) => addTo + 1;
    addWithDefault(); // 3
    addWithDefault(5); // 6
    
    
    Значение по умолчанию будет передано в метаданные и доступно через рефлексию как DefaultValue свойства ParameterInfo лямбда-метода:
    addWithDefault.Method
     .GetParameters()[0].DefaultValue; // 2
    
    
    До C#12 нужно было использовать локальную функцию или громоздкое DefaultParameterValue из пространства имен System.Runtime.InteropServices, чтобы указать значение по умолчанию для параметров лямбда-выражения. Эти подходы по-прежнему работают, но их сложнее читать, и они несовместимы со значениями по умолчанию для методов. Теперь будет согласованный поиск значений параметров по умолчанию для методов, конструкторов и лямбда-выражений. Вы можете оставить отзыв о первичных конструкторах на GitHub в обсуждении Preview Feedback: C# 12 Default values in lambda expressions. Чтобы попробовать эти новинки, загрузите последнюю превью версию Visual Studio 17.6 или превью 3 .NET 8. Источник: https://devblogs.microsoft.com/dotnet/check-out-csharp-12-preview/