Runtime: Будущее JSON в .NET Core 3.0

Отлично. Я за более быстрый и менее затратный синтаксический анализ json.

Будет ли обсуждаться функция json.net, которую будет поддерживать новый json apis? Если есть, я думаю, что две основные функции, которые приходят на ум, - это переименование / регистр свойств и игнорирование нулевых свойств.

Будет ли обсуждаться функция json.net, которую будет поддерживать новый json apis?

да. Мы заранее подумали, что перейдем на CoreFx. Это будет функция, которая разработана и построена как обычно. Кроме того, я обратился к авторам многих популярных библиотек JSON и предложил им ознакомиться с ранними версиями этого объявления. Я надеюсь, что мы сможем работать вместе, чтобы создать надежный компонент JSON для платформы, сохраняя при этом экосистему на ее вершине (например, ASP.NET Core), чтобы позволить другим. В конце концов, разные потребители будут иметь разные цели, и возможность подключать другую библиотеку означает, что вы можете получить максимальную гибкость в выборе компонента, который имеет лучшую стоимость / выгоду для вашего приложения.

Привет @terrajobst. Появится ли новый JSON как поверхность API netstandard или пока просто интегрирован в Core?

Привет @terrajobst. Появится ли новый JSON как поверхность API netstandard или пока просто интегрирован в Core?

Да, вопрос только в том, какой поезд с выпуском он сможет поймать. 2.1 может быть слишком рано.

Таким образом, биты синтаксического анализа JSON, встроенные в структуру, планируется, чтобы они были доступны, когда v3.0 перейдет в RTM или будет завершена только интеграция Apis в ASP.NET Core (только с одной реализацией - JSON.NET), которая будет заменяться на Поздняя дата?

План на 3.0 следующий:

1. Встроенные высокопроизводительные API-интерфейсы JSON. Читатель / писатель низкого уровня, читатель / писатель на основе Stream и сериализатор.
2. ASP.NET Core подключается к компоненту JSON.

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

Спасибо - это помогает прояснить ситуацию. 👍

И еще несколько вопросов!

Если используется пакет интеграции, будет ли он использоваться во всем конвейере ASP.NET Core или только в некоторых местах?
Я предполагаю, что Kestrel всегда будет использовать внутренних читателей / писателей.

Будет ли эргономика Api:

• Предоставляйте интеграцию только в том случае, если вы хотите расширить набор встроенных функций.
• Всегда предоставляйте интеграционный пакет, но один будет встроенным, интегрируя низкоуровневые средства чтения / записи в функциональность более высокого уровня.

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

Спасибо.

Это отличные новости! Быстрый вопрос: от каких пакетов будет зависеть эта библиотека?

Зачем изобретать колесо, которое проверено производственными заказчиками? Если есть проблема с Json.Net, просто отправьте PR, так как это открытый исходный код.

Я полагаю, проблема с Json.NET в том, что он не принадлежит Microsoft, поэтому его нужно заменить. О, но в System.Runtime.Serialization уже есть тот, который называется DataContractJsonSerializer. Можете ли вы использовать это, или это просто так весело писать новые API, DIY, что этого невозможно избежать?

Причина, по которой я не очень доволен этим, заключается в том, что Json.Net уже поддерживает крайние случаи, такие как, например, F # Discriminated Unions. Не особенно хорошо, но на уровне, с которым разработчики могут смириться. Вместо этого любой новый API обычно забывает обо всем, кроме варианта использования веб-сайта ASP.NET.

@markrendle В

@Thorium Вы действительно читали ОП? Это объясняет, почему не JSON.NET, и что JSON.NET будет по-прежнему официально поддерживаться с помощью пакета надстройки.

@JamesNK 😄

@Thorium Json.NET никуда не денется. Вы ничего не теряете. Это еще один вариант для простых и высокопроизводительных сценариев.

@Thorium Json.NET никуда не денется. Вы ничего не теряете. Это еще один вариант для простых и высокопроизводительных сценариев.

Как будет сгенерирован Json для обеспечения обратной совместимости?

Например, я использую SignalR, который использует Json.NET в фоновом режиме. Теперь, будут ли мои размеченные F # союзы сериализоваться в аналогичные структуры, чтобы я не боролся с проблемами с новой службой Azure Signalr (объединительной платой), генерирующей исключения времени выполнения из-за сериализации структур иначе, чем текущая библиотека SignalR моего сервера?

Я надеюсь, что другие быстро воспользуются новыми API. Глядя на тебя, @AzureCosmosDB ;-)

Планируете ли вы включить такой класс, как JObject, и поддержку динамического изменения, или это выходит за рамки данной функции?

Я рекомендую заглянуть в одну из этих библиотек:

• https://github.com/kevin-montrose/Jil или
• https://github.com/neuecc/Utf8Json

это может быть действительно хорошим способом получить вдохновение.

Будет ли DataContractJsonSerializer использоваться для внутреннего пользования этим новым устройством чтения / записи?

Я обратился к авторам многих популярных библиотек JSON и предложил им ознакомиться с ранними версиями этого объявления. Я надеюсь, что мы сможем работать вместе, чтобы создать надежный компонент JSON для платформы, сохраняя при этом экосистему на ее вершине (например, ASP.NET Core), чтобы позволить другим.

Есть ли причина , почему второй наиболее популярной библиотеки JSON после Json.NET - ServiceStack.Text , который уже был переработан , API был исключен? Сериализаторы ServiceStack.Text - это то, что используется для поддержки ServiceStack, который является одной из самых популярных «альтернативных веб-платформ, совместимых с .NET Core», которая поддерживает работу на других платформах в .NET . Мне любопытно, о какой «экосистеме» вы имеете в виду и надеетесь «работать вместе» здесь? Мне, очевидно, было бы интересно узнать, насколько совместимы эти «подключаемые» API-интерфейсы, и станет ли это еще одной областью, в которой внедрение и интеграция новых библиотек MS убивает экосистему, которую они заменяют.

Возможно, стоит просмотреть лицензированный MIT высокопроизводительный https://github.com/neuecc/Utf8Json

Это определенно то, что нам нужно ... мое предложение для имени основного класса, просто используйте " Json ".

@terrajobst Мне было интересно, когда это случится ...

Мне всегда было интересно, почему JSON.Net был добавлен как прямая зависимость, а не как абстракция (даже учитывая, что это фактический пакет JSON для экосистемы .Net).

Однако я думаю, что добавление абстракции только для JSON - это как-то неплохо. Я думаю, что абстракция _serializer_, такая как у нас в Орлеанском IExternalSerializer в форме Microsoft.Extensions.Serialization или что-то еще, была бы более эффективной ...

Есть ли какая-то конкретная причина, по которой make поддерживает только JSON? Я вижу и другие случаи, когда люди могут подключать другие типы сериализаторов ...

@galvesribeiro Что-то вроде IOutputFormatter / IInputFormatter ?

@ yaakov-h не знал об этом ... Были ли они?

@galvesribeiro AspNetCore: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.formatters.iinputformatter?view=aspnetcore-2.1

Окей ... теперь имеет смысл. Итак, где же здесь задействованы эти _новые_ абстракции только для JSON?

Решение начать это начинание также свидетельствует о неэффективности System.String (UTF-16 String).
Я думаю, что новые хуки JSON, которые абстрагируют всю обработку json между asp.net и json-библиотекой, будут выглядеть значительно лучше, если вы сначала решите задачу по созданию строки UTF-8 BaseType.
-> Возможно создать System.Utf8String

Да ... Я помню, как @migueldeicaza недавно сказал, что однажды он заставит .Net использовать utf8 strings 😄

@ jges42 @galvesribeiro Предложение добавить Utf8String - https://github.com/dotnet/corefx/issues/30503. Похоже, это также планируется для .Net Core 3.0.

Будут ли эти новые JSON API иметь выделенные пути кода для Utf8String и char / string , или оптимизация предполагает изменение статус-кво, чтобы все, кроме UTF-8 нужно будет вместо этого перекодировать на него? (Это не обязательно связано с огромными затратами, поскольку почти ничто не является родным UCS-2 UTF-16 string и все еще должно быть адаптировано / учтено, я просто пытаюсь получить представление о Поверхность API. Сделать так, чтобы Kestrel была более эффективной, разумно; я просто надеюсь, что дизайн учитывает больше клиентов, чем Kestrel.)

@galvesribeiro
На самом деле я думаю, что вы подняли хороший вопрос. Я думаю, что создание эффективной платформы сериализации и эффективного Json Decoder / Encoder - это два вида проблем. Я знаю, что есть несколько способов пометить структуру как сериализуемую, но я никогда не видел, чтобы она использовалась для какой-либо сериализации Json.

Проект Serde от Rust на самом деле имеет хорошую концепцию, разделив проблему на 2 задачи:

