День 1539. #ЗаметкиНаПолях
Чистые SQL-запросы в EF Core
В EF7 появилась поддержка возврата скалярных типов с помощью SQL-запросов. В EF8 появилась поддержка запросов несопоставленных (unmapped) типов с помощью чистого SQL. Это то, что Dapper предлагает по умолчанию, и приятно видеть, что EF Core догоняет его.
EF Core и SQL
В EF8 чистые SQL-запросы могут возвращать любой тип без необходимости включать его в модель EF. Вы можете запрашивать несопоставленные типы с помощью методов SqlQuery и SqlQueryRaw. Метод SqlQuery использует интерполяцию строк для параметризации запроса, защищая от атак SQL-инъекцией.
Вот пример запроса, возвращающего список OrderSummary:
SQL + LINQ
Интересной особенностью SqlQuery является то, что он возвращает IQueryable, который можно дополнить с помощью LINQ. Можно добавить оператор Where после вызова SqlQuery:
SQL-запросы для модификации данных
Если вы хотите изменить данные в базе данных с помощью SQL, вы обычно пишете запрос, который не возвращает результата. Запрос может быть UPDATE, DELETE или вызовом хранимой процедуры. Для этого можно использовать метод ExecuteSql:
Источник: https://www.milanjovanovic.tech/blog/ef-core-raw-sql-queries
Чистые 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Также возможно добавить OrderBy, Skip и Take:
FROM (
SELECT * FROM Orders AS o
) AS s
WHERE s.Created >= @p0
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Производительность аналогична LINQ-запросам с проекцией с помощью Select.
FROM (
SELECT * FROM Orders AS o WHERE o.Created >= @p0
) AS s
ORDER BY s.Id
OFFSET @p1 ROWS FETCH NEXT @p2 ROWS ONLY
SQL-запросы для модификации данных
Если вы хотите изменить данные в базе данных с помощью SQL, вы обычно пишете запрос, который не возвращает результата. Запрос может быть UPDATE, DELETE или вызовом хранимой процедуры. Для этого можно использовать метод ExecuteSql:
dbContext.Database.ExecuteSql(ExecuteSql также защищает от SQL-инъекций путем параметризации аргументов, как и SqlQuery. В EF7 можно написать приведённый выше запрос с помощью LINQ и метода ExecuteUpdate. Также есть метод ExecuteDelete для удаления записей.
@$"UPDATE Orders SET Status = 5
WHERE Created >= {start}");
Источник: https://www.milanjovanovic.tech/blog/ef-core-raw-sql-queries
👍15
День 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/
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/
👍5
День 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
Распространенным подходом к защите интеллектуальной собственности является обфускация) символов и сокрытие кода 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/
👍14
День 1542. #Книги
«Высоконагруженные приложения. Программирование, масштабирование, поддержка» (Клеппман М. — СПб.: Питер, 2022).
Осилил «кабанчика»! Многие называют эту книгу одной из обязательных к прочтению для разработчика ПО.
Первые главы читались удивительно легко. В них описывались основные принципы создания ПО (надёжность, масштабируемость и удобство сопровождения), модели данных и способы их хранения, кодирование и т.п.
Затем, видимо, сказалось отсутствие опыта работы с распределёнными системами, потому что, когда разговор пошёл про репликации, секционирование, распределённые транзакции и консенсус, приходилось просто продираться сквозь главы. Я уже давно понял, что информация, которую я не могу соотнести со своим опытом, у меня усваивается очень тяжело. И если, читая первые главы, я постоянно думал: «Вот это мы используем, а вот это можно применить там-то», то дальше пошёл вакуум чисто теоретической информации, для которой не было контекста, да и особенных знаний предмета.
Третья часть книги рассказывает о пакетной и потоковой обработке. Тут было что-то среднее, потому что с MapReduce, Hadoop, RabbitMQ и Kafka я не работал, но хотя бы что-то о них слышал.
Итого
Книга действительно очень крутая, даёт теоретическую базу для множества аспектов разработки больших масштабируемых приложений, а также сотни ссылок на источники, в которых можно узнать детали. Однако совсем уж «мастридом» я бы её не назвал. Она, наверное, даже не для сеньоров, а для архитекторов ПО. Читать её кому-то уровнем ниже просто «для общего развития» я бы не советовал. Всё-таки, она скорее обо всём понемногу, поэтому вряд ли поможет, если вы хотите изучить какую-то конкретную область в конкретном стеке технологий.
Но это мой личный опыт. Кто читал, оставляйте мнения в комментариях.
«Высоконагруженные приложения. Программирование, масштабирование, поддержка» (Клеппман М. — СПб.: Питер, 2022).
Осилил «кабанчика»! Многие называют эту книгу одной из обязательных к прочтению для разработчика ПО.
Первые главы читались удивительно легко. В них описывались основные принципы создания ПО (надёжность, масштабируемость и удобство сопровождения), модели данных и способы их хранения, кодирование и т.п.
Затем, видимо, сказалось отсутствие опыта работы с распределёнными системами, потому что, когда разговор пошёл про репликации, секционирование, распределённые транзакции и консенсус, приходилось просто продираться сквозь главы. Я уже давно понял, что информация, которую я не могу соотнести со своим опытом, у меня усваивается очень тяжело. И если, читая первые главы, я постоянно думал: «Вот это мы используем, а вот это можно применить там-то», то дальше пошёл вакуум чисто теоретической информации, для которой не было контекста, да и особенных знаний предмета.
Третья часть книги рассказывает о пакетной и потоковой обработке. Тут было что-то среднее, потому что с MapReduce, Hadoop, RabbitMQ и Kafka я не работал, но хотя бы что-то о них слышал.
Итого
Книга действительно очень крутая, даёт теоретическую базу для множества аспектов разработки больших масштабируемых приложений, а также сотни ссылок на источники, в которых можно узнать детали. Однако совсем уж «мастридом» я бы её не назвал. Она, наверное, даже не для сеньоров, а для архитекторов ПО. Читать её кому-то уровнем ниже просто «для общего развития» я бы не советовал. Всё-таки, она скорее обо всём понемногу, поэтому вряд ли поможет, если вы хотите изучить какую-то конкретную область в конкретном стеке технологий.
Но это мой личный опыт. Кто читал, оставляйте мнения в комментариях.
👍30
День 1543. #Курсы
Сегодня порекомендую вам ютуб канал Зонара Хорвата (Zoran Horvat) Зоран - консультант, разработчик и архитектор ПО, автор на Pluralsight, Udemy и YouTube. На его канале вы найдёте советы по разработке и архитектуре, паттернах проектирования, чистом коде, новинкам языка C# и т.п.
Видео, которое попалось мне, вышло совсем недавно и называется Are Design Patterns Dead in C#? (Паттерны Проектирования в C# Умерли?) В нём Зоран на примере оригинальной книги «Паттерны Проектирования» банды четырёх рассуждает, полезна ли до сих пор информация о паттернах проектирования и применимы ли они в современной разработке в .NET.
Не буду спойлерить, смотрите до конца)))
Кстати, про паттерны проектирования вы можете почитать на канале по тегу #DesignPatterns.
Сегодня порекомендую вам ютуб канал Зонара Хорвата (Zoran Horvat) Зоран - консультант, разработчик и архитектор ПО, автор на Pluralsight, Udemy и YouTube. На его канале вы найдёте советы по разработке и архитектуре, паттернах проектирования, чистом коде, новинкам языка C# и т.п.
Видео, которое попалось мне, вышло совсем недавно и называется Are Design Patterns Dead in C#? (Паттерны Проектирования в C# Умерли?) В нём Зоран на примере оригинальной книги «Паттерны Проектирования» банды четырёх рассуждает, полезна ли до сих пор информация о паттернах проектирования и применимы ли они в современной разработке в .NET.
Не буду спойлерить, смотрите до конца)))
Кстати, про паттерны проектирования вы можете почитать на канале по тегу #DesignPatterns.
YouTube
Are Design Patterns Dead in C#?
Become a patron and gain access to source code and exclusive live streams: https://www.patreon.com/posts/are-design-dead-81382714
When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper…
When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper…
👍17
День 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
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
👍14
День 1545. #Microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Начало
Вы наконец решили, что пришло время избавиться от старого, неуклюжего монолита. Над ним долго работали, но он стал настолько большим, что больше усилий тратится на его обслуживание, чем на добавление функций. Пришло время попробовать другой подход, например, микросервисы.
Совет: не списывайте со счетов монолит. При некоторой подготовке он может сослужить вам хорошую службу на протяжении всего перехода. Вот 12 советов, как сделать переход на микросервисы максимально плавным.
1. Убедитесь, что вы знаете, во что ввязываетесь
Переходя от монолита к микросервисам, вы меняете не только способ написания кода, но и операционную модель компании. Мало того, что придётся изучить новый, более сложный технологический стек, менеджменту потребуется скорректировать культуру работы и реорганизовать людей в более мелкие кросс-функциональные команды.
Важно как можно лучше изучить компромиссы, связанные с внедрением микросервисов, ещё до начала работы. Вы должны быть абсолютно уверены, что именно микросервисы являются правильным решением для вас. Начните с изучения как можно большего об архитектуре микросервисов и просмотрите несколько примеров проектов, например, здесь или здесь.
2. Составьте план
Старая система должна оставаться работоспособной во время перехода. Шаги миграции можно отслеживать с помощью тикетов. Это не только помогает придерживаться плана, но и даёт владельцам бизнеса прозрачность относительно вашего прогресса. При планировании необходимо:
- Распутать зависимости внутри монолита.
- Определить необходимые микросервисы.
- Разработать модели данных для микросервисов.
- Разработать метод переноса и синхронизации данных между базой данных монолита и базами данных микросервисов.
- Разработать API и спланировать обратную совместимость.
- Измерить базовую производительность монолита.
- Установить цели для доступности и производительности новой системы.
3. Поместите всё в монорепозиторий
Когда вы разбиваете монолит, большая часть кода будет перемещена из него в новые микросервисы. Используйте общий монорепозиторий для размещения кода микросервисов вместе с монолитом. Монорепозиторий поможет отслеживать подобные изменения. Кроме того, наличие всего в одном месте поможет быстрее восстанавливаться после сбоев. Вероятно, ваш монолит уже содержится в одном репозитории, поэтому вопрос сводится к созданию новых папок для микросервисов.
4. Используйте общий конвейер CI
Во время разработки вы будете не только постоянно выпускать новые микросервисы, но и развёртывать необходимые текущие изменения в монолите. Чем быстрее и безболезненнее будет этот процесс, тем быстрее вы сможете прогрессировать. Настройте непрерывную интеграцию и доставку (CI/CD) для автоматического тестирования и развёртывания кода. Если вы используете монорепозиторий, настройте раздельные конвейеры для развёртывания монолита и микросервисов, а также убедитесь в том, что вы получаете полноценные отчёты о тестировании и развёртывании, чтобы быстро обнаруживать и устранять сбои.
5. Убедитесь, что у вас достаточно тестов
Рефакторинг гораздо более эффективен и приносит больше удовлетворения, когда мы уверены, что в коде нет регрессий. Автоматизированные тесты дают уверенность в непрерывном выпуске обновлений. Отличным местом для начала является пирамида тестирования. Она может помочь разработать тесты для микросервисов. Старайтесь запускать тесты на локальном компьютере разработки так же часто, как и в конвейере непрерывной интеграции.
Продолжение следует…
Источник: https://semaphoreci.com/blog/monolith-microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Начало
Вы наконец решили, что пришло время избавиться от старого, неуклюжего монолита. Над ним долго работали, но он стал настолько большим, что больше усилий тратится на его обслуживание, чем на добавление функций. Пришло время попробовать другой подход, например, микросервисы.
Совет: не списывайте со счетов монолит. При некоторой подготовке он может сослужить вам хорошую службу на протяжении всего перехода. Вот 12 советов, как сделать переход на микросервисы максимально плавным.
1. Убедитесь, что вы знаете, во что ввязываетесь
Переходя от монолита к микросервисам, вы меняете не только способ написания кода, но и операционную модель компании. Мало того, что придётся изучить новый, более сложный технологический стек, менеджменту потребуется скорректировать культуру работы и реорганизовать людей в более мелкие кросс-функциональные команды.
Важно как можно лучше изучить компромиссы, связанные с внедрением микросервисов, ещё до начала работы. Вы должны быть абсолютно уверены, что именно микросервисы являются правильным решением для вас. Начните с изучения как можно большего об архитектуре микросервисов и просмотрите несколько примеров проектов, например, здесь или здесь.
2. Составьте план
Старая система должна оставаться работоспособной во время перехода. Шаги миграции можно отслеживать с помощью тикетов. Это не только помогает придерживаться плана, но и даёт владельцам бизнеса прозрачность относительно вашего прогресса. При планировании необходимо:
- Распутать зависимости внутри монолита.
- Определить необходимые микросервисы.
- Разработать модели данных для микросервисов.
- Разработать метод переноса и синхронизации данных между базой данных монолита и базами данных микросервисов.
- Разработать API и спланировать обратную совместимость.
- Измерить базовую производительность монолита.
- Установить цели для доступности и производительности новой системы.
3. Поместите всё в монорепозиторий
Когда вы разбиваете монолит, большая часть кода будет перемещена из него в новые микросервисы. Используйте общий монорепозиторий для размещения кода микросервисов вместе с монолитом. Монорепозиторий поможет отслеживать подобные изменения. Кроме того, наличие всего в одном месте поможет быстрее восстанавливаться после сбоев. Вероятно, ваш монолит уже содержится в одном репозитории, поэтому вопрос сводится к созданию новых папок для микросервисов.
4. Используйте общий конвейер CI
Во время разработки вы будете не только постоянно выпускать новые микросервисы, но и развёртывать необходимые текущие изменения в монолите. Чем быстрее и безболезненнее будет этот процесс, тем быстрее вы сможете прогрессировать. Настройте непрерывную интеграцию и доставку (CI/CD) для автоматического тестирования и развёртывания кода. Если вы используете монорепозиторий, настройте раздельные конвейеры для развёртывания монолита и микросервисов, а также убедитесь в том, что вы получаете полноценные отчёты о тестировании и развёртывании, чтобы быстро обнаруживать и устранять сбои.
5. Убедитесь, что у вас достаточно тестов
Рефакторинг гораздо более эффективен и приносит больше удовлетворения, когда мы уверены, что в коде нет регрессий. Автоматизированные тесты дают уверенность в непрерывном выпуске обновлений. Отличным местом для начала является пирамида тестирования. Она может помочь разработать тесты для микросервисов. Старайтесь запускать тесты на локальном компьютере разработки так же часто, как и в конвейере непрерывной интеграции.
Продолжение следует…
Источник: https://semaphoreci.com/blog/monolith-microservices
👍9
День 1546. #Microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Продолжение
Начало
6. Установите API-шлюз или обратный HTTP-прокси.
По мере развёртывания микросервисов необходимо разделять входящий трафик. Мигрированные функции предоставляются новыми сервисами, а старая функциональность обслуживается монолитом. Существует несколько способов маршрутизации запросов в зависимости от их характера:
- API-шлюз https://t.iss.one/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
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Продолжение
Начало
6. Установите API-шлюз или обратный HTTP-прокси.
По мере развёртывания микросервисов необходимо разделять входящий трафик. Мигрированные функции предоставляются новыми сервисами, а старая функциональность обслуживается монолитом. Существует несколько способов маршрутизации запросов в зависимости от их характера:
- API-шлюз https://t.iss.one/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
👍9
День 1547. #Microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Окончание
Начало
Продолжение
10. Сделайте монолит модульным
Если ваш монолит представляет собой запутанный клубок кода, вы вполне можете получить запутанный клубок распределённого кода после завершения миграции. Подобно уборке дома перед капитальным ремонтом, модульность монолита является необходимым подготовительным этапом.
Модульный монолит — это паттерн разработки ПО, представляющий собой вертикально расположенные модули, независимые и взаимозаменяемые. Противоположностью является классический N-уровневый монолит, в коде которого слишком много зависимостей (иногда циклических), что затрудняет внесение изменений.
Модульный монолит — ступенька к микросервисам. Модули могут обмениваться данными только через общедоступные API и по умолчанию всё приватно. В результате код менее переплетён, отношения легко идентифицировать, а зависимости чётко очерчены.
Два паттерна могут помочь вам провести рефакторинг монолита:
1) Душитель
Проводится рефакторинг монолита от края к центру, постепенно переписывая отдельные функции, пока монолит не будет полностью переделан.
Подробнее о паттерне «Душитель».
2) Слой защиты от повреждений
Вы обнаружите, что в некоторых случаях изменения в одном модуле распространяются на другие по мере рефакторинга монолита. Чтобы бороться с этим, вы можете создать слой перевода между быстро меняющимися модулями. Этот слой защиты предотвращает влияние изменений в одном модуле на остальные.
Подробнее о паттерне «Слой защиты от повреждений».
11. Разделите данные
Сила микросервисов в возможности развёртывать любой микросервис в любое время практически без координации с другими микросервисами. Вот почему следует любой ценой избегать связывания данных, поскольку оно создаёт зависимости между сервисами. Каждый микросервис должен иметь отдельную и независимую базу данных.
Может быть шокирующим осознание того, что вам нужно денормализировать общую базу данных монолита на (часто избыточные) меньшие базы данных. Но локальность данных — это то, что в итоге позволит микросервисам работать автономно.
После разделения нужно будет установить механизмы для синхронизации старых и новых данных во время перехода. Вы можете, например, настроить сервис зеркалирования данных или изменить код, чтобы транзакции записывались в оба набора баз данных.
12. Улучшите наблюдение
Новая система должна быть быстрее, производительнее и масштабируемее, чем старая. Иначе зачем возиться с микросервисами? Нужен базовый уровень для сравнения старого с новым. Перед началом миграции убедитесь, что у вас есть хорошие метрики и журналы. Может быть хорошей идеей установить какую-нибудь централизованную службу ведения журналов и мониторинга, так как это ключевой компонент для наблюдения за любым микросервисным приложением.
Итого
Путь к микросервисам никогда не бывает лёгким. Но я надеюсь, что с помощью этих советов вы сможете сэкономить время и нервы.
Не забывайте выполнять итерации небольшими шагами, использовать CI/CD, чтобы гарантировать, что монолит тестируется на регрессии, и хранить всё в одном репозитории, чтобы вы всегда могли отмотать назад, если что-то пойдет не так.
Источник: https://semaphoreci.com/blog/monolith-microservices
12 Способов Улучшить Монолит Перед Переходом на Микросервисы. Окончание
Начало
Продолжение
10. Сделайте монолит модульным
Если ваш монолит представляет собой запутанный клубок кода, вы вполне можете получить запутанный клубок распределённого кода после завершения миграции. Подобно уборке дома перед капитальным ремонтом, модульность монолита является необходимым подготовительным этапом.
Модульный монолит — это паттерн разработки ПО, представляющий собой вертикально расположенные модули, независимые и взаимозаменяемые. Противоположностью является классический N-уровневый монолит, в коде которого слишком много зависимостей (иногда циклических), что затрудняет внесение изменений.
Модульный монолит — ступенька к микросервисам. Модули могут обмениваться данными только через общедоступные API и по умолчанию всё приватно. В результате код менее переплетён, отношения легко идентифицировать, а зависимости чётко очерчены.
Два паттерна могут помочь вам провести рефакторинг монолита:
1) Душитель
Проводится рефакторинг монолита от края к центру, постепенно переписывая отдельные функции, пока монолит не будет полностью переделан.
Подробнее о паттерне «Душитель».
2) Слой защиты от повреждений
Вы обнаружите, что в некоторых случаях изменения в одном модуле распространяются на другие по мере рефакторинга монолита. Чтобы бороться с этим, вы можете создать слой перевода между быстро меняющимися модулями. Этот слой защиты предотвращает влияние изменений в одном модуле на остальные.
Подробнее о паттерне «Слой защиты от повреждений».
11. Разделите данные
Сила микросервисов в возможности развёртывать любой микросервис в любое время практически без координации с другими микросервисами. Вот почему следует любой ценой избегать связывания данных, поскольку оно создаёт зависимости между сервисами. Каждый микросервис должен иметь отдельную и независимую базу данных.
Может быть шокирующим осознание того, что вам нужно денормализировать общую базу данных монолита на (часто избыточные) меньшие базы данных. Но локальность данных — это то, что в итоге позволит микросервисам работать автономно.
После разделения нужно будет установить механизмы для синхронизации старых и новых данных во время перехода. Вы можете, например, настроить сервис зеркалирования данных или изменить код, чтобы транзакции записывались в оба набора баз данных.
12. Улучшите наблюдение
Новая система должна быть быстрее, производительнее и масштабируемее, чем старая. Иначе зачем возиться с микросервисами? Нужен базовый уровень для сравнения старого с новым. Перед началом миграции убедитесь, что у вас есть хорошие метрики и журналы. Может быть хорошей идеей установить какую-нибудь централизованную службу ведения журналов и мониторинга, так как это ключевой компонент для наблюдения за любым микросервисным приложением.
Итого
Путь к микросервисам никогда не бывает лёгким. Но я надеюсь, что с помощью этих советов вы сможете сэкономить время и нервы.
Не забывайте выполнять итерации небольшими шагами, использовать CI/CD, чтобы гарантировать, что монолит тестируется на регрессии, и хранить всё в одном репозитории, чтобы вы всегда могли отмотать назад, если что-то пойдет не так.
Источник: https://semaphoreci.com/blog/monolith-microservices
👍9👎1
День 1548. #ЗаметкиНаПолях
Управление Контейнерами в .NET 7 SDK
В .NET SDK 7.0.200 представлена новая функция, которая позволяет создавать и публиковать образы контейнеров непосредственно из файла проекта.
Для этого в файл проекта надо добавить:
- Создавать образ Docker для приложения, не создавая Dockerfile.
- Публиковать образ в реестре контейнеров.
- Указывать переменные, такие как базовый образ, тег образа и имя реестра в файле проекта.
Важно отметить, что устанавливать докер на компьютере не нужно. Пакет SDK для .NET может создать образ, а затем отправить его в удалённый реестр.
.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. Тем не менее, вы можете переопределить базовый образ по умолчанию, порт, имя контейнера, тэг и т.п.:
Источник: https://laurentkempe.com/2023/03/13/dotnet-7-sdk-built-in-container-improvements/
Управление Контейнерами в .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/
👍17👎1
День 1549. #ЗаметкиНаПолях
Используем Группы Конечных Точек для Версионирования Минимальных API
В ASP.NET Core 7 значительно улучшены минимальные API, в частности добавлена функция групп конечных точек. Это способ объявить некоторую общую информацию о маршрутизации для нескольких конечных точек, а также добавить общие ограничения, такие как авторизация, правила CORS и т. д.
Группы конечных точек позволяют управлять версиями API. Просто добавляем базовый маршрут в метод MapGroup, например:
ASP.NET Core 7 предоставляет класс RouteGroupBuilder для создания правил и группировки конечных точек. Создадим две группы конечных точек:
Источник: https://anthonygiretti.com/2023/03/16/asp-net-core7-use-endpoint-groups-to-manage-minimal-apis-versioning/
Используем Группы Конечных Точек для Версионирования Минимальных API
В ASP.NET Core 7 значительно улучшены минимальные API, в частности добавлена функция групп конечных точек. Это способ объявить некоторую общую информацию о маршрутизации для нескольких конечных точек, а также добавить общие ограничения, такие как авторизация, правила CORS и т. д.
Группы конечных точек позволяют управлять версиями API. Просто добавляем базовый маршрут в метод MapGroup, например:
MapGroup("/v1")
или MapGroup("/v2")
. ASP.NET Core 7 предоставляет класс RouteGroupBuilder для создания правил и группировки конечных точек. Создадим две группы конечных точек:
public static class MyGroupsДля удобства мы сгруппировали конечные точки в отдельных методах расширения. Теперь добавим ограничения и базовый маршрут к каждой группе в основном файле Program.cs. Кроме того, для демонстрации различий добавим Swagger, установив NuGet пакет Microsoft.AspNetCore.OpenApi и добавив необходимые методы расширения:
{
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;
}
}
var builder = WebApplication.CreateBuilder(args);Как видите, к первой группе применена одна политика CORS, а ко второй группе — другая, а также правила авторизации и ограничения скорости https://t.iss.one/NetDeveloperDiary/1487. Также для удобства отображения в SwaggerUI каждой группе добавлены теги с помощью метода
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();
WithTags(…)
. Результат на картинке ниже.Источник: https://anthonygiretti.com/2023/03/16/asp-net-core7-use-endpoint-groups-to-manage-minimal-apis-versioning/
👍14👎2
День 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/
Создание Асинхронной Рабочей Среды
«Вопросик к тебе…» — есть ли что-то более раздражающее, когда ты с головой погружён в отладку? А чтобы вернуться к сложной проблеме после того, как вас отвлекли, может потребоваться уйма времени.
Поэтому, всё более популярной становится форма асинхронной удалённой работы. Вся или большая часть работы выполняется в удобное для сотрудников время. Сотрудники используют асинхронные инструменты для общения, а совещаний в реальном времени очень мало.
Вероятно, самая распространенная причина – сотрудники в разных часовых поясах. Это даёт компаниям доступ к глобальному рынку кадров. Кроме того, сотрудники могут не только работать, когда им удобно, но и так, как они работают лучше всего. Люди счастливее, когда у них есть гибкость, а когда они счастливее, они более продуктивны. Менее очевидным преимуществом является запись почти каждого разговора.
Распространённое возражение против асинхронной работы заключается в том, что усложняется совместная работа, но практика показывает, что асинхронное сотрудничество намного лучше. У каждого есть время подумать и сформулировать мысль. Все сообщения регистрируются, поэтому легко найти, кто что сказал и избежать потери важных знаний.
Для менеджера наличие асинхронной команды означает, что нельзя полагаться на такие показатели, как количество отработанных часов. Нужно использовать метрики на основе результатов, которые побуждают членов команды работать более эффективно. Также невозможно сразу получить ответы на все свои вопросы. Вот ещё несколько достойных внимания вещей:
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/
👍20👎1
День 1551. #ЗаметкиНаПолях
Сокращаем Количество Обращений к Коллекциям
Многие проекты C# содержат множество мест, где разработчики добавляют элементы в коллекции, такие как HashSet и Dictionary. Довольно часто добавляют проверку, чтобы убедиться, находится ли элемент в коллекции. Однако это может быть довольно расточительно, так как методы Add() и TryAdd() в этих коллекциях уже выполняют эту проверку за вас. Посмотрим на некоторые примеры.
1. Работа с HashSet<T>
При написании кода с использованием HashSet<T> есть большая вероятность, что ваш код использует следующий шаблон: проверяет, существует ли элемент в наборе, и, если нет, добавляет его.
2. Работа с Dictionary<TKey, TValue>
При работе с экземпляром Dictionary аналогичная проверка обычно делается, используя ContainsKey() и Add():
Другим распространённым шаблоном является добавление записи только если ключ отсутствует в словаре:
JetBrains недавно объявили в своём блоге, что новые наборы проверок для анализатора кода в ReSharper и Rider содержат описанные выше проверки и соответствующие быстрые исправления для оптимизации вашей работы с различными типами коллекций за счёт сокращения количества операций поиска в коллекциях. Особенно при работе с большими коллекциями или частом добавлении записей оптимизация шаблона использования повысит производительность вашего кода.
Источник: https://blog.jetbrains.com/dotnet/2023/04/18/reduce-lookups-in-hashset-dictionary-and-other-collections-with-resharper/
Сокращаем Количество Обращений к Коллекциям
Многие проекты C# содержат множество мест, где разработчики добавляют элементы в коллекции, такие как HashSet и Dictionary. Довольно часто добавляют проверку, чтобы убедиться, находится ли элемент в коллекции. Однако это может быть довольно расточительно, так как методы Add() и TryAdd() в этих коллекциях уже выполняют эту проверку за вас. Посмотрим на некоторые примеры.
1. Работа с HashSet<T>
При написании кода с использованием HashSet<T> есть большая вероятность, что ваш код использует следующий шаблон: проверяет, существует ли элемент в наборе, и, если нет, добавляет его.
var person = new Person("Jon", "Smith");Вам не нужно этого проверять. Если вы посмотрите на исходный код HashSet<T>, вы увидите, что и Constains(), и Add() проверяют, содержит ли набор элемент. Другими словами, вы выполняете одну и ту же операцию дважды.
if (!people.Contains(person))
people.Add(person);
2. Работа с Dictionary<TKey, TValue>
При работе с экземпляром Dictionary аналогичная проверка обычно делается, используя ContainsKey() и Add():
if (employees.ContainsKey(id))При использовании индексатора словаря для установки значения, под капотом в Dictionary используется метод TryInsert(), поэтому проверка ContainsKey() лишняя.
employees[id] = employee;
else
employees.Add(id, employee);
Другим распространённым шаблоном является добавление записи только если ключ отсутствует в словаре:
if (!employees.ContainsKey(id))Для таких случаев Dictionary и Dictionary<TKey, TValue> имеют метод TryAdd(), который делает то же самое:
employees.Add(id, employee);
if (employees.TryAdd(id, employee))Для получения значений словаря, только если ключ существует, есть метод TryGetValue(key, out value):
{
… // элемент успешно добавлен
}
else
{
… // элемент с таким ключом уже существует
}
// До:Итого
if (employees.ContainsKey(id))
return employees[id];
// После:
if (employees.TryGetValue(id, out var employee))
return employee;
JetBrains недавно объявили в своём блоге, что новые наборы проверок для анализатора кода в ReSharper и Rider содержат описанные выше проверки и соответствующие быстрые исправления для оптимизации вашей работы с различными типами коллекций за счёт сокращения количества операций поиска в коллекциях. Особенно при работе с большими коллекциями или частом добавлении записей оптимизация шаблона использования повысит производительность вашего кода.
Источник: https://blog.jetbrains.com/dotnet/2023/04/18/reduce-lookups-in-hashset-dictionary-and-other-collections-with-resharper/
👍37
День 1552. #ЗаметкиНаПолях
Проверки Работоспособности в ASP.NET Core. Начало
Мы все хотим создавать надёжные приложения, которые можно бесконечно масштабировать, чтобы обрабатывать любое количество запросов. Крайне важно, чтобы у вас была система для получения быстрой обратной связи о работоспособности приложения. В этом помогут проверки работоспособности (Health Checks).
Они позволяют отслеживать работоспособность различных компонентов, в том числе: баз данных, API, кэша, внешних сервисов. ASP.NET Core имеет встроенную поддержку проверки работоспособности.
Вот базовая конфигурация, которая регистрирует сервис проверки работоспособности:
- Healthy
- Degraded
- Unhealthy
Например, если приложение работает медленнее обычного, можно возвратить HealthStatus.Degraded.
Специальные проверки
Специальные проверки можно создавать, реализуя интерфейс IHealthCheck. Например, для базы данных SQL, можно использовать запрос, который быстро выполняется, вроде
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/health-checks-in-asp-net-core
Проверки Работоспособности в ASP.NET Core. Начало
Мы все хотим создавать надёжные приложения, которые можно бесконечно масштабировать, чтобы обрабатывать любое количество запросов. Крайне важно, чтобы у вас была система для получения быстрой обратной связи о работоспособности приложения. В этом помогут проверки работоспособности (Health Checks).
Они позволяют отслеживать работоспособность различных компонентов, в том числе: баз данных, API, кэша, внешних сервисов. ASP.NET Core имеет встроенную поддержку проверки работоспособности.
Вот базовая конфигурация, которая регистрирует сервис проверки работоспособности:
var builder = WebApplication.CreateBuilder(args);Проверка возвращает значение HealthStatus, которое может быть 3х видов:
builder.Services.AddHealthChecks();
var app = builder.Build();
app.MapHealthChecks("/health");
app.Run();
- Healthy
- Degraded
- Unhealthy
Например, если приложение работает медленнее обычного, можно возвратить HealthStatus.Degraded.
Специальные проверки
Специальные проверки можно создавать, реализуя интерфейс IHealthCheck. Например, для базы данных SQL, можно использовать запрос, который быстро выполняется, вроде
SELECT 1
:public class SqlHealthCheck : IHealthCheckПроверку необходимо зарегистрировать, для этого добавим метод к AddHealthChecks:
{
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);
}
}
}
builder.Services.AddHealthChecks()Мы задаём имя проверки и устанавливаем, какой статус использовать в качестве результата сбоя.
.AddCheck<SqlHealthCheck>(
"custom-sql",
HealthStatus.Unhealthy);
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/health-checks-in-asp-net-core
👍26👎1
День 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:
По умолчанию конечная точка, возвращающая статус проверки работоспособности, выдаёт строковое значение, представляющее HealthStatus. Это неудобно, если у вас настроено несколько проверок, поскольку хорошо было бы просматривать состояние отдельно для каждого сервиса. Что ещё хуже, если один из сервисов выходит из строя, проверка просто вернёт Unhealthy, и вы не узнаете, что вызывает проблему.
Эту проблему можно решить, предоставив ResponsWriter, который уже существует в пакете AspNetCore.HealthChecks.UI.Client. После установки пакета надо изменить вызов MapHealthChecks, чтобы использовать ResponseWriter:
Итого
Мониторинг приложений важен для отслеживания доступности, использования ресурсов и изменений в производительности. Отслеживать работоспособность ваших приложений ASP.NET Core легко, предоставляя проверки работоспособности для ваших сервисов. Вы можете внедрить пользовательские проверки работоспособности, но сначала проверьте, существуют ли готовые решения.
Источник: https://www.milanjovanovic.tech/blog/health-checks-in-asp-net-core
Проверки Работоспособности в 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
👍26
День 1554. #ЗаметкиНаПолях
Как Исключить Свойства при Сериализации в JSON. Начало
Распространённая проблема при сериализации объектов в JSON в том, что результат содержит множество нежелательных свойств. По умолчанию сериализуются все свойства. Однако очень часто нам не нужна вся информация. Рассмотрим, как убрать ненужные свойства при сериализации объекта на примере двух популярных библиотек сериализации System.Text.Json и Newtonsoft.Json.
1. Игнорируем отдельные свойства
Для отдельных свойств можно использовать атрибут
Мы также можем применять условия при индивидуальном игнорировании свойства. Для атрибута
- Always — свойство всегда игнорируется (по умолчанию),
- Never — свойство всегда сериализуется и десериализуется, независимо от глобальных параметров DefaultIgnoreCondition, IgnoreReadOnlyProperties и IgnoreReadOnlyFields,
- WhenWritingDefault — свойство не учитывается при сериализации, если содержит значение по умолчанию для типа (default),
- WhenWritingNull — свойство не учитывается при сериализации, если оно равно null.
В Newtonsoft.Json сериализацию свойства можно настроить с помощью JsonPropertyAttribute.
3. Атрибуты DataContract и DataMember
В некоторых сценариях у нас есть классы со многими свойствами, а мы хотим сериализовать только некоторые из них. При использовании Newtonsoft.Json мы можем добавить атрибут класса
Источник: https://code-maze.com/csharp-exclude-properties-from-json-serialization/
Как Исключить Свойства при Сериализации в 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);
{2. Условное игнорирование отдельных свойств
"Name": "John",
"LastName": "Smith"
}
Мы также можем применять условия при индивидуальном игнорировании свойства. Для атрибута
[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/
👍25
День 1555. #ЗаметкиНаПолях
Как Исключить Свойства при Сериализации в JSON. Окончание
Начало
4. Игнорировать все свойства с null или default
Можно не учитывать при сериализации свойства со значениями null или значениями по умолчанию для типа (default).
5. Используем IContractResolver
Newtonsoft.Json предоставляет этот интерфейс для тонкой настройки сериализации. Проще всего создать класс, унаследованный от DefaultContractResolver, в котором либо:
- переопределить метод CreateProperty, который позволяет обратиться к метаданным свойства и задать ему булево значение ShouldSerialize, определяющее, должно ли свойство попасть в вывод при сериализации,
- переопределить метод CreateProperties, который должен вернуть список свойств, попадающих в вывод при сериализации.
После создания класса, реализующего этот интерфейс, его можно подключить в настройках сериализации:
Источник: https://code-maze.com/csharp-exclude-properties-from-json-serialization/
Как Исключить Свойства при Сериализации в JSON. Окончание
Начало
4. Игнорировать все свойства с null или default
Можно не учитывать при сериализации свойства со значениями null или значениями по умолчанию для типа (default).
public class BookВ System.Text.Json для этого нужно задать опцию DefaultIgnoreCondition со значением WhenWritingNull или WhenWritingDefault соответственно:
{
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"
};
var json1 = JsonSerializer.Serialize(book,В Newtonsoft.Json нужно задать параметры NullValueHandling или DefaultValueHandling соответственно:
new JsonSerializerOptions
{
DefaultIgnoreCondition
= JsonIgnoreCondition.WhenWritingNull
// или JsonIgnoreCondition.WhenWritingDefault
});
var json2 = JsonConvert.SerializeObject(book,Вывод:
new JsonSerializerSettings
{
NullValueHandling = NullValueHandling.Ignore
// или
// DefaultValueHandling =
// DefaultValueHandling.Ignore
});
{Если мы зададим игнорирование значений по умолчанию, то свойства "Sells" не будет в выводе.
"Id": 1,
"Title": "Dracula",
"Sells": 0
}
5. Используем IContractResolver
Newtonsoft.Json предоставляет этот интерфейс для тонкой настройки сериализации. Проще всего создать класс, унаследованный от DefaultContractResolver, в котором либо:
- переопределить метод CreateProperty, который позволяет обратиться к метаданным свойства и задать ему булево значение ShouldSerialize, определяющее, должно ли свойство попасть в вывод при сериализации,
- переопределить метод CreateProperties, который должен вернуть список свойств, попадающих в вывод при сериализации.
После создания класса, реализующего этот интерфейс, его можно подключить в настройках сериализации:
var json = JsonConvert.SerializeObject(book,Пример создания класса ContractResolver можно найти здесь.
new JsonSerializerSettings
{
ContractResolver =
new MyPropertiesResolver()
});
Источник: https://code-maze.com/csharp-exclude-properties-from-json-serialization/
👍19
День 1556. #ЧтоНовенького
Новые Атрибуты Валидации в .NET 8
В .NET 8 превью 2, представлены несколько новых атрибутов, которые наверняка вызовут интерес у разработчиков.
1. RequiredAttribute.DisallowAllDefaultValues
Атрибут Required используется для пометки свойства или параметра как обязательного, что означает, что он не может быть null. Теперь добавлено свойство DisallowAllDefaultValues, которое позволяет проверять, что структура не равна своему значению по умолчанию. Допустим, у нас есть свойство типа Guid. По умолчанию Guid инициализируется как Guid.Empty. Чтобы гарантировать, что значение этого свойства всегда установлено, мы можем использовать атрибут Required со свойством DisallowAllDefaultValues, установленным в true. Если значение свойства не задано явно и остаётся равным Guid.Empty, валидация завершится ошибкой:
2. Явные границы Range
Теперь можно явно указывать границы при проверке диапазона с помощью RangeAttribute. Можно определять диапазоны с границами, которые исключаются из проверки:
3. Атрибут Length
Этот атрибут теперь можно использовать для установки как нижних, так и верхних границ для строк или коллекций, что обеспечивает большую гибкость при проверке:
4. Атрибуты AllowedValues и DeniedValues
Следующие атрибуты можно использовать для проверки свойства по списку разрешённых или запрещённых значений. AllowedValues указывает список допустимых значений. DeniedValues - список запрещённых значений.
Источник: https://dev.to/bytehide/net-8-preview-2-unveiled-5-new-features-you-need-to-know-2cof
Новые Атрибуты Валидации в .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,Здесь атрибут указывает, что допустимым диапазоном для Sample типа double является любое значение больше 0 и меньше 1, однако граничные значения 0 и 1 исключаются из допустимого диапазона.
MinimumIsExclusive = true,
MaximumIsExclusive = true)]
public double Sample { get; set; }
3. Атрибут Length
Этот атрибут теперь можно использовать для установки как нижних, так и верхних границ для строк или коллекций, что обеспечивает большую гибкость при проверке:
[Length(10, 20)]Атрибут Length в коде выше гарантирует, что коллекция Values должна содержать не менее 10 и не более 20 элементов.
public ICollection<int> Values { get; set; }
4. Атрибуты AllowedValues и DeniedValues
Следующие атрибуты можно использовать для проверки свойства по списку разрешённых или запрещённых значений. AllowedValues указывает список допустимых значений. DeniedValues - список запрещённых значений.
[AllowedValues("chocolate", "vanilla")]В этом примере для свойства IceCreamFlavor можно задать только значение «шоколад» или «ваниль», а свойству CakeFlavor нельзя задать значение «свекла» или «баклажан». Эти атрибуты могут быть полезны в сценариях, где вы хотите ограничить возможные значения свойства, например, в раскрывающемся списке или наборе флажков.
public string IceCreamFlavor { get; set; }
[DeniedValues("beetroot", "eggplant")]
public string CakeFlavor { get; set; }
Источник: https://dev.to/bytehide/net-8-preview-2-unveiled-5-new-features-you-need-to-know-2cof
👍29