1. Сериализовать / десериализовать (черты, похожие на интерфейсы в C #), что означает, что любой тип, наследуемый от этого интерфейса, может быть сериализован / десериализован.
2. Сериализатор / десериализатор - это реализация для конкретного формата.

Тип может реализовать сериализацию / десериализацию вручную или с помощью макроса (который можно рассматривать как некоторую форму плагина компилятора), который генерирует код, необходимый для реализации этих черт. Если тип содержит дочерний тип, который не реализует эти черты, он даже предупредит во время компиляции. В целом это хорошая концепция, потому что это означает, что вы можете просто написать некоторые объекты данных и (де) сериализовать их для любого поддерживаемого формата. Так писать формат намного проще.

Я не думаю, что все способы Serde будут работать для C #, потому что он на самом деле не предлагает никаких атрибутов, зависящих от типа, которые могут быть важны для некоторых структур данных. Так что для этого нужно проделать некоторую работу. Также рассмотрение AoT Compilation будет очень важно для некоторых проектов (WASM). Он также должен хорошо работать с ним.

Вот ссылка на документы Serde, чтобы прояснить это (щелкните четыре нижних черты, чтобы увидеть концепцию):
https://docs.serde.rs

@mythz Лицензия

@ poizan42 ServiceStack.Text имеет двойную лицензию: как OSS / коммерческие лицензии, так и бесплатные для использования как в коммерческих проектах OSS, так и в коммерческих проектах с закрытым исходным кодом. Но лицензии на исходный код не имеют значения, поскольку MS разрабатывает свою собственную реализацию.

Утверждение заключалось в том, что MS сотрудничала с «экосистемой» для разработки «подключаемых» API-интерфейсов сериализатора JSON - если ServiceStack, который активно разрабатывался почти десять лет, является одним из немногих независимых программных пакетов .NET, которым удалось его поддерживать. собственное независимое здоровое сообщество за пределами MS в течение его времени, которое поддерживает второй по популярности сериализатор JSON после JSON.NET и, как представляется, второй по популярности активно разрабатываемый веб-фреймворк (за пределами MS), который работает на большем количестве платформ, чем любой MS веб-фреймворк не считается частью «экосистемы», на которую в первую очередь влияют эти изменения, мне любопытно, о какой «экосистеме» они относятся и почему мы исключаемся и сколько других исключаются, потому что они не считается частью «экосистемы».

Я не понимаю всей этой обиды. Asp.net заставил вас использовать определенную версию json.net. Они меняют его, поэтому вы можете выбрать, какой парсер JSON вам нужен (или смешать его), и есть один OOB по умолчанию. ServiceStack должен быть доволен этим изменением, отслеживать и предоставлять отзывы об этом развитии, а не просто ныть о том, что его упустили из виду, что редко бывает эффективным способом воспитания хорошего духа сообщества. Я лично знаю многих членов команды .net и уверен, что они не имели никакого злого умысла. Все они являются большими сторонниками OSS и общественной работы.
Лично для меня любая лицензия, производная от GPL, была бы большим автоматическим отказом. Apache или MIT для меня и моих клиентов, или мы пойдем дальше. Никаких загадочных двойных лицензий.

Asp.net заставил вас использовать определенную версию json.net

Неа. Как так?

Я не понимаю всей этой обиды.

Прикомандированный!

Я лично рад, что мы наконец-то сможем использовать выбранный нами сериализатор без необходимости загружать JSON.Net только для того, чтобы не использовать его, но все же необходимо отправить его, потому что ASP.Net имеет жесткую ссылку на библиотеку.

(Бесстыдный плагин: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

Я не понимаю всей этой обиды.

Потому что вы либо не прочитали, либо не поняли мои комментарии. Попробуйте отвечать прямо на мои комментарии (например, используйте функцию цитаты) вместо того, чтобы придумывать свое собственное повествование.

Они меняют его, чтобы вы могли выбрать, какой парсер JSON вам нужен (или смешать его)

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

ServiceStack должен быть доволен этим изменением и отслеживать и предоставлять отзывы об этом развитии,

У нас не было возможности сделать (или мы все еще знаем, как это сделать), но спасибо за то, что дали мне знать, что я должен чувствовать. Я бы предпочел оценить функциональность, совместимость и совместимость библиотеки, прежде чем иметь возможность оценить силу каждой из них. Может быть, это будет здорово, и будет легко поддерживать обе реализации, но, судя по опыту, взаимодействие с различными реализациями сериализатора чревато несовместимостью и угловыми случаями, а также зависимостью от различных реализаций и функций, специфичных для сериализации. Я предсказываю, что взаимодействие между JSON.NET и имплементацией по умолчанию будет отличным, поскольку это их цель дизайна и то, что проверяется, но другим сериализаторам не повезло.

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

Я оспариваю их утверждение, что они разработали это в сотрудничестве с «экосистемой». У .NET была история убийства существующей экосистемы каждый раз, когда они объединяют библиотеку «по умолчанию», что, как я ожидаю, будет. здесь (я изо всех сил пытаюсь вспомнить время, когда сборка по умолчанию когда-либо помогала экосистеме). Но, тем не менее, нам нужно разработать бесшовную интеграцию с тем, что они выпускают, к чему я хотел бы иметь доступ и вводить данные до того, как API будут заморожены. Но это нормально, я не ожидаю, что вас будет заботить, как это влияет на существующие фреймворки / библиотеки, которые должны поддерживать существующие и будущие реализации, вы, вероятно, беспокоитесь только о том, останется ли JSON.NET поддерживаться или нет, потому что это все, что влияет на вас, но Постарайтесь придерживаться своих предположений и дайте нам знать, как мы должны относиться к таким деструктивным изменениям.

Я изо всех сил пытаюсь вспомнить время, когда объединение по умолчанию когда-либо помогало экосистеме

Да ладно тебе!

(В остальном я в основном согласен с вашими мнениями)

@mythz Я удивлен, что это вызывает какие-либо проблемы, поскольку сегодня мы

Я предсказываю, что взаимодействие между JSON.NET и имплементацией по умолчанию будет отличным, поскольку это их цель дизайна и то, что проверяется, но другим сериализаторам не повезло.

Я уже могу сказать вам, что то, что мы будем поставлять, не будет поддерживать весь спектр функций, которые поддерживает JSON.NET. Так что это уже неправда, и на самом деле мы ожидаем, что в некоторых случаях он будет менее функциональным (из-за производительности и масштабов).

Возможность расширения в основном уже существует сегодня, и у нас повсюду есть реализации JSON.NET по умолчанию. Это просто меняет это значение по умолчанию на новый сериализатор JSON ...

@abatishchev

Я действительно не могу вспомнить, когда встраивание или принятие реализации по умолчанию в их базовой структуре (или проектах) приносило пользу существующей окружающей экосистеме? Каждый раз, когда я видел его в комплекте, например, NuGet, MVC, ORM, модульное тестирование, веб-API и т. Д., Он имел только пагубный эффект, эффективно забирая кислород и мотивацию для конкуренции в этом пространстве.

Бывают моменты, когда конкурирующие библиотеки, такие как ASP.NET Ajax, не могут конкурировать, где они в конечном итоге отказываются от него и принимают jQuery, но я не помню, когда это когда-либо помогало? Примечание. Это всего лишь мои наблюдения, которые я внимательно следил за .NET через несколько лет. Может быть, есть примеры, и мне было бы любопытно узнать о них? но, судя по моему обзору, последствия значений по умолчанию для MS пагубно сказываются на существующей экосистеме функций, которые она заменяет.

Преимущества @mythz для пользователей от решения по умолчанию от Microsoft - не то же самое, что преимущества для авторов альтернативного решения. EF - лучшая ORM в мире .NET, а MSTest раньше был лучше, чем NUnit. По моему мнению.

Но давайте не будем флудить и останавливаться на теме. Ваше здоровье!

@davidfowl Это просто меняет это значение по умолчанию на новый сериализатор JSON ...

Я хотел бы предложить, чтобы не было сериализатора по умолчанию, и потребовал бы, чтобы реализация была загружена. Если должно быть значение по умолчанию, будет ли оно встроено во фреймворк или в какую-то отдельную библиотеку (как это происходит сейчас)?

Я хотел бы предложить, чтобы не было сериализатора по умолчанию, и потребовал бы, чтобы реализация была загружена. Если должно быть значение по умолчанию, будет ли оно встроено во фреймворк или в какую-то отдельную библиотеку (как это происходит сейчас)?

Это неразумно, поскольку опыт будет некачественным. Каждая современная платформа имеет встроенный JSON.

@davidfowl Сейчас не вызывает проблем, потому что он не выпущен, но нам все еще нужно оценить сбои и объем работ, которые он вызовет. Сколько усилий потребуется для его беспрепятственной поддержки, сможем ли мы применить настройки к новому impl для поддержки нашего существующего поведения, сможем ли мы поддерживать новую модель настройки и API-интерфейсы, сможем ли мы настроить наш сериализатор для поддержки конфигурация / формат проводов по умолчанию будут в состоянии поддерживать новые API как .NET Core, так и .NET Framework - хотя ясно, что ASP.NET Core 3 откажется от .NET Framework, неясно, будут ли новые API использовать. NET Core только типы, которые не позволят нам продолжать поддерживать как .NET Core, так и .NET Framework.

Я уже могу сказать вам, что то, что мы будем поставлять, не будет поддерживать весь спектр функций, которые поддерживает JSON.NET. Так что это уже неправда, и на самом деле мы ожидаем, что в некоторых случаях он будет менее функциональным (из-за производительности и масштабов).

Я только ожидал, что он будет поддерживать подмножество функций JSON.NET, например, будет ли JSON.NET поддерживать проводной формат по умолчанию? (Я предполагаю, что да). Будет ли новый impl использовать форматы сериализации JSON.NET, где это возможно (также при условии, что да).

Сколько усилий потребуется для его беспрепятственной поддержки, сможем ли мы применить настройки к новому impl для поддержки нашего существующего поведения, сможем ли мы поддерживать новую модель настройки и API-интерфейсы, сможем ли мы настроить наш сериализатор для поддержки конфигурация / формат проводов по умолчанию позволит новым API-интерфейсам поддерживать как .NET Core, так и .NET Framework.

@mythz Я не слежу за некоторыми из этого. Я пытаюсь понять, сколько стоит обсуждение существующих API и того, как они будут использоваться. Может, стоит посмотреть на какие-то конкретные сценарии?

@mythz единственная реальная проблема, которую я вижу для servicestack, будет, если этот новый api не поддерживается в .net framework classic, таким образом servicestack не сможет поддерживать как .net core, так и .net classic, как клиентские, пакеты в зависимости от этих библиотек не будет полностью доступна в .NET framework. Это вас беспокоит? я спрашиваю, потому что ваша озабоченность как конкретный пример не ясна.

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

Преимущества @mythz для пользователей от решения по умолчанию от Microsoft - не то же самое, что преимущества для авторов альтернативного решения.

Под экосистемой я имею в виду окружающую экосистему / сообщества библиотеки .NET (которая, по-видимому, также является «экосистемой» в OP), которую она заменяет, которую я также утверждаю, что пользователи .NET также извлекают выгоду из здоровой экосистемы с разнообразие вариантов и большая конкуренция (как это характерно для более здоровых экосистем, таких как Python, Java, Node, Ruby, PHP и т. д.).

EF - лучшая ORM в мире .NET

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

Их последняя попытка создать уровень доступа к данным ORM в Entity Framework также негативно повлияла на некогда процветающее сообщество ранее известной ORM NHibernate. Несмотря на то, что EF в несколько раз медленнее, чем любой другой ORM с открытым исходным кодом для .NET , ему удалось привлечь больше загрузок, чем все другие ORM вместе взятые.

Имейте в виду, что это было до .NET Core, где производительность теперь является главным приоритетом, но это исторический пример пагубного влияния значений по умолчанию MS на существующие экосистемы / сообщества. ИМО, в значительной степени принято то, что происходит с существующими сообществами, когда MS вводит значения по умолчанию, поэтому недавно был предпринят отказ от настроек доставки по умолчанию, которые конкурируют с IdentityServer и AutoMapper.

и MSTest был лучше, чем NUnit в свое время.

ИМО, этого никогда не было (и поддержка R # для NUnit всегда была отличной AFAICR), и тот факт, что мы не могли запустить его кроссплатформенный на Mono, означал, что библиотеки, поддерживающие кросс-платформенный на Mono (до .NET Core), не могли использовать Это.

Но давайте не будем флудить и останавливаться на теме. Ваше здоровье!

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

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

@davidfowl @

Несмотря на это, я бы предпочел, чтобы он существовал 8 лет назад, поскольку основной причиной разработки ServiceStack.Text было то, что сериализаторы JSON .NET Framework были чрезвычайно медленными. Но после того, как все это время SS.Text был расширен ряд особенностей во всех наших библиотеках, например настроек для поддержки различных Языки ServiceStack Supports , различные варианты настройки JSON в ServiceStack , поддержка JSON в ServiceStack шаблоны , Комплексная поддержка BLOB Тип JSON в ServiceStack .Redis и т. Д.

Итак, теперь я сосредоточен на оценке того, каким будет влияние, как будет выглядеть новый API и параметры подключаемости, можем ли мы модернизировать существующие функции, сможем ли мы использовать в качестве сериализатора JSON в приложениях SS .NET Core. (что он сломает), сможет ли ServiceStack.Text поддерживать новый API, сможем ли мы поддерживать .NET v4.5, сможет ли он настроить его для поддержки проводных форматов существующих развертываний и т. д. I в основном понятия не имею, какое влияние на это окажет или какая стратегия будет развиваться, так как у меня еще не было возможности использовать или увидеть что-либо. Я узнаю больше ответов, когда у меня будет возможность использовать его, и я, очевидно, хотел бы иметь возможность протестировать интеграцию, предоставить обратную связь и предложить изменения до того, как API будут заморожены.

@mythz

Есть ли причина , почему второй наиболее популярной библиотеки JSON после JSON.NET - ServiceStack.Text , который уже был переработан ,

Упущение не было преднамеренным. Мы активно искали и работали с авторами библиотеки JSON в рамках репозитория CoreFxLab, и один из наших разработчиков начал сравнивать наши работы с их. Я считаю, что список изначально был заполнен с использованием основных поисковых запросов, таких как «json» в NuGet . Похоже, ваша библиотека просто не появилась. Я понимаю, что это может расстраивать или беспокоить вас, но постарайтесь понять ситуацию с нашей стороны: нельзя ожидать, что наша команда знает каждую библиотеку под солнцем. Это объявление является частью нашей открытой модели разработки, направленной на вовлечение всего сообщества. Единственная причина, по которой мы стремимся сначала обратиться к небольшим группам, - это убедиться, что наши планы и сообщения имеют разумный уровень осмысленности и качества, прежде чем мы поделимся ими с миром. Еще нет ничего окончательного. Мы активно ищем дополнительные отзывы.

Мне любопытно, о какой «экосистеме» вы имеете в виду и надеетесь «работать вместе» здесь?

Экосистема .NET и, в частности, стороны, заинтересованные в обработке JSON.

Мне, очевидно, было бы интересно узнать, насколько совместимы эти «подключаемые» API-интерфейсы, и станет ли это еще одной областью, в которой внедрение и интеграция новых библиотек MS убивает экосистему, которую они заменяют.

Назначение запланированных точек расширения ASP.NET Core - дать клиентам возможность заменить встроенный компонент JSON любой библиотекой JSON, которую они хотят. Конечно, ASP.NET всегда поставлялся с «включенными батареями», т. Е. Разумным вариантом по умолчанию. Раньше это был Json.NET, а в дальнейшем это компонент, предоставляемый платформой. Учитывая, что Json.NET был жестко встроен в ASP.NET, новый план кажется более подходящим для таких людей, как вы; поэтому я не совсем уверен, какая часть нашего плана, по вашему мнению, представляет собой угрозу.

Остается открытым вопрос, какие шаблоны для ASP.NET в версии 3.0 будут использовать.

Не пора ли сделать шаблоны модульными? Например, возьмем vue.js.

Создание нового приложения vue позволяет вам выбирать то, что вам нужно. Почему нельзя сделать что-то подобное для asp.net вместо создания 500 шаблонов для всех сценариев.

Вот конкретный пример функции в .ASP NET Core 2.2, в которой не-JSON.NET JSON форматировщики ввода / вывода столкнутся с проблемами, и то, как развязанное решение может помочь:
Функция ProblemDetails , которая позволяет получить ответ об ошибке, совместимый с RFC 7807 :
https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ProblemDetails.cs

[JsonProperty(NullValueHandling = NullValueHandling.Ignore, PropertyName = "instance")]
public string Instance { get; set; }

[JsonExtensionData]
public IDictionary<string, object> Extensions { get; } = new Dictionary<string, object>(StringComparer.Ordinal);

Приведенный выше код аннотируется специфическими атрибутами JSON.NET, включая конкретный резервный атрибут [JsonExtensionData] , все неизвестные свойства JSON десериализуются в этот словарь, а содержимое этого словаря сериализуется в обычную структуру JSON.

Любой альтернативный форматировщик ввода / вывода JSON теперь должен обрабатывать эти специфические атрибуты JSON.NET, чтобы иметь возможность правильно сериализовать / десериализовать этот тип или найти другой способ, то есть вернуться к JSON.NET для этих типов.

Теперь, если у нас есть четко определенная спецификация функций, которые Input / OutputFormatter для JSON должны поддерживать для 3.0, вышеуказанная проблема не существует, т. Е. Эти атрибуты могут находиться в пакете Microsoft.Extension ... и каждом Custom JSON Formatter. могли бы использовать их для реализации этой функциональности, чтобы быть совместимыми.

Насколько мне известно, в ASP.NET Core есть только несколько экземпляров «официального» исходного кода, которые аннотированы атрибутами JSON.NET, но я также видел сторонние библиотеки, использующие специфические атрибуты JSON.NET (обычно для указания имя атрибута через [JsonProperty("name")]

FWIW, вот о чем https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Я думаю, вы ответили, прежде чем прочитали мой предыдущий комментарий, который ИМО разъясняет мои опасения.

Мы активно ищем дополнительные отзывы.

Где? Есть ли предложение / документ по API, создан ли API, под каким репо он разрабатывается?

Думаю, вы ответили до того, как прочитали мой предыдущий комментарий, который ИМО больше проясняет мои опасения.

Я читал его, но, похоже, вы против использования любого значения по умолчанию, что, как объяснил @davidfowl , для нас нецелесообразно. Я хотел сказать, что наш план - это улучшение того, что у нас есть в настоящее время, то есть фактическое подключение к Json.NET. Отсюда мой вопрос.

Где? Есть ли предложение / документ по API, создан ли API, под каким репо он разрабатывается?

Мы намеренно еще не занимались программированием / проектированием API в .NET Core, потому что хотели выпустить это объявление в первую очередь. Мы не хотели, чтобы люди читали чайные листья, не предоставив контекста, представленного в этом объявлении. Другими словами, следите за обновлениями, мы скоро опубликуем API и код.

@terrajobst Все впечатление от публикации, что

1. Решение о внесении изменений принято.

В дальнейшем мы планируем внести некоторые изменения в нашу поддержку JSON:

1. Сделан предварительный дизайн
   Нам нужны высокопроизводительные API-интерфейсы JSON.
   Удалите зависимость от ASP.NET Core к Json.NET.
   Предоставьте пакет интеграции ASP.NET Core для Json.NET.

Все это означает, что направление взято. Все, что требуется от «экосистемы», - это найти очевидные болевые точки, которые MS не может реально объяснить.

Упускать ServiceStack и обсуждать его как некую вторичную библиотеку .NET - смехотворно. Даже если я использую только библиотеки, поставляемые MS, это не значит, что я не знаю об альтернативах.

У меня нет проблем с тем, что MS принимает решения, но если бы это было прямо заявлено и не покрыто «отзывами сообщества» по уже принятым решениям.

Это мое впечатление

@terrajobst

Я читал это, но, похоже, вы против того, чтобы иметь какое-либо значение по умолчанию

Никогда не предполагал, что до этого JSON.NET уже использовался по умолчанию. Я объяснил более подробно выше, но, повторюсь, это позиционируется, чтобы взять на себя стандарт по умолчанию и стать новым стандартом де-факто, где в действительности .NET Core будет иметь только 2 сериализатора JSON в будущем: этот новый де-факто высокопроизводительный стандарт по умолчанию и JSON. NET для пользовательских функций. Другие сериализаторы JSON станут нишевыми, например, добавлены уникальные функции для поддержки различных сценариев.

Мы сознательно не занимались программированием / проектированием API .NET Core, потому что хотели получить это объявление первыми.

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

Мы не хотели, чтобы люди читали чайные листья, не предоставив контекста, представленного в этом объявлении. Другими словами, следите за обновлениями, мы скоро опубликуем API и код.

Значит, тогда он был разработан внутри компании? Через какое время после его выпуска посторонние должны будут тестировать и предлагать изменения в дизайне API? Меня больше всего беспокоит то, как будут выглядеть «подключаемые» и «расширяемые» API, сможем ли мы «взять на себя» и иметь полный контроль над форматом проводов для типов Ref / Value? А как насчет встроенных типов, перечислений, bools, других встроенных функций и т. Д.? Например, в качестве примера можно будет настроить bool для приема других популярных значений JSON, таких как «да», «вкл», «1».

Другие вопросы:

• Можно ли использовать эту реализацию отдельно (в отдельном пакете NuGet)?
• Связана ли "подключаемая" часть API с веб-платформой или ее можно использовать в другом месте (например, Xamarin / UWP)
• Будет ли он поддерживать .NET Standard 2.0 или .NET v4.5?
• Если нет, смогут ли API поддерживать .NET Standard 2.0 или .NET v4.5?

@mythz
На самом деле он не разработан внутри (насколько мне известно), часть Reader / Writer выполняется в corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) и, в частности, в corefxlab для него пока нет высокоуровневого API.

Лично я бы исключил, что расширяемые / подключаемые части API должны быть .NET Standard (т.е. атрибуты и т. Д.). На данный момент библиотека в corefxlab - это .NET Standard 1.1, но я предполагаю, что это изменится в зависимости от целей производительности библиотеки и т. Д.

@mythz

Кажется, вам не терпится принять мои утверждения и поместить их в контекст «стакан наполовину пуст». Я понимаю, вы настроены скептически. Я предлагаю сэкономить несколько нажатий клавиш и обсудить конкретные предложения API, а не обсуждать их абстрактно. Я совершенно убежден, что наш план предоставит вам необходимые точки продления.

@terrajobst Не пытаюсь быть скептиком, пытаясь узнать, какие высокоуровневые предлагаемые возможности, которые, как я полагаю, уже определены (или все они еще не определены?). Это объявление является первым, о котором слышало большинство из нас, поэтому я хотел получить некоторые разъяснения относительно того, насколько он может быть расширяемым, расширяемым и многоразовым. Является ли System.Text.JsonLab текущим impl? Означает ли это, что он также будет поддерживать .NET Standard 2.0 и .NET v4.5?

Это может быть хорошей функцией для создателей библиотек, но вы также должны учитывать, что корпоративные разработчики используют 50 библиотек с деревьями зависимостей и пытаются найти совместимость между ними. Будут ли конфигурации сопоставления в стиле привязки-перенаправления для устранения несоответствий?

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

Похоже, это изменение вызвано двумя причинами. Во-первых, это стремление к повышению производительности за счет использования новых типов в .Net Core.

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

Это сломает вещи? Да! Вот почему на объявлении есть надпись «критические изменения». (Может быть, этот ярлык следует воспроизвести здесь.) И поскольку известно, что это критическое изменение, было начато обсуждение, чтобы изучить влияние. Кроме того, чтобы минимизировать влияние, будет предоставлена ​​дополнительная библиотека, которая позволит людям продолжать использовать JSON.Net.

Мне как автору библиотеки это очень интересно, и я бы предпочел, чтобы разговор продолжался.

@Tornhoof в ответ на ваши примеры, если я хочу продолжить использование JSON.Net, мне нужно будет также сослаться на библиотеку совместимости, о которой я упоминал ранее. В основном это должно быть plug-and-play, но могут быть изменения. Я определенно не хочу, чтобы структура (.Net Core) диктовала, что сериализатор, который я выбираю, ДОЛЖЕН использовать эти атрибуты для сериализации, особенно когда мой сериализатор использует другой механизм для аналогичных концепций.

Решение, предоставляемое .Net, должно быть более общим, чем это. Обработка сериализации конкретной модели должна выполняться выбранной реализацией JSON.

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

@gregsdennis
Я не уверен, что вы имеете в виду под более общим?
Предполагая, что ваш сериализатор имеет концепцию переопределения имен свойств json, изменения их нулевого поведения и / или резервных / универсальных реализаций и предполагая, что все три функции являются частью общей спецификации для сериализаторов JSON для .net core 3.0, тогда пакет реализации сопоставляет эти атрибуты с деталями вашей внутренней реализации.
Например, если ваша библиотека предпочитает использовать [DataMember] для указания имени свойств (как это делает SpanJson), ваш пакет интеграции должен легко отобразить это.
Я не говорю, что атрибуты - это правильный путь, это просто видимая часть примера кода.

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

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

Есть ли планы использовать инструкции SIMD в новом парсере JSON, например, в RapidJSON?

Ссылка: http://rapidjson.org/

Предлагаемое предложение выглядит хорошо, но, пожалуйста, просто попробуйте сгладить «критические изменения ». Я просто обычный пользователь сторонних библиотек, и недавно был один из таких случаев, когда отражение было внезапно исключено из процесса сборки собственного выпуска UWP .net (компилятор ).

Таким образом, ни одно из моих приложений UWP не могло быть создано в режиме выпуска в течение нескольких месяцев, так как мне пришлось переписать весь код, который использовал отражение в сторонних библиотеках. Я знаю, что многим авторам библиотек пришлось снова разделить свои реализации, чтобы исключить отражение в этих частях UWP. Большинство авторов библиотеки не пришли на вечеринку, и я был вынужден покинуть корабль. Хотя MS вышла на первый план и взяла на себя обязательство реализовать альтернативу в стандарте .net 2.1. мы знаем, что реальность такова, что для реализации стандарта .net 2.1 потребуются месяцы с момента первоначального критического изменения.

Дело в том, что это был чрезвычайно разрушительный для меня процесс, который имел огромные последствия для конечных пользователей и был совсем не «гладким» и беспроблемным.

Это определенно правильный шаг.
Мне интересно какое-то время видеть эту ссылку Json.Net.

@Tornhoof Я думаю, что должно быть определенное разделение: интерфейсы, которые каждый провайдер должен будет реализовать для использования с .Net Core 3.0, и встроенная реализация по умолчанию.

Интерфейсы должны быть как можно более универсальными. Возможно, столь же упрощенно, как определение только методов Serialize() и Deserialize() .

Остальные детали оставьте на усмотрение реализации. Если реализация по умолчанию использовала атрибут для определения механизма ввода настраиваемых свойств, меня это устраивает. Я думаю, что это специфическая для реализации деталь, которая не должна быть частью интерфейса.

Тем не менее, возможность настраивать свойства ключей может быть требованием, хотя я не уверен, как это можно кодифицировать.

@gregsdennis Да, вы правы, я в основном смотрел на IInput / OutputFormatter, которые уже существуют в настоящее время в ASP.NET Core, и, в частности, на проблемы, связанные с их заменой версиями, отличными от JSON.NET.
В любом случае, как показывают ваши комментарии и комментарии @mythz , я думаю, что определение области будет интересным и, вероятно, не таким простым (я помню проблемы со спецификациями интерфейса DI). Так что лучше на ранних этапах процесса задействовать много разных точек зрения.

@Tornhoof согласился. Современные интерфейсы Formatter отчетливо JSON.Net основе, но не так много на самом сериализаторе, а на объекте опций. Кажется, что нам также понадобится общий способ передачи параметров (общий объект параметров).

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

Не сейчас мы так поступаем. Параметры зависят от сериализатора и для них нет общего интерфейса. Форматировщики в MVC уже должным образом разложены и ни с чем не связаны. JsonResult будет иметь критические изменения, потому что он напрямую принимает JsonSerializationOptions (тип JSON.NET).

Я собирался сказать то же самое. Мы не планируем создавать абстракцию для чтения / записи / сериализатора JSON. Это не нужно; Фреймворки либо работают с примитивами ввода-вывода (такими как Stream , TextReader ), либо подключаются к обработке фреймворка более высокого уровня (например, средства форматирования ASP.NET Core).

Говоря о болевых точках: лично (а я, вероятно, в очень небольшом меньшинстве) меня беспокоит слабая природа многих парсеров JSON. Существует стандарт (tm), но большинство парсеров проявили снисходительность и принимают документы, не соответствующие требованиям. Что в конечном итоге плохо в этом, так это то, что разработчики не реализуют стандарт, который они внедряют в отношении библиотеки. Если библиотека допускает несоответствующий документ, разработчики довольны, если все биты используют одну и ту же библиотеку. Боль возникает при попытке установить связь между доменами, использующими разные библиотеки. Внезапно возникает проблема, потому что разные библиотеки поддерживают разные разновидности JSON.

Должны ли мы устранить болевые точки, сделав библиотеку JSON как можно более снисходительной (но, возможно, в итоге получится сложность и двусмысленность) или атаковать первопричину; неподтверждающие библиотеки JSON.

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

(То, что не входит в стандарт; комментарии, конечные запятые, строки одинарных кавычек, строки без кавычек и т. Д.)

IMHO, поскольку JSON происходит из мира веб-браузеров, кажется, что для взаимодействия мы должны выбрать double в качестве базового представления для чисел в JSON, хотя стандарт JSON ничего не говорит о репутации.

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

@mrange - насколько мне нравится делать вещи максимально строгими ... это зависит от возможности вносить изменения в несоответствующий код.

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

@terrajobst спасибо! Func<Stream, CancellationToken, Task<T>> и Func<T, CancellationToken, Stream, Task> - это все, что здесь нужно. Возможно, с некоторыми перегрузками для TextReader / Writer, Span и string.

Однако обратная сторона заключается в том, что вы хотите сериализовать / десериализовать другой тип библиотеки, и этот тип украшен атрибутами из сериализатора json, который вы не используете.

@thefringeninja, если вы уже используете стороннюю библиотеку для объектов, значит, у вас уже есть ссылка на другой сериализатор. Там ничего не изменилось.

Я не из тех, кто разжигает страх, но думаю, что у аргументы .

@terrajobst Что касается экосистемы, хотя невозможно учесть каждую существующую библиотеку, я не думаю, что быстрый поиск «json» на NuGet что-то кому-то скажет. Возможно, имя ServiceStack.Text - не самый явный способ сказать «Эй! Я пакет, который может (де) сериализовать JSON!», Но на протяжении многих лет его сравнивали. Возможно, дело в том, что вы пытаетесь обмануть настройки MS по умолчанию и либо не знать широты и популярности альтернатив, либо использовать их достаточно часто для внутреннего использования, чтобы ознакомиться с ними.

Я согласен с тем, что должно быть какое-то значение по умолчанию, чтобы обеспечить работу, которая _просто работает_ "из коробки". Если другие авторы библиотек в экосистеме опубликуют пакет интеграции, было бы здорово, если бы они могли включить в документацию, примечания к выпуску и т. Д., Чтобы подчеркнуть, что есть альтернативы помимо значений по умолчанию. Сделать открытие было бы проблематичным для экосистемы.

Я надеюсь, что если цель устранения зависимости искренняя, API-интерфейсы должны лучше всего отражать потребности сообщества, а не моделироваться непосредственно после Json.NET. Суть в том, что это потребует работы всех авторов библиотеки, а не только ServiceStack, но API-интерфейсы не должны напрямую напоминать API Json.NET, иначе вы вернетесь к тому, что выглядит как зависимость, но без dll.

API не должны напрямую напоминать API Json.NET

... или реализация любого другого конкретного поставщика.

Часть обсуждения, которое имело место до объявления, включала идею о том, что команда .Net будет использовать данные из различных библиотек, чтобы понять, как были решены различные проблемы, а затем использовать то, что, по их мнению, будет наиболее подходящим из них. идеи в сочетании с собственными. Во многом это не отличается от того, как будет разрабатываться любая другая новая библиотека JSON; просто так получилось, что этот будет включен в рамки.

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

Прежде чем что-либо обсуждать, подумайте об использовании результатов Microsoft Research в этой области (точнее, без ветвления и анализа FSM) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -data-analytics /

Мы идем в этом направлении для высокопроизводительного парсинга JSON --- конечно, помимо Span<T> ---
cc @terrajobst @karelz

:( Все это обсуждение JSON заставляет меня думать, что мой вопрос о шаблонах пропал.

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

Я видел много отозванных пакетов для ядра и 461, и я надеюсь, что этот тип или изменение исправят это.

Я боюсь, что каскадные проблемы будут преследовать нас, пожалуйста, докажите, что мы неправы.

// точечные чистые разработчики повсюду

@ c0shea

[…] Было бы здорово, если бы они могли включить в документацию, примечания к выпуску и т. Д., Чтобы подчеркнуть, что есть альтернативы помимо значений по умолчанию.

Я уверен, что так и будет. В документации уже перечислены альтернативные реализации для нескольких тем, таких как контейнеры DI , поставщики журналов , интеграция Swagger или поставщики баз данных EF Core .

@ Филлип-Хейдон
Система шаблонов уже поддерживает настраиваемые шаблоны, а существующие шаблоны фактически уже имеют ряд опций. Просто проверьте, например, dotnet new mvc --help чтобы узнать, что в настоящее время возможно. Я уверен, что вы могли бы легко расширить это, например, альтернативными интеграциями сериализатора JSON, и запросы функций или запросы на вытягивание для этого, вероятно, будут приняты в aspnet / Templates .

@mrange - насколько мне нравится делать вещи максимально строгими ... это зависит от возможности вносить изменения в несоответствующий код.

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

Может быть, иметь строгий режим по умолчанию и иметь возможность явно переключить его в более мягкий режим

@poke Думаю, вам действительно нужно попробовать vue cli, а затем повторить попытку dotnew new. Текущий дотнет новый ... это ... это ...

Могу я попросить вас запомнить, что различные браузеры, выполняющие синтаксический анализ JSON, не поддерживают должным образом значения int64 и дают нам возможность сериализовать / десериализовать длинные строки в виде строк? Это одна из тех вещей, которые вы не замечаете, пока она не укусит вас сильно. Разновидностью этого является возможность решить, десериализованы ли числа по умолчанию в целые или длинные.

Могу я попросить вас запомнить, что различные браузеры, выполняющие синтаксический анализ JSON, не поддерживают должным образом значения int64 и дают нам возможность сериализовать / десериализовать длинные строки в виде строк? Это одна из тех вещей, которые вы не замечаете, пока она не укусит вас сильно. Разновидностью этого является возможность решить, десериализованы ли числа по умолчанию в целые или длинные.

.... Ах, EcmaScript, спасибо, что все удвоилось. Я уверен, что это не вызвало проблем в какой-то другой части кода ...

Как пурист, я не люблю подобные вещи.
Как реалист, думаю, мне придется с этим согласиться.

Будет ли какая-либо часть новой реализации JSON в .Net Standard 2.1 ?

Я немного слежу за этим и не уверен, что пропустил. Могу ли я просмотреть предлагаемую поверхность или интерфейс API? Мне интересно посмотреть, что такое API-интерфейс для этого предложения.

Могу ли я просмотреть предлагаемую поверхность или интерфейс API?

Еще многое предстоит сделать, но https://github.com/dotnet/corefx/pull/33216 - это только начало. Вот примечания к обзору API .

ОБНОВЛЕНИЕ: Дорожная карта также доступна здесь .

Итак, насколько полная функция будет сравнивать api aspnet 3.0 с api json.net? Кроме того, будет ли прекращено использование json.net для всех намерений и целей путем разработки новых приложений с собственным api?

просто улучшить производительность или заменить все функции json.net?

Это потрясающая новость.

Я настоятельно рекомендую попытаться сотрудничать с @neuecc, его работа с MessagePack , Utf8Json , ZeroFormatter и т. Д. Была феноменальной.

@link в

Я подозреваю, что большинство пользователей aspnet не будут иметь сильной зависимости от реализации json.net и смогут практически беспрепятственно выполнить миграцию.

Могу ли я просмотреть предлагаемую поверхность или интерфейс API?

Еще многое предстоит сделать, но dotnet / corefx # 33216 - это только начало. Вот примечания к обзору API .

ОБНОВЛЕНИЕ: Дорожная карта также доступна здесь .

@khellang Мы собираемся получить помощь по

Еще одно хорошее движение в направлении OSS. Будет мотивировать разработчиков других коммерческих платформ разработать что-то лучшее, чем MS, что уже делает, бесплатно, или стать полностью OSS, если они действительно заботятся о сообществе.

Собираемся ли мы получить какую-либо помощь по языку, чтобы по-настоящему написать json на C #?

@dotnetchris Я не для JSON ?

@khellang , это, безусловно, шаг в правильном направлении, но я имею в виду полную поддержку. Используя те же образцы объектов из вашей ссылки, больше похожие на:

json v1 = { 
                    first: 0, 
                    second: ["s1", "s2" ] 
                }

var andCsharp = v1.second.Where(item => item.EndsWith("1"));

При достаточном количестве вуду, таком как неявная генерация объекта кортежа / значения / записи, чтобы все это работало на уровне языка за кулисами.

И наоборот, компилятор может вызывать службы json, создавать класс, а затем работать с экземпляром класса, как если бы вы написали:

var v1 = "{ first: 0, second: ['s1', 's2' ] }".Deserialize<MyV1>();

Изменить: LOL @ downvoters.

@dotnetchris https://github.com/dotnet/csharplang/issues/1238

@dotnetchris Если вам интересно, проголосуйте, пожалуйста, на https://github.com/dotnet/roslyn/pull/24110. Команда IDE закрыла его из-за отсутствия интереса. Но если наберется достаточно голосов, возможно, это может измениться.

Означают ли «встроенные» и «предоставленные платформой» JSON API, что это не будет отдельный (сетевой стандарт) пакет nuget? Если нет, то почему бы и нет?

Я полагаю, что новая общая платформа ASP.NET Core не может зависеть от пакетов nuget, или может?

Разве еще не существует пространства имен System.Json ? Это пространство имен, которое будет использоваться / расширяться для .NET Core 3.0 и, в конечном итоге, .NET Standard. Это пространство имен уже используется (может использоваться не так часто, но доступно 😅) в Xamarin.Android 7.1+, Xamarin.iOS 10.8+ и Xamarin.Mac 3.0+.

Его удаление нарушит обратную совместимость. Выход из него и запуск нового API может вызвать некоторую путаницу. Расширение / улучшение без удаления каких-либо API может быть немного ограничивающим при добавлении новых API.

Было бы здорово иметь интерфейсы для JsonReader / JsonWriter, потому что есть и другие источники и цели, чем просто потоки. Например, я также использую JSON.NET для MongoDB. Это быстрее, и мне не нужно поддерживать несколько сериализаторов в моих приложениях.

Я знаю, что это может немного повлиять на производительность, но это очень полезно.

@SebastianStehle : JsonReader / JsonWriter - абстракции высокого уровня, см. Комментарий terrajobst

План на 3.0 следующий:

1. Встроенные высокопроизводительные API-интерфейсы JSON. Читатель / писатель низкого уровня, читатель / писатель на основе Stream и сериализатор.
2. ASP.NET Core подключается к компоненту JSON.

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

Высокоуровневый, простой в использовании API будет обернут вокруг потоков, чтобы легко десериализовать из потоков и в потоки (это часто наиболее распространено при сериализации. Если вам нужна максимальная производительность в сценариях, где вы не можете использовать потоки, вам следует использовать низкий API уровня, которые работают с Span<T> или Memory<T> , особенно когда у вас есть данные уже под рукой / в памяти, которые вы хотите использовать, и не имеете накладных расходов на асинхронность.

@TsengSR

https://github.com/neuecc/Utf8Json не предоставляет функциональные возможности для написания пользовательских читателей / писателей из-за соображений производительности (виртуальные вызовы и распределения, я думаю), и я подумал, что они хотели бы пойти по тому же пути. Но пока я не видел кода сериализации.

Я согласен с @ JonasZ95 и @gregsdennis , я надеюсь, что реализация не будет простой абстракцией тех же деталей реализации JSON.Net, а вместо этого сосредоточится на том, как это _ должно_ выглядеть.

Я также считаю, что к нему следует подходить как к 2 отдельным функциям ...

1. сериализация / десериализация
2. json-версия указанной сериализации и десериализации.

Надеюсь, платформа ASP.NET Core будет использовать общую абстракцию сериализации вместо абстракции, специфичной для JSON.

Что касается расширяемости, я надеюсь, что фреймворк будет использовать метод DI для кодирования абстракций (интерфейсов, а не абстрактных классов) и просто предоставит локальное значение по умолчанию. С точки зрения авторов библиотеки JSON, это обеспечит максимальную расширяемость, потому что все, что вам нужно сделать, это предоставить класс адаптера ASP.NET Core, который использует библиотечную реализацию интерфейсов, а затем настроить ASP.NET Core для использования адаптера библиотеки.

Реализация сторонней библиотеки может выглядеть примерно так:
`` С #
// ссылка на сторонние библиотеки
с помощью Newtonsoft.Json;

// очень наивный пример для краткости, чтобы
// подчеркиваем суть
открытый класс NewtonsoftAdapter: ISerializer
{
частный JsonSerializerSettings _settings;
частное форматирование _format;

public NewtonsoftAdapter(JsonSerializerSettings Configuration, Formatting FormatOption)
{
    _settings = Configuration;
    _format = FormatOption;
}

    // interface method
public string Serialize<T>(T Subject)
{
    return JsonConvert.SerializeObject(Subject, _format, _settings);
}

    // interface method
public T Deserialize<T>(string SerializedContent)
{
    return JsonConvert.DeserializeObject<T>(SerializedContent, _settings);
}

}

...

// настраиваем адаптер со сторонними параметрами настройки
var settings = новый JsonSerializerSettings
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = new NewtonsoftAdapter (настройки, Formatting.Indented);

// настраиваем ядро ​​asp.net
// где адаптер реализует ISerializer (или любое другое имя, которое вы придумали)
// авторы библиотеки могут даже предоставить свой собственный метод расширения UseXYZ ().
app.UseSerializer (адаптер);
`` ''

В синтаксическом анализе текста на основе SIMD, в том числе для структурированного текста, такого как JSON, произошел большой прогресс. Есть ли шанс, что работа в .NET Core приблизится к этому уровню производительности? Есть ли способ использовать эти методы?

Эй, даже у Microsoft Research есть новые высокопроизводительные решения !

@AnthonyMastrean Спасибо, что подняли этот вопрос. Мне также интересны любые тесты, чтобы понять, как этот текущий Json impl сравнивается с simdjson.

Кстати, авторы simdjson сказали, что они все еще работают над полной публикацией этого проекта (я думаю, еще док). А пока вы можете прочитать интересное обсуждение этого проекта на HN .

Есть ли способ использовать эти методы?

.NET Core 3.0 просто включает в себя набор встроенных функций, платформы , так что это определенно выполнимо 😄

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

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

Там, где я работаю, мы каждый день анализируем терабайт JSON. Я также знаю других, которые используют .NET и F # для обработки большого количества документов JSON. JSON стал больше, чем просто транспортным механизмом сервер => браузер. Он часто используется в чисто серверных сценариях.

OFC; бэкенду было бы лучше переключиться на двоичный формат, такой как AVRO / Protobuf, но часто это сложно, и у JSON есть некоторые преимущества (я неохотно признаю). Наличие действительно быстрого парсера JSON может буквально сэкономить 10 000 долларов в месяц для компаний, подобных нам.

@poke Этот проект относится к .NET Core (не ASP.NET ...), поэтому он актуален для всех рабочих нагрузок, а не только для Интернета.

Я могу согласиться с тем, что уже слишком поздно работать над этим конкретным методом оптимизации для .NET Core 3.0, но я надеюсь, что сейчас будет проведено некоторое исследование, чтобы гарантировать, что оптимизация будет возможна в будущем (то есть без критических изменений ).

Может быть, лучше сделать что-то вроде унифицированной сборки сопоставления ('System.Text.Json.Mapping'), где определять атрибуты и другие вещи для сопоставления JSON с классами C #? После реализации этой вещи все существующие парсеры / писатели JSON могут быть адаптированы для использования унифицированного сопоставления. Это даст возможность всем приложениям .NET Standard без проблем перемещаться между разными библиотеками JSON.

@AlexeiScherbakov Новые абстракции не особо помогают. Вы просто снова ограничите себя, выбрав общую абстракцию, и всегда будут новые библиотеки, которые не могут использовать абстракцию и требуют большего. Так было всегда, например, с ведением журнала .

Я не думаю, что создание новой абстракции, основанной на этой новой реализации, принесет нам какую-либо пользу, особенно когда библиотека в любом случае спроектирована так, чтобы быть намного менее многофункциональной.

И на самом деле уже существует абстракция netstandard в форме DataContract / DataMember, которую, я надеюсь, эта библиотека в конечном итоге будет уважать (даже если эта абстракция несколько ограничена).

Кроме атрибута игнорирования, у нас не может быть миллиарда новых атрибутов и сценариев для обслуживания. Я бы предпочел сопоставление JSON с классами 1: 1, если вы хотите сделать что-то необычное или поддерживать устаревшее, используйте json.net.

Лично меня не особо интересуют классы JSON <=> C #. Я думаю, что важно иметь концепцию синтаксического анализа / записи JSON, отделенную от созданной объектной модели C # от модели JSON.
Таким образом, я (который не очень заботится о классах JSON <=> C #) могу иметь действительно эффективный синтаксический анализатор без обхода какой-то объектной модели.

@mrange вот для чего

Означает ли это, что я могу рассчитывать на API Reader / Writer на платформе, предоставляемой JSON API? Является ли шаблон "Читатель / Писатель" наиболее эффективным?

На данный момент в System.Text.Json типа :

• Utf8JsonReader - быстрый, без кеширования, прямой способ чтения текста JSON в кодировке UTF-8.
• Utf8JsonWriter - ^ То же, что и Utf8JsonReader , но для записи.
• JsonDocument - модель документа с произвольным доступом только для чтения для полезных данных JSON.

Все вышеперечисленные типы должны быть (более или менее) свободными от размещения 👍

Мы разместили статью о simdjson: https://arxiv.org/abs/1902.08318

Также продолжается работа над портом simdjson на C #: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

Может быть, лучше сделать что-то вроде унифицированной сборки сопоставления ('System.Text.Json.Mapping'), где определять атрибуты и другие вещи для сопоставления JSON с классами C #? После реализации этой вещи все существующие парсеры / писатели JSON могут быть адаптированы для использования унифицированного сопоставления. Это даст возможность всем приложениям .NET Standard без проблем перемещаться между разными библиотеками JSON.

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

Вероятно, сопоставление классов json с классами C # 1-1 было бы лучшим подходом, по крайней мере, в некоторых случаях вы могли бы избежать создания новых классов, даже если классы типов viewmodel по-прежнему будут необходимы в других случаях.

Было бы неплохо, если бы был какой-то способ игнорировать свойства, которые не нужны, и, по крайней мере, контролировать некоторые аспекты сериализации (например, верблюжий против паскальского корпуса).

@mrange вот для чего

@davidfowl Означает ли это, что новые API идут по этому пути? Доработан ли дизайн?

Пока мы говорим, поддержка сериализации приземляется. В связанной проблеме говорится:

• Из-за нехватки времени и для сбора отзывов набор функций предназначен для минимально жизнеспособного продукта для версии 3.0.
• Нацелены на простые сценарии объекта POCO. Обычно они используются для сценариев DTO.
• API разработан с возможностью расширения для новых функций в последующих выпусках и сообществом.
• Атрибуты времени разработки для определения различных параметров, но по-прежнему поддерживают модификации во время выполнения.
• Высокая производительность с использованием IL Emit с откатом к стандартному отражению для совместимости.

В нем также подробно рассказывается, как они планируют поддерживать преобразование перечислений, обработку нулей, верблюд против PascalCasing и т. Д.

Если у вас есть отзывы по этому поводу, вы должны оставить свои комментарии в этом выпуске или запросе на перенос.

@lemire Вау, это действительно круто. simdjson действительно супер быстрый.

Есть ли шанс, что вы сможете реализовать тест сериализации JSON TechEmpower ? (Я знаю, что работы будет намного больше)

Я нашел эти реализации: в репозитории TechEmpower и в репозитории ASP.NET .

@KPixel Это сериализация, верно? Между тем simdjson - это парсер ... Если я не запутался в терминах, эти вещи идут в противоположных направлениях?

Виноват. Я предположил, что есть часть десериализации (которая будет использовать парсер).

Будет ли System.Text.Json стандартным пакетом nuget для .NET? или это то, что доступно только для .net core 3.0?

@ John0King , посмотрите здесь: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Я думаю, что удобство использования также должно быть в центре внимания нового пакета JSON. Одна из функций, которые, как мне кажется, должны быть, - это поддержка проверки схемы JSON. Newtonsoft взимает за это плату. Это что-то достаточно фундаментальное, поэтому оно должно предоставляться на платформе бесплатно, как это было в случае проверки схемы XML.

@ jemiller0 У меня сложилось впечатление, что проверка XML была в некоторой степени неоднозначной, а схема JSON получила

@lemire Да, это большое дело, если вы разрабатываете программное обеспечение с открытым исходным кодом и хотите сделать свое программное обеспечение доступным для всех. Разбор XML - это не смешанный пакет. Оно работает. То же самое и с проверкой схемы JSON. Отсутствие встроенного бесплатного способа сделать это делает платформу .NET неконкурентоспособной.

Я никогда не видел, чтобы схема json использовалась в реальном мире. Даже в этом случае он не должен быть частью обсуждаемой здесь реализации. И ни одна из миллиардов других функций и причуд в json.net также не должна быть реализована здесь. Это должно быть не что иное, как сверхлегкая быстрая реализация. Если вы недовольны тем, что вам нужна лицензия для json.net для поддержки проверки json. Создайте свою собственную реализацию с открытым исходным кодом и сделайте ее свободно доступной.

@ jemiller0

Мне искренне любопытно: предлагают ли другие языки программирования поддержку схемы JSON в своей стандартной библиотеке?

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

Если вам нужна проверка схемы JSON, вы можете реализовать валидатор поверх этой библиотеки, который должен быть достаточно низким, чтобы вы могли это сделать.

Я не верю, что проверка схемы JSON в стандартной библиотеке имеет какое-либо отношение к конкурентоспособности платформы или нет.

Цель этой библиотеки - быть высокопроизводительной низкоуровневой библиотекой для работы с JSON. Все, что не так, включая большинство более продвинутых функций JSON.NET, не будет частью этого.

За исключением того, что он также будет включать функции более высокого уровня, призванные заменить Newtonsoft.Json 😊

@poke Вы имеете право иметь любое мнение, как и я. XML используется повсеместно. Следовательно, Microsoft справедливо включила поддержку валидации в .NET Framework. Сейчас JSON в моде и используется ВЕЗДЕ, в файлах конфигурации, веб-API и т.д. Лично мне кажется немного смешным, что Microsoft с самого начала использует стороннее программное обеспечение. Это должно быть основной особенностью платформы.

@lemire Я скоро

Я использую схемы JSON на работе, и у меня скорее есть действительно хороший парсер JSON, чем наполовину хороший парсер JSON + валидатор схемы JSON. Также AFAIK JSON Schema - это _draft_ 7 прямо сейчас. Поэтому для меня имеет смысл использовать схему JSON как внешнюю библиотеку, которая может быстро развиваться вместе со схемой. Хотя было бы неплохо иметь схему JSON в дорожной карте.

@ jemiller0

Имеет смысл иметь такой же уровень поддержки JSON, какой исторически поддерживался для XML.

.Net также включает поддержку XSLT и XPath. Если вам нужен «такой же уровень поддержки», разве это не значит, что вам также понадобится какая-то их версия для JSON?

Я пытаюсь сказать: экосистема JSON отличается от экосистемы XML. Оба имеют разные шаблоны использования, а соответствующие технологии имеют разные уровни использования и уровни стандартизации. Кроме того, XML был добавлен в .Net до того, как появились NuGet, git или GitHub. В настоящее время гораздо проще и приемлемее полагаться на стороннюю библиотеку.

Так что нет, я не думаю, что имеет смысл слепо говорить: «Это было в XML, значит, это должно быть и в JSON».

Кроме того, проверка просто ортогональна синтаксическому анализу. Я был бы абсолютно согласен с добавлением поддержки валидации в какой-то момент (возможно, в другом пакете вообще). Но это совсем не обязательно для правильной поддержки синтаксического анализа.

Нам нужен способ строгой проверки данных в запросах API REST.
Потому что мы сохраняем json, который поступает через API без ошибок, а позже мы не можем проанализировать его в JS из-за запятых в конце и так далее.

И почему вы не можете подтвердить этот запрос сейчас?

@ phillip-haydon @ freerider7777 Я думаю, что любой достойный парсер JSON должен соблюдать спецификацию JSON и выдавать ошибки (и / или предупреждения), когда документ не правильно сформирован (например, когда в нем есть запятые). Это довольно просто, но также отличается от проверки, которая представляет собой сравнение данных JSON со схемой (по крайней мере, так я использую термины).

https://tools.ietf.org/html/rfc7159

Microsoft, одной из крупнейших компаний по разработке программного обеспечения, некому заниматься валидацией. Более важен быстрый парсер. Это позволит вам анализировать недопустимый JSON со скоростью света. :-) Никому не приходило в голову, что быстрая проверка может быть полезной. Это похоже на ASP.NET Core, быстрое упрощенное обновление до веб-форм.

И почему вы не можете подтвердить этот запрос сейчас?
@ phillip-haydon В коде контроллера с таким json:
ModelState.IsValid == true

🤦‍♂️

Вы можете выполнить проверку на основе вашей схемы json уже с помощью NSwag + System.ComponentModel.DataAnnotations :

<Project Sdk="Microsoft.NET.Sdk" >
  <ItemGroup>
    <PackageReference Include="NSwag.MsBuild" Version="12.0.10" />
  </ItemGroup>
  <ItemGroup>
    <Compile Remove="**\*.g.cs" />
  </ItemGroup>
  <ItemGroup>
    <SchemaFiles Include="$(MSBuildProjectDirectory)\..\schema\*.json" InProject="false" />
    <EmbeddedResource Include="$(MSBuildProjectDirectory)\..\schema\*.json" LinkBase="Messages\Schema" />
  </ItemGroup>
  <Target Name="GenerateMessageContracts" BeforeTargets="GenerateAssemblyInfo">
    <Exec Command="$(NSwagExe_Core21) jsonschema2csclient /name:%(SchemaFiles.Filename) /namespace:MyNamespace.Messages /input:%(SchemaFiles.FullPath) /output:$(MSBuildProjectDirectory)/Messages/%(SchemaFiles.Filename).g.cs" />
    <ItemGroup>
      <Compile Include="**\*.g.cs" />
    </ItemGroup>
  </Target>
</Project>

Я согласен с @lemire , есть разница в проверке структуры JSON и проверке JSON по схеме. Я не сомневаюсь, что Microsoft потратила время и усилия, чтобы правильно реализовать первое ... второе - это крайний случай, и я не думаю, что он вписывается в общий дизайн этой библиотеки JSON. Я почти уверен, что они ясно дали понять, что эта библиотека JSON предназначена ТОЛЬКО для обеспечения быстрого и эффективного анализа, необходимого для работы ядра asp.net. Он не был разработан для включения _extras_, которые поставлялись с парсером newtonsoft. (см. комментарий @poke ранее в теме).

Я не думаю, что тот факт, что они намеренно не разработали его так, чтобы иметь все навороты, не делает его продуктом худшего качества.

Это случилось с предварительной версией 4?

Есть ли планы сделать System.Text.Json.Serialization.Policies.JsonValueConverterclass public, чтобы разрешить замену классов конвертера из Json.net?

Будет ли System.Text.Json поставляться с полной поддержкой .Net через nuget? Было бы неплохо обеспечить полное взаимодействие, а также использовать преимущества полной инфраструктуры.

System.Text.Json был недавно изменен на создание netstandard2.0 двоичных файлов для доставки OOB; https://github.com/dotnet/corefx/pull/37129 :

Если возможно, вам следует нацелиться на .NET Core 3.0 и получить встроенные API-интерфейсы System.Text.Json. Однако, если вам нужно поддерживать netstandard2.0 (например, если вы разработчик библиотеки), вы можете использовать наш пакет NuGet, совместимый с netstandard2.0.

преимущества полной структуры

Что это снова? 🤔

@khellang

Я бы предпочел nuget с несколькими вариантами, включая полную структуру (4.5 или любой другой приемлемый минимум), стандарт и ядро. Предпочтительно использование коробчатых сборок.

Связанная выше проблема относится к этому пакету, но не поддерживается:

https://www.nuget.org/packages/System.Text.Json

Есть ли текущий поддерживаемый пакет?

Я бы предпочел nuget с несколькими вариантами, включая полную структуру (4.5 или любой другой приемлемый минимум), стандарт и ядро.

Почему ты предпочитаешь это? Если нет необходимости в многоцелевом использовании, т.е. все используемые API являются частью стандарта, гораздо лучше иметь только одну цель 😊

Есть ли текущий поддерживаемый пакет?

Я не думаю, что он еще отправлен. PR был объединен несколько дней назад. Этот пакет раньше был проектом сообщества, который теперь передан MS.

@khellang, это зависит от специфики - я делал общее заявление.

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

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

Я обычно предпочитаю вкусы в коробках: когда я goto definition , я получаю декомпилированные исходники. Если я goto definition в сетевых стандартных библиотеках, я обычно вижу только источники-заглушки, которые вызывают исключения NotImplemented .

преимущества полной структуры

Что это снова? 🤔

Многие приложения используют .NET Framework не потому, что они абсолютно не хотят использовать .NET Core, а потому, что .NET Core не подходит. Я использую .NET Core, когда это возможно; когда мне нужно ориентироваться на версии Windows ниже, чем Windows Server 2012 (минимальная версия .NET Core 3.0), я должен использовать .NET Framework. Хотя я уверен, что это было очень болезненное решение отказаться от поддержки Windows Server 2008 R2 и ниже, это очень болезненное решение для каждой компании, имеющей платные клиенты с серверами, которые они не хотят обновлять / часто в основном воссоздают с нуля. просто чтобы мы могли использовать немного более новый инструмент.

Никто не был бы счастливее меня, если бы я мог отказаться от использования .NET Framework завтра, но даже со всеми возможностями WPF и Windows Forms в .NET Core 3.0 и более поздних версиях Microsoft делает это практически невозможным с помощью своих политик поддержки. Я пытался обсудить это со всеми, кто хотел бы слушать в Microsoft, но, к сожалению, я еще не получил ни одного электронного письма, подтверждающего, что сообщение было доставлено.

@JesperTreetop, не говоря уже об отсутствии поддержки LTS для версий .NET Core, которые стоит использовать на предприятии;) Я надеюсь, что мы получим поддержку LTS в 3.x - как .NET-архитектор моей организации, я буду настаивать на Принятие .NET Core, если мы получим версию 3.x с поддержкой LTS.

@marksmeltzer Вчерашнее сообщение в блоге « Представляем .NET 5» показывает, что .Net Core 3.1 будет LTS, и его выпуск запланирован на ноябрь 2019 года.

Будет ли этот новый сериализатор JSON поддерживать типы F #?

@rliman в настоящее время он не поддерживает Guid или Enum, так что ему предстоит долгий путь. Я согласен с тем, что полная поддержка типов опций F #, аналогичных C # с нулевым значением, должна требоваться ИМХО

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

Нет простого способа «сгладить» эту новую «особенность».

Это MS пытается решить проблему, которую они изначально вызвали. И теперь каждый должен заплатить цену.

С NET Core с самого начала кажется, что универсал немного «шустрый» ... Этот чистый «гибкий» подход, возможно, придется немного замедлить и позволить всем перевести дух.

Похоже, что в ASP.NET Core эти «особенности» (критические изменения) стали новой нормой.

На мой взгляд, ASP.NET Core отчаянно нуждается в переработке процесса архитектурного проектирования. Потому что снова и снова продолжайте делать эти функции «мы исправим это позже».

Я занимаюсь разработкой ASP.NET Core с тех пор, как он был на ранних бета-версиях ... И это большое улучшение по сравнению с .NET.

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

Просто вернитесь и прочтите другие темы ... Кажется, это повторяющаяся тема.

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

Классический .NET может быть не таким мощным, как Core ... Но он очень стабилен и согласован, начиная с версии 2.0.

Только мое мнение.

Привет @suncodefactory!
Я помню некоторое время назад, когда ppl кричал на ms за то, что они не используют библиотеки с открытым исходным кодом, теперь их обвиняют в этом: D
С моей точки зрения, Aspnet / core MVC api были очень стабильными с момента mvc1 / 2! Причина, по которой aspnet был стабильным, начиная с версии 2.0, заключалась в том, что он вообще никогда не менялся / не улучшался 😄.
Честно говоря, если вы используете расширенную функцию библиотеки сериализации, у вас есть возможность переосмыслить ее и, возможно, подойти к проблеме со структурой данных, подходящей для задачи, вместо того, чтобы делать вид, что все сериализаторы поддерживают все языковые функции, я думаю, это неправильная проблема, которую нужно решить, и неправильный способ использования сериализации.
Ясность, обратная совместимость и будущие расширения - вот что движет моими сериализуемыми dtos, очень разные компромиссы, используемые в общих объектах бизнес-логики (они частные, имеют много функций и т. Д.)

Мы можем перенести микросервисы с сетевой платформы на Linux (сетевое ядро) практически без каких-либо усилий со стороны производственных групп. Я не понимаю, о чем вы, ребята. Microsoft делает огромную работу по ускорению внедрения подобных изменений, которые давно назрели.

Привет @suncodefactory!
Я помню некоторое время назад, когда ppl кричал на ms за то, что они не используют библиотеки с открытым исходным кодом, теперь их обвиняют в этом: D

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

Также я никогда не говорил о классическом asp.net ... Я говорил о .NET Framework 2.0. И причина, по которой он был стабильным, заключалась не в том, что не было никаких улучшений, как вы ошибочно утверждаете (поскольку ядро ​​.net основано на .NET 4.6.1). Причина заключалась в том, что он был хорошо спланирован и спроектирован.

Что касается того, насколько хорошо ядро ​​aspnet по сравнению с классическим asp.net mvc, которое не имеет ничего общего с этим конкретным потоком.

Эта ветка посвящена критическому изменению, которое MS собирается отправить еще раз, не задумываясь над этим.

Мы можем перенести микросервисы с сетевой платформы на Linux (сетевое ядро) практически без каких-либо усилий со стороны производственных групп. Я не понимаю, о чем вы, ребята. Microsoft делает огромную работу по ускорению внедрения подобных изменений, которые давно назрели.

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

И сказать, что основная команда asp.net проделала большую работу по доставке изменений, просто неправда.

Я занимаюсь разработкой ядра asp.net со времен беты 3, и я почти уверен, что процесс архитектурного проектирования отсутствует.

Что касается того, насколько хорошо ядро ​​asp.net по сравнению с классическим ... У меня нет возражений, так как я также считаю, что оно лучше, чем классическое.

Но то, что ядро ​​asp.net лучше классического, не означает, что они отлично справляются с архитектурным проектированием. Это совершенно разные темы.

Можем ли мы ограничить это обсуждение функциональностью JSON в .NET Core 3, пожалуйста?

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

Значит, никаких улучшений делать не надо? Почему вы вообще программист, если не хотите, чтобы программное обеспечение развивалось, росло и улучшалось?

@suncodefactory

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

Ах, да ладно, вы говорите, что «критическое изменение» означает, что вы должны отказаться от своего проекта и начать с нуля.

Сколько критических изменений вы можете сосчитать, которые были в ASP.NET Core 2.x / 3.0, которые требовали более

• Ссылка на другой пакет
• Использование другого пространства имен
• Изменение более 5 строк кода
• Удаление 1-2 строк кода (т.е. свойств из классов параметров)

??

@suncodefactory

Эта ветка посвящена критическому изменению, которое MS собирается отправить еще раз, не задумываясь над этим.

Как это на самом деле _безопасное_ изменение? Новые API-интерфейсы JSON - это совершенно новый набор API-интерфейсов, представленных в .NET Core, которые не удаляют и не нарушают какие-либо существующие данные. Да, в конечном итоге вы увидите, что вещи и библиотеки переключаются на него, поскольку он предлагает различные возможности оптимизации, но вы не обязаны применять это к своему коду.

Говоря, в частности, об ASP.NET Core, хотя _ «это не имеет ничего общего с этим конкретным потоком» _, у вас есть выбор продолжать использовать Newtonsoft.Json, если вы зависите от некоторых из его более продвинутых функций. Да, вам придется изменить некоторый код для этого, чтобы он заработал, но я не считаю, что это действительно ломает, учитывая, что вам нужно сделать это только в том случае, если вы действительно хотите перейти на новую версию. Теперь это хорошо: у вас есть больше вариантов.

Если вам это не нравится по какой-либо причине, не стесняйтесь придерживаться .NET Framework, который является известным, стабильным и фиксированным набором функций. Это будет оставаться там довольно долго, так что вы можете полностью на это рассчитывать. Но, пожалуйста, прекратите использовать эту ветку для распространения своей анти-новаторской повестки дня, когда _ «это не имеет ничего общего с этой конкретной веткой» _.

Два вопроса от пользователя EF Core.

1. Будет ли System.Text.Json поддерживать циклические ссылки? Циклические ссылки могут встречаться в данных EF Core, где есть двусторонние навигационные ссылки между классами. Json.NET обрабатывает это с такими настройками, как
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. С появлением классов в стиле DDD с частными сеттерами и частными конструкторами можно System.Text.Json десериализовать эти типы классов?

@JonPSmith ИМО, это не имеет значения. Никогда не следует сериализовать сущность напрямую. Вам следует сериализовать проекцию. Это позволяет избежать циклических ссылок и не раскрывает все данные, особенно когда вы добавляете к объекту дополнительные свойства, которые могут оказаться конфиденциальными.

@JonPSmith : Имхо, оба варианта использования недействительны как с точки зрения передовой практики, так и с точки зрения DDD.

1. Я никогда не встречал передового опыта, который рекомендовал бы десериализацию сущностей напрямую (за исключением самых простых учебных примеров). Циркулярные ссылки всегда имеют свою цену. Это требует отслеживания уже обработанных объектов, это означает: выделение памяти и дополнительные циклы ЦП. Но одна из почтовых целей новой библиотеки JSON - точно избежать выделения памяти.
2. Это также недопустимо, поскольку вы никогда не сериализуетесь в модель домена, особенно когда вы получаете данные через веб-запрос, такой как вызов WebApi. В DDD вы всегда должны работать с событиями / командами, отправлять команду в свое веб-приложение, получать (и обезвоживать) объект из репозитория (через сопоставление ORM или EventSourcing), применять команду и сохранять ее.

Кроме того, новый JSON API предназначен для высокопроизводительных сценариев. Для всего остального, где вам нужен богатый набор функций, вы (и должны) по-прежнему использовать JSON.NET или что-то еще, что соответствует вашим потребностям.

@suncodefactory Это противоположность

Например, посмотрите на Microsoft.Extensions.Configuration.Json 2.2.0 - он зависит от Newtonsoft.Json 11.0.2. Это пакет конфигурации; не имеет ничего общего с обработкой HTTP-запросов или ASP.NET Core MVC. Или посмотрите Microsoft.IdentityModel.Protocols.OpenIdConnect , который использует его для обработки веб-токенов JSON; это горячий путь, который требует максимальной производительности. JSON.NET не является медленной библиотекой по любым стандартам, но она обеспечивает баланс между производительностью, функциональностью и поддержкой огромного количества пользовательских сценариев. В новой библиотеке JSON от Microsoft этого делать не нужно, потому что JSON.NET существует. Таким образом, он может сосредоточиться на работе с абсолютными основами с максимальной производительностью.

У .NET всегда было собственное решение для сериализации JSON в System.Runtime.Serialization.Json , но в высокопроизводительном мире .NET Core оно не очень хорошее. Я бы точно не хотел, чтобы его вызывали для проверки учетных данных при каждом входящем запросе. Мы очень приветствуем новую библиотеку JSON с современной обработкой данных UTF-8 и минимальными выделениями.

Вы по-прежнему сможете ссылаться на Newtonsoft.Json в своем приложении и продолжать использовать его в качестве конвейера десериализации / сериализации для данных запроса / ответа, как и раньше. И отныне вы сможете делать это, не беспокоясь о том, от какой версии зависит Core framework. Это победа для всех.

Спасибо @ phillip-haydon и @TsengSR за ваши мысли. Я спрашивал, будут ли поддерживаться эти функции, а вы ответили, что нет, что вы понимаете и принимаете. Я буду продолжать использовать Json.NET в случае, когда мне нужно сериализовать / десериализовать классы EF Core.

КСТАТИ. У меня есть веская причина для сериализации / десериализации классов сущностей EF Core в стилях DDD. У меня есть библиотека, которая содержит функцию, которую я называю Seed from Production, которая позволяет разработчикам делать снимок данных из производственной базы данных, анонимизировать любые личные данные, а затем заполнять новую базу данных снимком.

Мне нужна эта функция для одного из моих клиентов, и вместо того, чтобы писать только для них, я встроил ее в свою библиотеку с открытым исходным кодом EfCore.TestSupport, чтобы другие могли ее использовать (и моему клиенту не пришлось платить мне за это).

Планируется ли поддержка [DataContract] , [DataMember] и друзей?

Сегодня это способ определить, как типы должны сериализоваться / десериализоваться (например, имя поля) таким образом, чтобы не привнести зависимость к какой-либо библиотеке сериализации в проект, использующий ее.

Текущий JsonNamingPolicy принимает только строку, поэтому нет возможности проверить атрибуты члена.

Привет.
Мы просто попытались переключить наши микросервисы на DotNet core 3 preview 6, и мы не можем десериализовать наши неизменяемые ссылочные типы: класс с неизменяемыми свойствами (без сеттеров) и только один конструктор для установки всех свойств. Json.net правильно обрабатывает эти классы.
Это проблема необходимости API System.Text.Json или это план по его поддержке?
Спасибо за ваши ответы

@agjini См. https://github.com/dotnet/corefx/issues/38569

Спасибо @khellang.
Поддержка действительно запланирована, но не для версии 3.0.
Кажется, можно продолжить использование Json.net с ядром DotNet 3, но я не знаю, как это сделать (недостаточно добавить ссылку на пакет). Есть ли способ сделать это?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

Спасибо за помощь ребята.
Оно работает !
Я пропустил руководство по миграции, где все объясняется:

https://docs.microsoft.com/fr-fr/aspnet/core/migration/22-to-30?view=aspnetcore-2.2&tabs=visual-studio

IMO json.net наполовину запечен, и сделать его по умолчанию (т.е. для signalr), который нарушает существующий код, было преждевременным.

С другой стороны, переход с .NET Core 2.2 на 3.0 является обновлением основной версии, и даже если команда .NET Core не строго соблюдает семантическое управление версиями, я бы ожидал, что при обновлении с одной версии на другую без явных изменений что-то сломается. (например, явное добавление библиотеки Newtonsoft в конвейер)

Закрытие, учитывая, что это объявление, а не проблема

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

Я знаю, что это было сказано раньше, но я также хотел бы добавить свое желание.

Было бы здорово, если бы у нас были неизменяемые объекты. Я знаю, что это возможно, добавив Json.NET в MVC-Pipeline, но в моем случае все мои тесты терпят неудачу, поскольку я использую ReadAsAsync<> который теперь реализован где-то в одноранговой зависимости Microsoft.AspNet.WebApi.Client и это зависит от System.Text.Json

Мы предоставляем клиентам библиотеку классов .NET Standard, чтобы они могли использовать нашу библиотеку для работы на любой платформе, поддерживающей .NET Standard. Нам нужно использовать System.Text.Json в нашей библиотеке классов. Каковы будут планы по поддержке System.Text.Json в .NET Standard?

@alsami

Было бы здорово, если бы у нас были неизменяемые объекты.

Вам нужна только возможность предотвратить его изменение другими или вам также нужна возможность создавать новые экземпляры с умно заменяемыми частями (например, неизменяемые коллекции и Roslyn)? Если вам нужно первое, мы подготовили для вас новые JsonDocument DOM API.

@ mwoo-o

Каковы будут планы по поддержке System.Text.Json в .NET Standard?

Он доступен как пакет NuGet для .NET Standard 2.0: System.Text.Json .

@terrajobst

Спасибо. Когда этот System.Text.Json будет включен в стандартный пакет SDK для .NET?
Будет ли стандарт .NET 3.0 (или некоторые другие более поздние версии) включать пакет System.Text.Json? Произойдет ли это в производственной версии .NET Core 3.0 SDK?

@terrajobst

Есть ли планы сделать так, чтобы метод Deserialize работал с PipeReader? Или добавьте метод Patch, который можно использовать в сценариях потоковой передачи, когда у нас нет всех данных, когда мы начинаем десериализацию.

Вот упрощенная версия предлагаемого API:

private async ValueTask<T> Deserialize<T>(PipeReader reader, CancellationToken cancellationToken) 
    where T: new()
{
    T model = new T();
    while (!cancellationToken.IsCancellationRequested)
    {
        ReadResult readResult = await reader.ReadAsync(cancellationToken);
        ReadOnlySequence<byte> buffer = readResult.Buffer;

        if (readResult.IsCanceled) break;
        if (buffer.IsEmpty && readResult.IsCompleted) break;

        SequencePosition consumed = JsonSerializer.Patch(model, buffer, readResult.IsCompleted);
        reader.AdvanceTo(consumed, buffer.End);               
    }

    return model;
}

public SequencePosition Patch<T>(T model, ReadOnlySequence<byte> jsonData, bool isFinalBlock, JsonSerializerOptions options = null)
{
      ...            
}

@terrajobst

способность препятствовать тому, чтобы другие видоизменяли его

Только это в настоящее время. Действительно только для «объектов передачи данных». Отличные новости!

@ mwoo-o

Спасибо. Когда этот System.Text.Json будет включен в стандартный пакет SDK для .NET?
Будет ли стандарт .NET 3.0 (или некоторые другие более поздние версии) включать пакет System.Text.Json? Произойдет ли это в производственной версии .NET Core 3.0 SDK?

Нет стандартного пакета SDK для .NET. .NET Standard - это поверхность API, доступная на всех поддерживаемых платформах. Вы можете отправить System.Text.Json в любое приложение, которое работает на поддерживаемых платформах, поддерживаемых стандартом .NET, см. Поддержка реализации .NET .

@TsengSR

Нет стандартного пакета SDK для .NET. .NET Standard - это поверхность API, доступная на всех поддерживаемых платформах.

Что ж, есть тип проекта, который позволяет использовать API. Я думаю, @ mwoo-o спрашивает, планируем ли мы добавить System.Text.Json в .NET Standard. Ответ - нет. Хорошо, теперь мы планируем оставить это пакетом NuGet.

Это ужасно. Слишком мало функций, которые можно применить в проекте.