Runtime: Die Zukunft von JSON in .NET Core 3.0

Das ist toll. Ich bin alles für schnelleres und weniger zuordnendes Json-Parsing.

Wird es eine Diskussion über die Funktionen von json.net geben, die die neue json-API unterstützt? Wenn ja, denke ich, dass die beiden wichtigsten Funktionen das Umbenennen / Groß-/Kleinschreibung von Eigenschaften und das Ignorieren von Nulleigenschaften sind.

Wird es eine Diskussion über die Funktionen von json.net geben, die die neue json-API unterstützt?

Jawohl. Wir haben uns schon früh Gedanken gemacht, dass wir zu CoreFx migrieren werden. Es wird ein Feature sein, das wie gewohnt im Freien entworfen und gebaut wird. Darüber hinaus habe ich Autoren vieler beliebter JSON-Bibliotheken kontaktiert und sie eingeladen, frühe Entwürfe dieser Ankündigung zu überprüfen. Ich hoffe, dass wir zusammenarbeiten können, um eine solide JSON-Komponente für die Plattform zu erstellen und gleichzeitig das Ökosystem darüber (z. B. ASP.NET Core) steckbar zu halten, um andere zu ermöglichen. Letztendlich haben verschiedene Verbraucher unterschiedliche Ziele und die Möglichkeit, eine andere Bibliothek anzuschließen, bedeutet, dass Sie bei der Auswahl der Komponente mit dem besten Preis-Leistungs-Verhältnis für Ihre App maximale Flexibilität erhalten.

Hallo @terrajobst. Wird das neue JSON als Netstandard-API-Oberfläche erscheinen oder vorerst nur in Core integriert?

Hallo @terrajobst. Wird das neue JSON als Netstandard-API-Oberfläche erscheinen oder vorerst nur in Core integriert?

Ja, die Frage ist nur, welchen Auslösezug er erwischen kann. 2.1 könnte zu früh sein.

Daher ist geplant, dass die in das Framework integrierten JSON-Parsing-Bits verfügbar sind, wenn v3.0 auf RTM umgestellt wird, oder wird nur die Integration von Apis in ASP.NET Core abgeschlossen (mit nur einer Implementierung - JSON.NET), die zu einem Zeitpunkt austauschbar sein wird späteren Zeitpunkt?

Der Plan für 3.0 sieht wie folgt aus:

1. Integrierte leistungsstarke JSON-APIs. Low-Level-Reader/Writer, ein Stream basierter Reader/Writer und ein Serializer.
2. ASP.NET Core ist in Bezug auf die JSON-Komponente steckbar.

Es gibt eine offene Frage, was die Vorlagen für ASP.NET in 3.0 verwenden werden. Abhängig von der Wiedergabetreue, die wir mit 3.0 bereitstellen können, müssen sie möglicherweise das Json.NET-Integrationspaket einbinden. Das Ziel ist jedoch, genügend Wiedergabetreue und Parität zu liefern, um standardmäßig nur von den integrierten abzuhängen.

Danke - das hilft bei der Klärung. 👍

Und noch ein paar zusätzliche Fragen!

Wenn ein Integrationspaket verwendet wird, wird es in der gesamten ASP.NET Core-Pipeline oder nur an einigen Stellen verwendet?
Ich gehe davon aus, dass Kestrel immer die internen Leser/Schreiber verwendet.

Wäre die Ergonomie der API:

• Geben Sie eine Integration nur an, wenn Sie den integrierten Funktionsumfang erweitern möchten.
• Liefern Sie immer ein Integrationspaket, aber eines wäre eingebaut, das die Low-Level-Lese-/Schreibgeräte in die übergeordnete Funktionalität integriert.

Angenommen, dieser neue Parser wird für all die eingebauten JSON-Sachen wie appSettings.json , könnte ich dann eine frühzeitige Anfrage zur Unterstützung von Kommentaren stellen?

Vielen Dank.

Das sind tolle Neuigkeiten! Kurze Frage: Von welchen Paketen wird diese Bibliothek abhängen?

Warum ein Rad neu erfinden, das von Serienkunden getestet wird? Wenn es ein Problem mit Json.Net gibt, senden Sie einfach eine PR, da es sich um Open Source handelt.

Ich nehme an, das Problem mit Json.NET ist, dass es nicht im Besitz von Microsoft ist und daher ersetzt werden muss. Oh, aber es gibt den bereits in System.Runtime.Serialization, genannt DataContractJsonSerializer. Können Sie das nutzen oder macht es einfach so viel Spaß, neue APIs zu programmieren, DIY, dass es nicht vermieden werden kann?

Der Grund, warum ich damit nicht sehr zufrieden bin, ist, dass Json.Net bereits Randfälle wie zB F# Discriminated Unions unterstützt. Nicht besonders gut, aber auf einem Niveau, mit dem Entwickler leben können. Stattdessen vergessen neue APIs normalerweise alles andere als den Anwendungsfall einer ASP.NET-Website.

@markrendle Es gibt eine Opt-in-Einstellung für JsonReader (in Arbeit), um Kommentare zuzulassen. Das Konfigurationssystem wird diese Einstellung wahrscheinlich standardmäßig aktivieren.

@Thorium Hast du das OP tatsächlich gelesen? Es erklärt, warum nicht JSON.NET und dass JSON.NET weiterhin offiziell mit einem Add-In-Paket unterstützt wird.

@JamesNK 😄

@Thorium Json.NET wird nicht verschwinden. Du verlierst nichts. Dies ist eine weitere Option für einfache und leistungsstarke Szenarien.

@Thorium Json.NET wird nicht verschwinden. Du verlierst nichts. Dies ist eine weitere Option für einfache und leistungsstarke Szenarien.

Wie wird der Json generiert, um abwärtskompatibel zu sein?

Zum Beispiel verwende ich SignalR, das Json.NET im Hintergrund verwendet. Werden meine F#-Diskriminierten Unions nun zu ähnlichen Strukturen serialisiert, damit ich keine Probleme mit dem neuen Azure Signalr Service (Backplane) bekämpfe, der Laufzeitausnahmen auslöst, weil die Strukturen anders als die aktuelle SignalR-Bibliothek meines Servers serialisiert werden?

Ich hoffe, dass andere die neuen APIs schnell aufnehmen. Schau dich an,

Planen Sie, eine Klasse wie JObject einzubinden und dynamische Unterstützung zu bieten, oder ist dies für diese Funktion nicht möglich?

Ich empfehle einen Blick in eine dieser Libs:

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

Dies könnte eine wirklich gute Möglichkeit sein, Inspirationen zu bekommen.

Wird DataContractJsonSerializer diesen neuen Leser/Schreiber intern verwenden?

Ich habe Autoren vieler beliebter JSON-Bibliotheken kontaktiert und sie eingeladen, frühe Entwürfe dieser Ankündigung zu überprüfen. Ich hoffe, dass wir zusammenarbeiten können, um eine solide JSON-Komponente für die Plattform zu erstellen und gleichzeitig das Ökosystem darüber (z. B. ASP.NET Core) steckbar zu halten, um andere zu ermöglichen.

Gibt es einen Grund, warum die zweitbeliebteste JSON-Bibliothek nach JSON.NET - ServiceStack.Text, die bereits umgestaltet wurde, um auf Span aufzubauen?APIs wurde ausgeschlossen? ServiceStack.Text-Serializer werden verwendet, um ServiceStack zu unterstützen, das eines der beliebtesten "alternativen .NET Core-kompatiblen Web Frameworks" ist, das die Ausführung auf mehr Plattformen in .NET unterstützt . Ich bin neugierig, auf welches "Ökosystem" Sie sich beziehen und mit dem Sie hoffen, hier "zusammenzuarbeiten"? Mich würde natürlich interessieren, wie kompatibel diese "steckbaren" APIs am Ende sind oder ob dies ein weiterer Bereich ist, in dem die Einführung und Integration neuer MS-Bibliotheken das Ökosystem, das sie ersetzt, zerstört.

Es kann sich lohnen, die vom MIT lizenzierte Hochleistungsversion https://github.com/neuecc/Utf8Json zu überprüfen

Dies ist definitiv das, was wir brauchen ... mein Vorschlag für den Hauptklassennamen, verwenden Sie einfach " Json ".

@terrajobst Ich habe mich gefragt, wann das passieren würde ...

Ich habe mich immer gefragt, warum JSON.Net als direkte Abhängigkeit und nicht als Abstraktion hinzugefügt wurde (auch wenn man bedenkt, dass es das De-facto-JSON-Paket für das .Net-Ökosystem ist).

Ich denke jedoch, dass das Hinzufügen einer Abstraktion für JSON-only irgendwie ein Sprung in die Beine ist. Ich denke, eine _serializer_-Abstraktion wie in Orleans IExternalSerializer in Form von Microsoft.Extensions.Serialization oder etwas wäre effektiver ...

Gibt es einen bestimmten Grund, warum make nur JSON ist? Ich sehe andere Fälle, in denen Leute andere Arten von Serializern anschließen können ...

@galvesribeiro Etwas wie IOutputFormatter / IInputFormatter ?

@yaakov-h war sich dessen nicht bewusst ... Waren sie es?

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

Okay... macht jetzt Sinn. Wo also kommen diese _neuen_ JSON-only-Abstraktionen ins Spiel?

Die Entscheidung, dieses Unternehmen zu starten, ist auch ein Beweis für die Ineffizienz von System.String (UTF-16 String).
Ich denke, dass die neuen JSON-Hooks, die das gesamte Json-Handling zwischen asp.net und einer Json-Bibliothek abstrahieren, deutlich besser aussehen würden, wenn Sie zuerst einen utf-8-String-BaseType erstellen.
--> Vielleicht erstellen Sie einen System.Utf8String

Ja ... ich erinnere mich , dass utf8 Strings zu verwenden 😄

@jges42 @galvesribeiro Der Vorschlag zum Hinzufügen von Utf8String lautet https://github.com/dotnet/corefx/issues/30503. Es scheint auch für .Net Core 3.0 geplant zu sein.

Werden diese neuen JSON-APIs dedizierte Codepfade für Utf8String und char / string , oder beinhaltet die Optimierung das Umdrehen des Status Quo, sodass alles, was nicht UTF-8 ist, muss stattdessen transkodiert werden? (Dies ist nicht unbedingt mit großen Kosten verbunden, da fast nichts das native UCS-2 UTF-16 von string und noch angepasst / berücksichtigt werden muss. Ich versuche nur, eine Vorstellung davon zu bekommen API-Oberfläche. Dies zu tun, um Kestrel effizienter zu machen, ist vernünftig; ich hoffe nur, dass das Design mehr Clients als Kestrel berücksichtigt.)

@galversribeiro
Eigentlich denke ich, dass Sie einen guten Punkt ansprechen. Ich denke, ein effizientes Serialisierungs-Framework und ein effizienter Json-Decoder/Encoder zu erstellen, sind zwei Arten von Problemen. Ich weiß, dass es einige Möglichkeiten gibt, eine Struktur als serialisierbar zu markieren, aber ich habe sie noch nie für eine Json-Serialisierung verwendet.

Das Serde-Projekt von Rust hat eigentlich ein gutes Konzept, indem es das Problem in 2 Probleme aufteilt:

1. Serialisieren/Deserialisieren (Eigenschaften ähnlich wie bei Schnittstellen in C#), was bedeutet, dass jeder Typ, der von dieser Schnittstelle erbt, serialisiert/deserialisiert werden kann
2. Serializer/Deserializer ist die formatspezifische Implementierung.

Ein Typ kann entweder Serialize/Deserialize von Hand implementieren oder durch ein Makro (das als eine Art Compiler-Plugin angesehen werden könnte), das den Code generiert, der für die Implementierung dieser Traits erforderlich ist. Wenn ein Typ einen untergeordneten Typ enthält, der diese Eigenschaften nicht implementiert, wird er sogar zur Kompilierzeit warnen. Es ist insgesamt ein nettes Konzept, weil es bedeutet, dass Sie einfach einige Datenobjekte schreiben und es für jedes unterstützte Format (de)serialisieren können. Das Schreiben eines Formats ist auf diese Weise viel einfacher.

Ich glaube nicht, dass die Wege von Serde alle für C# funktionieren, weil es keine typspezifischen Attribute bietet, die für einige Datenstrukturen wichtig sein könnten. Dafür muss also einiges getan werden. Auch die Berücksichtigung von AoT-Kompilierung wird für einige Projekte sehr wichtig sein (WASM). Es sollte auch gut damit funktionieren.

Hier ist ein Link zu den Serde-Dokumenten, um es klarer zu machen (Klicken Sie auf die unteren 4 Merkmale, um das Konzept zu sehen):
https://docs.serde.rs

@mythz Die Lizenz von ServiceStack.Text ist AGPL mit einigen FOSS-Ausnahmen - sie würde wahrscheinlich verhindern, dass

@poizan42 ServiceStack.Text ist doppelt lizenziert mit sowohl OSS- als auch in kommerziellen Closed-Source-Projekten verwendet werden können. Aber die Quellcode-Lizenzen sind irrelevant, da MS ihre eigene Implementierung entwickelt.

Die Behauptung war, dass MS mit dem "Ökosystem" zusammenarbeitete, um "steckbare" JSON-Serializer-APIs zu entwickeln - wenn ServiceStack, das seit fast einem Jahrzehnt in aktiver Entwicklung war, eine der wenigen unabhängigen .NET-Software-Suiten ist, die es geschafft haben, ihre Funktion aufrechtzuerhalten eigene unabhängige, gesunde Community außerhalb von MS innerhalb ihrer Lebensdauer, die den zweitbeliebtesten JSON-Serializer nach JSON.NET und das scheinbar zweitbeliebteste aktiv entwickelte Web Framework (außerhalb von MS) verwaltet, das auf mehr Plattformen läuft als jedes MS Web-Framework wird nicht als Teil des "Ökosystems" angesehen, das in erster Linie von diesen Veränderungen betroffen ist. Ich bin gespannt, auf welches "Ökosystem" sie sich beziehen und warum wir ausgeschlossen werden und wie viele andere ausgeschlossen werden, weil sie es sind nicht als Teil des "Ökosystems" angesehen.

Ich verstehe diesen ganzen Ärger nicht. Asp.net hat Sie gezwungen, eine bestimmte Version von json.net zu verwenden. Sie ändern es, damit Sie den gewünschten JSON-Parser auswählen können (oder mischen), und es gibt einen Standard-OOB. ServiceStack sollte sich über diese Änderung freuen und diese Entwicklung beobachten und Feedback geben, anstatt nur zu jammern, wie sie übersehen wurde, was selten ein effektiver Weg ist, um einen guten Gemeinschaftsgeist zu fördern. Ich kenne viele der .net-Teammitglieder persönlich und bin überzeugt, dass sie keine Bosheit beabsichtigten. Sie alle sind große Befürworter von OSS und Community-Arbeit.
Persönlich wäre jede von der GPL abgeleitete Lizenz für mich ein großes automatisches Nein. Apache oder MIT für mich und meine Kunden oder wir machen weiter. Keine mysteriösen Doppellizenzen.

Asp.net hat Sie gezwungen, eine bestimmte Version von json.net zu verwenden

Nö. Wie so?

Ich verstehe diesen ganzen Ärger nicht.

Abgeordnet!

Ich persönlich bin froh, dass wir endlich den Serializer unserer Wahl verwenden können, ohne JSON.Net herunterladen zu müssen, nur um es nicht zu verwenden, aber dennoch ausliefern zu müssen, da ASP.Net einen harten Verweis auf die Bibliothek hat.

(Schamloser Stecker: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

Ich verstehe diesen ganzen Ärger nicht.

Weil Sie meine Kommentare entweder nicht gelesen oder verstanden haben. Versuchen Sie, direkt auf meine Kommentare zu antworten (dh verwenden Sie die Zitatfunktion), anstatt Ihre eigene Erzählung zu erfinden.

Sie ändern es, damit Sie den gewünschten JSON-Parser auswählen können (oder mischen).

Wie ein magischer "Mix" wählen sie automatisch die optimalsten API- und Plugability-Optionen, die vorhandene .NET-Serializer direkt ein- und ausstecken und in ihre internen Anpassungsoptionen mischen können, wobei das Drahtformat genau das ist gleich und alles wird einfach über alle Serializer hinweg funktionieren? In diesem Fall haben Sie Recht, es sind keine Zusammenarbeits- oder Integrationstests erforderlich, bevor die APIs verfestigt sind. Oder vielleicht sind Serializer-Implementierungen nuancierter mit verschiedenen Unterschieden und Meinungen und alles wird nicht nur funktionieren, nicht alle Anpassungsoptionen werden genau implementiert, das Wire-Format wird nicht dasselbe sein und es wird nicht möglich sein, es zu erreichen perfektes Zusammenspiel zwischen verschiedenen Implementierungen. Die "Plugability", die Sie beschönigen, macht einen großen Unterschied, der bestimmen kann, wie viel Umschreiben wir vornehmen müssen und ob es möglich ist, bestehende und diese neue Implementierung zu unterstützen oder nicht.

ServiceStack sollte sich über diese Änderung freuen und diese Entwicklung beobachten und Feedback geben,

Wozu wir keine Gelegenheit hatten (oder immer noch wissen, wie es geht), aber danke, dass Sie mich wissen lassen, wie ich mich fühlen soll. Ich würde es vorziehen, die Funktionalität, Interoperabilität und Kompatibilität der Bibliothek zu bewerten, bevor ich die Stärke jeder einzelnen bewerten kann. Vielleicht ist es großartig und es wird einfach sein, beide Implementierungen zu unterstützen, aber aus Erfahrung ist die Zusammenarbeit mit verschiedenen Serialisierungsimplementierungen mit Inkompatibilitäten und Eckfällen und der Abhängigkeit von verschiedenen serialisierungsspezifischen Implementierungen und Funktionen behaftet. Meine Vorhersage ist, dass die Interop zwischen JSON.NET und dem Standard-Impl großartig sein wird, da dies ihr Designziel ist und was getestet wird, aber andere Serializer werden nicht so viel Glück haben.

anstatt nur darüber zu jammern, dass es übersehen wurde, was selten ein effektiver Weg ist, um einen guten Gemeinschaftsgeist zu fördern.

Ich stelle ihre Behauptung in Frage, dass sie dies in Zusammenarbeit mit dem "Ökosystem" entwickelt haben hier (ich habe Mühe, mich an eine Zeit zu erinnern, in der das Bündeln eines Standardwerts dem Ökosystem jemals geholfen hat). Aber unabhängig davon müssen wir eine nahtlose Integration mit allem entwickeln, was sie veröffentlichen, auf das ich Zugriff und Eingaben haben möchte, bevor die APIs eingefroren werden. Aber das ist in Ordnung. Ich erwarte, dass Sie sich nicht darum kümmern, wie sich dies auf die vorhandenen Frameworks/Bibliotheken auswirkt, die bestehende und zukünftige Implementierungen unterstützen müssen. Sie sind wahrscheinlich nur besorgt, ob JSON.NET unterstützt bleibt oder nicht, weil das alles ist, was Sie betrifft, aber Versuchen Sie, an Ihren Annahmen festzuhalten, und teilen Sie uns mit, wie wir uns dabei fühlen sollen, störende Veränderungen wie diese zu absorbieren.

Es fällt mir schwer, mich an eine Zeit zu erinnern, in der das Bündeln eines Standardwerts dem Ökosystem jemals geholfen hat

Ach komm schon!

(Im Rest stimme ich deiner Meinung größtenteils zu)

@mythz Ich bin überrascht, dass dies Probleme verursacht, da wir heute eine weitere JSON-Bibliothek von Drittanbietern in das Framework bündeln. Es gibt nur eine Handvoll Orte, an denen wir JSON backen, und die meisten von ihnen haben ein Anbietermodell, das Benutzer vernünftigerweise ersetzen würden (wie MVC-Formatierer).

Meine Vorhersage ist, dass die Interop zwischen JSON.NET und dem Standard-Impl großartig sein wird, da dies ihr Designziel ist und was getestet wird, aber andere Serializer werden nicht so viel Glück haben.

Ich kann Ihnen bereits sagen, dass das, was wir ausliefern werden, nicht die Bandbreite an Funktionen unterstützt, die JSON.NET unterstützt. Das ist also bereits nicht wahr und tatsächlich, wir erwarten, dass es in einigen Fällen (aus Gründen der Leistung und des Umfangs) weniger leistungsfähig ist.

Die Pluggability ist heute meist schon vorhanden und wir haben überall standardmäßige JSON.NET-Implementierungen. Dies ändert nur diesen Standard, um stattdessen der neue JSON-Serializer zu sein ...

@abatishchev

Ich kann mich wirklich nicht daran erinnern, wann das Einbetten oder Übernehmen einer Standardimplementierung in ihr Basisframework (oder ihre Projekte) dem bestehenden umgebenden Ökosystem zugute kam? Jedes Mal, wenn ich es gebündelt gesehen habe, z. B. NuGet, MVC, ORMs, Unit Testing, Web API, etc. hatte es immer nur eine nachteilige Wirkung, da es effektiv den Sauerstoff und die Motivation für den Wettbewerb in diesem Bereich verbraucht.

Es gibt Zeiten, in denen konkurrierende Bibliotheken wie ASP.NET Ajax nicht mithalten konnten, wenn sie es aufgegeben und jQuery übernommen haben, aber ich erinnere mich an keine Zeit, in der es jemals geholfen hat? Hinweis: Dies ist nur meine Beobachtung aus .NET nach mehreren Jahren. Vielleicht gibt es Beispiele und ich wäre neugierig auf einige? aber aus meiner Sicht wirken sich die Auswirkungen der MS-Standardeinstellungen nachteilig auf das vorhandene Ökosystem der Funktionalität aus, das es ersetzt.

Die Vorteile von

Aber lassen Sie uns nicht überschwemmen und beim Thema bleiben. Danke schön!

@davidfowl Dies ändert nur diesen Standard, um stattdessen der neue JSON-Serializer zu sein ...

Ich möchte vorschlagen, dass es keinen Standard-Serializer gibt und dass eine Implementierung heruntergeladen werden muss. Wenn es einen Standard geben muss , wird er in das Framework oder in eine separate Bibliothek eingebrannt (wie es derzeit der Fall ist)?

Ich möchte vorschlagen, dass es keinen Standard-Serializer gibt und dass eine Implementierung heruntergeladen werden muss. Wenn es einen Standard geben muss, wird er in das Framework oder in eine separate Bibliothek eingebrannt (wie es derzeit der Fall ist)?

Das ist unvernünftig, da die Erfahrung unterdurchschnittlich sein wird. Jede moderne Plattform hat JSON integriert.

@davidfowl Verursacht abschätzen , die es verursachen wird. Wie viel Aufwand wird es erfordern, um es nahtlos zu unterstützen, werden wir in der Lage sein, Anpassungen auf das neue Impl anzuwenden, um unser bestehendes Verhalten zu unterstützen, werden wir in der Lage sein, das neue Anpassungsmodell und die neuen APIs zu unterstützen, können wir unseren Serializer entsprechend anpassen? Das Standardkonfigurations-/Drahtformat wird die neuen APIs sowohl .NET Core als auch .NET Framework unterstützen können. NET Core-Typen, die uns daran hindern, weiterhin sowohl .NET Core als auch .NET Framework zu unterstützen.

Ich kann Ihnen bereits sagen, dass das, was wir ausliefern werden, nicht die Bandbreite an Funktionen unterstützt, die JSON.NET unterstützt. Das ist also bereits nicht wahr und tatsächlich, wir erwarten, dass es in einigen Fällen (aus Gründen der Leistung und des Umfangs) weniger leistungsfähig ist.

Ich erwarte immer nur, dass es eine Teilmenge der JSON.NET-Funktionen unterstützt, zB wird JSON.NET das Standard-Wire-Format unterstützen? (Ich gehe davon aus, ja). Wird das neue impl nach Möglichkeit JSON.NET-Serialisierungsformate übernehmen (auch unter der Annahme, dass ja).

Wie viel Aufwand ist erforderlich, um es nahtlos zu unterstützen, werden wir in der Lage sein, Anpassungen auf das neue Impl anzuwenden, um unser bestehendes Verhalten zu unterstützen, werden wir in der Lage sein, das neue Anpassungsmodell und die neuen APIs zu unterstützen, können wir unseren Serializer entsprechend anpassen? das Standardkonfigurations-/Drahtformat werden die neuen APIs sowohl .NET Core als auch .NET Framework unterstützen können.

@mythz Ich

@mythz Die einzige wirkliche Sorge, die ich für Servicestack sehe, wäre, wenn diese neue API nicht auf .net Framework Classic unterstützt wird. Auf diese Weise kann Servicestack nicht sowohl .net Core als auch .net Classic als Kundenpakete unterstützen abhängig von diesen Bibliotheken sind im .net Framework full nicht verfügbar. Ist das Ihr Anliegen? Ich frage, weil Ihr Anliegen als konkretes Beispiel nicht klar ist.

Auch dies ist ein Vorschlag in der Anfangsphase und das Ziel, das er erreichen möchte, sieht ziemlich vielversprechend aus. Konstruktive Kritik ist immer gut für oss-Projekte.

Die Vorteile von

Mit Ökosystem beziehe ich mich auf das umgebende Ökosystem / die Gemeinschaften der .NET-Bibliothek (auf das sich vermutlich auch das "Ökosystem" im OP bezieht), das es ersetzt, von dem ich auch behaupten würde, dass .NET-Benutzer auch von einem gesunden Ökosystem profitieren eine Vielzahl von Optionen und mehr Wettbewerb (wie es das Merkmal gesünderer Ökosysteme wie Python, Java, Node, Ruby, PHP usw. ist).

EF ist das beste ORM in der .NET-Welt

Kurz nach der Veröffentlichung von EF eroberte es schnell den Großteil des ORM-Marktanteils, war dabei über 6x langsamer als NHibernate und unterstützte wohl weniger Funktionen, Auszug aus meinem InfoQ-Interview 2012 :

Ihr jüngster Versuch einer ORM-Datenzugriffsschicht im Entity Framework hat sich auch negativ auf die einst florierende Community des früheren prominenten ORM NHibernate ausgewirkt. Obwohl EF um ein Vielfaches langsamer als jedes andere Open Source .NET ORM ist , ist es EF gelungen, mehr Downloads anzuziehen als alle anderen ORMs zusammen.

Denken Sie daran, dass dies vor .NET Core war, wo Leistung jetzt oberste Priorität hat, aber es ist ein historisches Beispiel für die nachteiligen Auswirkungen von MS-Standardeinstellungen auf vorhandene Ökosysteme/Communitys. IMO ist es so ziemlich akzeptiert, was mit bestehenden Communities passiert, wenn MS Standardeinstellungen einführt, weshalb es kürzlich einen Pushback gegeben hat, um von den Versandstandards zurückzukehren, die mit IdentityServer und AutoMapper konkurrieren.

und MSTest war damals besser als NUnit.

IMO war dies nie der Fall (und die R#-Unterstützung von NUnit war immer ein ausgezeichnetes AFAICR) und die Tatsache, dass wir es nicht plattformübergreifend auf Mono ausführen konnten, bedeutete, dass Bibliotheken, die plattformübergreifend auf Mono unterstützten (vor .NET Core), nicht verwendet werden konnten es.

Aber lassen Sie uns nicht überschwemmen und beim Thema bleiben. Danke schön!

Ich möchte diesen Thread auch hier nicht entführen, musste aber erklären, warum ich mit Ihren Punkten nicht einverstanden bin.

In diesem Zusammenhang ist der Hauptgrund für die Verwendung eines anderen Serializers als JSON.NET jetzt die Leistung und der Grund für diesen neuen Standard-Serializer ist die Leistung. Da die meisten Leute nur Standardeinstellungen verwenden, erwarte ich, dass dies die deutlichsten Auswirkungen auf die JSON.NET-Freigabe hat, während der Hauptgrund für die Verwendung eines alternativen Serializers mit diesem schnelleren Impl nicht mehr bestehen sollte. Grundsätzlich sehe ich dies also auch als nachteilig auf das bestehende (Bibliotheks-)Ökosystem. IMO ist ein schwächeres Ökosystem von JSON-Bibliotheken ein Netto-Negativ für .NET (was die meisten Verbraucher nicht sehen werden, sie verwenden einfach die Standardeinstellungen und vergessen die anderen Optionen), aber das ist nicht mein Hauptanliegen.

@davidfowl @shahid-pk

Trotzdem hätte ich es vorgezogen, dass dies vor 8 Jahren existierte, da der Hauptgrund für die Entwicklung von ServiceStack.Text darin bestand, dass .NET Framework JSON-Serializer extrem langsam waren. Aber nach all dieser Zeit SS.Text wurde für die Unterstützung in allen unseren Bibliotheken, zB Anpassungen mit einer Reihe von Funktionen erweitert verschiedenen Sprachen ServiceStack Unterstützt verschiedene JSON Anpassungsoptionen in ServiceStack , JSON - Unterstützung in ServiceStack Vorlagen , komplexer Typ JSON blob Unterstützung in ServiceStack .Redis usw.

Jetzt konzentriere ich mich auf die Bewertung der Auswirkungen, wie die neuen API- und Plugability-Optionen aussehen werden, können wir vorhandene Funktionen nachrüsten, werden wir in der Lage sein, den JSON-Serializer in SS .NET Core-Apps zu übernehmen? (was wird es kaputt machen), wird ServiceStack.Text in der Lage sein, die neue API zu unterstützen, werden wir .NET v4.5 unterstützen können, wird es in der Lage sein, es an die Drahtformate bestehender Bereitstellungen anzupassen usw. I Ich habe im Grunde keine Ahnung, welche Auswirkungen dies hat oder wie die Strategie weitergehen wird, da ich noch keine Gelegenheit hatte, etwas zu verwenden oder zu sehen. Ich werde mehr Antworten wissen, wenn ich die Gelegenheit dazu habe, und ich würde natürlich gerne die Möglichkeit haben, die Integration zu testen, Feedback zu geben und Änderungen vorzuschlagen, bevor die APIs eingefroren wurden.

@mythz

Gibt es einen Grund, warum die zweitbeliebteste JSON-Bibliothek nach JSON.NET - ServiceStack.Text, die bereits umgestaltet wurde, um auf Span-APIs erstellt zu werden, ausgeschlossen wurde?

Die Unterlassung war nicht beabsichtigt. Wir haben im Rahmen des CoreFxLab-Repositorys aktiv nach Autoren von JSON-Bibliotheken gesucht und mit einfachen Suchbegriffen wie "json" auf NuGet gefüllt . Anscheinend wurde Ihre Bibliothek einfach nicht angezeigt. Ich verstehe, dass dies frustrierend oder besorgniserregend für Sie sein kann, aber versuchen Sie, die Situation von unserer Seite her zu verstehen: Von unserem Team kann nicht erwartet werden, dass es jede Bibliothek unter der Sonne kennt. Diese Ankündigung ist Teil unseres offenen Entwicklungsmodells, um die gesamte Community einzubeziehen. Der einzige Grund, warum wir dazu neigen, zuerst kleinere Gruppen zu erreichen, besteht darin, sicherzustellen, dass unsere Pläne und Botschaften ein angemessenes Maß an Nachdenklichkeit und Qualität aufweisen, bevor wir sie mit der Welt teilen. Noch ist nichts endgültig. Wir suchen aktiv nach zusätzlichem Feedback.

Ich bin neugierig, auf welches "Ökosystem" Sie sich beziehen und mit dem Sie hoffen, hier "zusammenzuarbeiten"?

Das .NET-Ökosystem und insbesondere die an der JSON-Verarbeitung interessierten Parteien.

Mich würde natürlich interessieren, wie kompatibel diese "steckbaren" APIs am Ende sind oder ob dies ein weiterer Bereich ist, in dem die Einführung und Integration neuer MS-Bibliotheken das Ökosystem, das sie ersetzt, zerstört.

Der Zweck der geplanten ASP.NET Core-Erweiterungspunkte besteht darin, Kunden zu ermöglichen, die integrierte JSON-Komponente durch eine beliebige JSON-Bibliothek zu ersetzen. Natürlich wird ASP.NET immer mit "Batterien im Lieferumfang" ausgeliefert, dh einem vernünftigen Standarderlebnis. In der Vergangenheit war dies Json.NET und in Zukunft eine von der Plattform bereitgestellte Komponente. Angesichts der Tatsache, dass Json.NET etwas fest mit ASP.NET verdrahtet war, scheint der neue Plan für Leute wie Sie netztechnisch besser zu sein; Daher bin ich mir nicht ganz sicher, welchen Teil unseres Plans Sie für eine Bedrohung halten.

Es gibt eine offene Frage, was die Vorlagen für ASP.NET in 3.0 verwenden werden.

Ist es nicht an der Zeit, dass die Vorlagen modular sind? Nehmen wir zum Beispiel vue.js.

Wenn Sie eine neue vue-App erstellen, können Sie die gewünschten Dinge auswählen. Warum kann nicht etwas Ähnliches für asp.net getan werden, anstatt 500 Vorlagen zu erstellen, um alle Szenarien abzudecken.

Hier ist ein konkretes Beispiel für ein Feature in .ASP NET Core 2.2, bei dem Nicht-JSON.NET JSON-Eingabe-/Ausgabeformatierer Probleme haben und wie eine entkoppelte Lösung helfen könnte:
Die ProblemDetails- Funktion, die eine RFC 7807- kompatible Fehlerreaktion ermöglicht:
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);

Der obige Code ist mit JSON.NET-spezifischen Attributen annotiert, einschließlich eines spezifischen Fallback-Attributs [JsonExtensionData] , alle unbekannten JSON-Eigenschaften werden in dieses Wörterbuch deserialisiert und der Inhalt dieses Wörterbuchs wird in die normale JSON-Struktur serialisiert.

Jeder alternative JSON-Eingabe-/Ausgabeformatierer muss nun diese JSON.NET-spezifischen Attribute verarbeiten, um diesen Typ ordnungsgemäß zu serialisieren/deserialisieren oder einen anderen Weg zu finden, dh für diese Typen auf JSON.NET zurückzugreifen.

Wenn wir nun eine gut definierte Spezifikation von Funktionen haben, die ein Input/OutputFormatter für JSON für 3.0 unterstützen muss, existiert das obige Problem nicht, da diese Attribute in einem Microsoft.Extension...-Paket und jedem benutzerdefinierten JSON-Formatierer leben könnten könnte sie verwenden, um diese Funktionalität kompatibel zu implementieren.

Meines Wissens nach gibt es nur wenige Instanzen von "offiziellem" Quellcode in ASP.NET Core, die mit JSON.NET-Attributen annotiert sind, aber ich habe auch Bibliotheken von Drittanbietern gesehen, die JSON.NET-spezifische Attribute verwenden (normalerweise zur Angabe). den Attributnamen über [JsonProperty("name")]

FWIW, darum geht es bei https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Ich denke, Sie haben geantwortet, bevor Sie meinen vorherigen Kommentar gelesen haben, der IMO mehr meine Bedenken klärt.

Wir suchen aktiv nach zusätzlichem Feedback.

Woher? Gibt es einen API-Vorschlag/-Dokument, wurde eine API erstellt, unter welchem ​​Repository wird sie entwickelt?

Ich denke, Sie haben geantwortet, bevor Sie meinen vorherigen Kommentar gelesen haben, der IMO mehr meine Bedenken klärt.

Ich habe es gelesen, aber es scheint, dass Sie sich gegen einen Standard aussprechen , der, wie

Woher? Gibt es einen API-Vorschlag/-Dokument, wurde eine API erstellt, unter welchem ​​Repository wird sie entwickelt?

Wir haben bewusst noch kein Codierungs-/API-Design in .NET Core durchgeführt, da wir diese Ankündigung zuerst veröffentlichen wollten. Wir wollten nicht, dass die Leute die Teeblätter lesen, ohne den Kontext anzugeben, den diese Ankündigung lieferte. Mit anderen Worten, bleiben Sie dran, wir werden bald APIs und Code veröffentlichen.

@terrajobst Ganze Impression für Post that

1. Die Entscheidung, Änderungen vorzunehmen, ist gefallen.

Für die Zukunft planen wir, einige Änderungen an unserer JSON-Unterstützung vorzunehmen:

1. Einige vorläufige Entwürfe sind fertig
   Wir brauchen leistungsstarke JSON-APIs.
   Entfernen Sie die Abhängigkeit von ASP.NET Core zu Json.NET.
   Stellen Sie ein ASP.NET Core-Integrationspaket für Json.NET bereit.

All dies bedeutet, dass eine Richtung eingeschlagen wird. Alles, was vom "Ökosystem" verlangt wird, ist, offensichtliche Schmerzpunkte zu finden, die MS realistischerweise nicht erklären konnte.

Das Weglassen von ServiceStack und die Diskussion als eine .NET-Bibliothek zweiter Klasse ist lächerlich. Auch wenn ich ausschließlich über MS Libraries ausgeliefert habe, heißt das nicht, dass ich keine Alternativen wüsste.

Ich habe kein Problem damit, dass MS Entscheidungen trifft, aber wenn es direkt gesagt wurde und nicht mit "Community-Feedback" zu bereits getroffenen Entscheidungen abgedeckt wurde.

Das ist mein Eindruck

@terrajobst

Ich habe es gelesen, aber es scheint, dass Sie sich gegen eine Standardeinstellung wehren

Ich habe das nie behauptet, JSON.NET war schon vorher der Standard. Ich habe es oben ausführlicher erklärt, aber um es noch einmal zu wiederholen, ist dies in der Lage, den Standard zu übernehmen und der neue Defacto-Standard zu werden, bei dem .NET Core in der Zukunft effektiv nur 2 JSON-Serializer haben wird: dieser neue Defacto-Hochleistungsstandard und JSON. NET für benutzerdefinierte Funktionen. Andere JSON-Serializer werden Nischen werden, zB einzigartige Funktionen, die hinzugefügt werden, um verschiedene Szenarien zu unterstützen.

Wir haben bewusst keine Codierung/API-Design für .NET Core vorgenommen, da wir diese Ankündigung zuerst erhalten wollten.

Ok, also kann kein "Außenstehender" wissen, wie gut die Steckbarkeit, Erweiterbarkeit oder Interoperabilität ist
wird noch sein.

Wir wollten nicht, dass die Leute die Teeblätter lesen, ohne den Kontext anzugeben, den diese Ankündigung lieferte. Mit anderen Worten, bleiben Sie dran, wir werden bald APIs und Code veröffentlichen.

Es wurde also intern entwickelt? Wie lange nach der Veröffentlichung müssen Außenstehende testen und Änderungen am API-Design vorschlagen? Mein Hauptanliegen, wie die "einsteckbaren" und "erweiterbaren" APIs aussehen werden, werden wir in der Lage sein, "übernehmen" und die vollständige Kontrolle über das Drahtformat von Ref/Wert-Typen zu haben? Was ist mit eingebauten Typen, Aufzählungen, Bools, anderen intrinsischen Eigenschaften usw.? ZB kann es bool konfigurieren, dass es andere gängige JSON-Werte wie "yes", "on", "1" akzeptiert.

Andere Fragen:

• Kann diese Implementierung eigenständig verwendet werden (in einem separaten NuGet-Paket)?
• Ist der "plugable" Teil der API an das Web Framework gebunden oder kann er an anderer Stelle verwendet werden (zB Xamarin/UWP)
• Wird es .NET Standard 2.0 oder .NET v4.5 unterstützen?
• Wenn nicht, können die APIs .NET Standard 2.0 oder .NET v4.5 unterstützen?

@mythz
Es ist nicht wirklich intern entwickelt (nach meinem Wissen), der Reader/Writer-Teil wird in corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) und insbesondere gibt es in corefxlab noch keine High-Level-API dafür.

Persönlich würde ich ausschließen, dass die erweiterbaren / steckbaren API-Teile .NET-Standard sind (dh Attribute usw.). Die Bibliothek in corefxlab ist derzeit .NET Standard 1.1, aber ich kann mir vorstellen, dass sich dies je nach Leistungsziel der Bibliothek usw. ändern wird.

@mythz

Sie scheinen begierig darauf zu sein, meine Aussagen zu nehmen und sie in einen "Das Glas ist halb leer"-Kontext zu setzen. Ich verstehe, du bist skeptisch. Ich schlage vor, dass wir uns eine Reihe von Tastenanschlägen sparen und konkrete API-Vorschläge diskutieren, anstatt sie abstrakt zu diskutieren. Ich bin ziemlich überzeugt, dass unser Plan die von Ihnen benötigten Erweiterungspunkte bietet.

@terrajobst Ich versuche nicht, skeptisch zu sein, sondern zu wissen, was die vorgeschlagenen Funktionen auf hoher Ebene sind, von denen ich annehme, dass sie bereits beschlossen wurden (oder sind sie alle noch offen?). Diese Ankündigung ist die erste, die die meisten von uns davon gehört haben, also war ich nach einiger Klärung darüber, wie steckbar, erweiterbar und wiederverwendbar es sein soll. Ist System.Text.JsonLab das aktuelle Impl? bedeutet dies, dass es auch .NET Standard 2.0 und .NET v4.5 unterstützt?

Dies mag eine nette Funktion für Bibliotheksersteller sein, aber Sie müssen auch die Unternehmensentwickler berücksichtigen, die 50 Bibliotheken mit Abhängigkeitsbäumen verwenden und versuchen, Kompatibilitäten zwischen diesen zu finden. Wird es Mapping-Konfigurationen im Binding-Redirect-Stil geben, um zu versuchen, die Nichtübereinstimmungen zu verwalten?

Dieses Gespräch wirkt nervös, sei es, weil die Leute in irgendeiner Weise beleidigt wurden oder weil sie versuchen, eine getroffene oder nicht ergriffene Maßnahme zu verteidigen. Es ist schwer zu lesen. Entschuldigung herum! Bitte lassen Sie einfach den aktuellen Stand und gehen Sie weiter.

Es scheint zwei Gründe für diese Änderung zu geben. Der erste ist der Wunsch nach verbesserter Leistung durch die Verwendung neuer Typen in .Net Core.

Darüber hinaus wurde erkannt, dass vor einiger Zeit ein Architekturfehler beim Einfügen von harten Verweisen auf JSON.Net gemacht wurde, eine Bibliothek, die sich außerhalb von .Net befindet. Um dies zu beheben, muss die Einführung einer neuen, integrierten JSON-Implementierung sowie Schnittstellen erfolgen, die es Dritten ermöglichen, ihre eigenen Implementierungen zu verwenden.

Wird das Dinge kaputt machen? Jawohl! Aus diesem Grund ist die Ankündigung mit dem Etikett "Breaking Changes" versehen. (Vielleicht sollte dieses Label hier wiederholt werden.) Und da dies bekanntermaßen eine bahnbrechende Änderung ist, wurde eine Diskussion gestartet, um die Auswirkungen zu untersuchen. Um die Auswirkungen zu minimieren, wird außerdem eine zusätzliche Bibliothek bereitgestellt, die es den Benutzern ermöglicht, JSON.Net weiterhin zu verwenden.

Als Bibliotheksautor interessiert mich das sehr, und ich würde es vorziehen, wenn das Gespräch vorangetrieben würde.

@Tornhoof Als Reaktion auf Ihre Beispiele müsste ich, wenn ich JSON.Net weiterhin verwenden möchte, auch auf die zuvor erwähnte Kompatibilitätsbibliothek verweisen. Es sollte hauptsächlich Plug-and-Play sein, aber es kann Änderungen geben. Ich möchte definitiv nicht, dass das Framework (.Net Core) vorschreibt, dass der von mir gewählte Serializer diese Attribute für die Serialisierung verwenden MUSS, insbesondere wenn mein Serializer einen anderen Mechanismus für ähnliche Konzepte verwendet.

Die von .Net bereitgestellte Lösung sollte allgemeiner sein. Die ausgewählte JSON-Implementierung sollte eine spezifische Verarbeitung der Modellserialisierung durchführen.

@mythz Nach allem, was ich weiß und von den Leuten gesehen habe, die an diesem Vorschlag beteiligt sind, werden Sie eine lange Chance haben, die vorgeschlagene API und die Implementierung zu überprüfen und zu kommentieren, bevor sie als stabil veröffentlicht wird. Einer der Gründe für diesen Beitrag in einem so frühen Stadium war es, Leute wie Sie aus genau diesem Grund zu finden.

@gregsdennis
Ich bin mir nicht sicher, was du mit allgemeiner meinst?
Angenommen, Ihr Serializer hat das Konzept, json-Eigenschaftsnamen zu überschreiben, ihr Null-Verhalten und/oder Fallback-/Catch-All-Implementierungen zu ändern und davon auszugehen, dass alle drei Funktionen Teil der gemeinsamen Spezifikation für JSON-Serializer für .net Core 3.0 sind, dann das Implementierungspaket ordnet diese Attribute Ihren internen Implementierungsdetails zu.
Wenn Ihre Bibliothek es zum Beispiel vorzieht, [DataMember] zu verwenden, um den Namen von Eigenschaften anzugeben (wie SpanJson es tut), sollte Ihr Integrationspaket so einfach zuordnen.
Ich sage nicht, dass Attribute der richtige Weg sind, es ist einfach ein sichtbarer Teil des Codebeispiels.

Die ideale Welt wäre natürlich, dass keine ASP.NET Core-Framework-Bibliothek spezifische Annotationen verwendet, um das Serialisierungsverhalten zu steuern, aber was das obige Feature betrifft, ist dies ziemlich kompliziert bis unmöglich, da der RFC erfordert, dass bestimmte Benennungsregeln befolgt werden .

Wie auch immer, ich denke, es wird in Zukunft viele Diskussionen über diese gemeinsamen Funktionen geben, wie man sie verwendet und beschreibt.

Gibt es Pläne, SIMD-Anweisungen im neuen JSON-Parser zu verwenden, wie in RapidJSON?

Referenz: http://rapidjson.org/

Der vorgeschlagene Vorschlag sieht gut aus , aber bitte versuchen Sie einfach " Breaking Changes " zu glätten ).

Daher konnte monatelang keine meiner UWP-Apps im Release-Modus erstellt werden, da ich den gesamten Code neu schreiben musste, der Reflektion in Bibliotheken von Drittanbietern verwendet. Ich weiß, dass viele Bibliotheksautoren ihre Implementierungen erneut aufteilen mussten, um Reflexionen in diesen UWP-Teilen auszuschließen. Die meisten Bibliotheksautoren kamen nicht zur Party, und ich war gezwungen, das Schiff zu verlassen. Obwohl MS in den Vordergrund trat und sich verpflichtete, eine Alternative im .net-Standard 2.1 zu implementieren. Wir wissen, dass die Realität vor Ort ist.

Der Punkt ist einfach, dies war für mich ein enorm störender Prozess, der massive Konsequenzen für die Endbenutzer hatte und alles andere als "reibungslos" und reibungslos verlief.

Dies ist definitiv der richtige Schritt.
Ich wundere mich eine Weile, diese Json.Net-Referenz zu sehen.

@Tornhoof Ich denke, es muss eine definierte Trennung geben: die Schnittstellen, die jeder Anbieter implementieren müsste, um mit .Net Core 3.0 verwendet zu werden, und die integrierte Standardimplementierung.

Die Schnittstellen sollten möglichst allgemein verwendbar sein. Vielleicht so einfach wie nur die Methoden Serialize() und Deserialize() zu definieren.

Andere Details sollten der Umsetzung überlassen werden. Wenn die Standardimplementierung ein Attribut verwendet hat, um einen benutzerdefinierten Eigenschaftsschlüsselmechanismus zu definieren, bin ich damit einverstanden. Ich denke, das ist ein implementierungsspezifisches Detail, das nicht Teil der Schnittstelle sein sollte.

Das heißt, die Möglichkeit , benutzerdefinierte Schlüsseleigenschaften zu erstellen, könnte eine Anforderung sein, obwohl ich nicht sicher bin, wie dies kodifiziert werden könnte.

@gregsdennis Ja, Sie haben Recht, ich habe mir hauptsächlich den IInput/OutputFormatter angesehen, der derzeit in ASP.NET Core bereits vorhanden ist, und insbesondere die Probleme beim Ersetzen durch Nicht-JSON.NET-Versionen.
Wie Ihre und @mythz- Kommentare zeigen, wird die Bereichsdefinition wahrscheinlich interessant und wahrscheinlich nicht so einfach (ich erinnere mich an die Probleme mit den DI-Schnittstellenspezifikationen). Daher ist es besser, viele verschiedene Standpunkte frühzeitig in den Prozess einzubeziehen.

@Tornhoof stimmte zu. Die aktuellen Formatierungsschnittstellen sind eindeutig JSON.Net-basiert, jedoch nicht so sehr auf dem Serializer selbst, sondern eher auf dem Optionsobjekt. Es scheint, dass wir auch einen generischen Weg benötigen würden, um Optionen zu kommunizieren (ein gemeinsames Optionsobjekt).

Bedeutet dies, dass das Optionsobjekt einen minimalen Funktionsumfang für eine Implementierung vorschreibt? Ich glaube nicht. Ich habe kürzlich einen Formatierer für meinen Serializer implementiert, der das Optionsobjekt vollständig ignoriert, aber es war für meinen privaten Gebrauch. Wenn ich eine für den öffentlichen Gebrauch machen wollte, würde ich versuchen, so viele dieser Optionen wie möglich zu interpretieren, um sie zu unterstützen.

Nicht so machen wir die Dinge jetzt. Die Optionen sind Serializer-spezifisch und es gibt keine gemeinsame Schnittstelle für sie. Die Formatierer in MVC sind bereits richtig ausgeklammert und an nichts gekoppelt. JsonResult hat Breaking Changes, da es direkt JsonSerializationOptions (den JSON.NET-Typ) verwendet.

Ich wollte dasselbe sagen. Wir planen nicht, eine Abstraktion für einen JSON-Reader/Writer/Serializer zu erstellen. Es wird nicht benötigt; Frameworks verarbeiten entweder IO-Primitive (z. B. Stream , TextReader ) oder lassen sich in eine übergeordnete Framework-Verarbeitung (z. B. die ASP.NET Core-Formatierer) einbinden.

Apropos Schmerzpunkte: Persönlich (und ich bin wahrscheinlich eine sehr kleine Minderheit) mache ich mir Sorgen über die lasche Natur vieler JSON-Parser. Es gibt einen Standard (tm), aber die meisten Parser haben sich dafür entschieden, nachsichtig zu sein und nicht konforme Dokumente zu akzeptieren. Das Schlimme daran ist auf lange Sicht, dass Entwickler nicht in Richtung eines Standards implementieren, den sie in Richtung einer Bibliothek implementieren. Wenn die Bibliothek nicht konforme Dokumente zulässt, sind die Entwickler zufrieden, solange alle Bits dieselbe Bibliothek verwenden. Der Schmerz entsteht, wenn versucht wird, zwischen Domänen zu kommunizieren, die unterschiedliche Bibliotheken verwenden. Plötzlich gibt es ein Problem, weil verschiedene Bibliotheken unterschiedliche JSON-Varianten unterstützen.

Sollten wir die Schwachstellen beseitigen, indem wir die JSON-Bibliothek so nachsichtig wie möglich gestalten (aber vielleicht mit Komplexität und Mehrdeutigkeit enden) oder die Ursache angreifen; nicht bestätigende JSON-Bibliotheken.

Da MS einflussreich ist, gibt es vielleicht zu viel verlangt von MS, um sich erfolgreich für konforme JSON-Parser einzusetzen, um die Interoperabilität auf lange Sicht zu verbessern, aber ich wünschte, es wäre anders. Vielleicht nachsichtig beim Lesen, aber streng beim Schreiben?

(Dinge, die nicht im Standard enthalten sind; Kommentare, nachgestellte Kommas, einfache Anführungszeichen, keine Anführungszeichen usw.)

IMHO, da JSON aus der Webbrowser-Welt stammt, sollten wir aus Gründen der Interoperabilität Double als zugrunde liegende Darstellung für Zahlen in JSON wählen, obwohl der JSON-Standard nichts über den Rep sagt.

Was die API angeht, gehe ich implizit davon aus, dass die am häufigsten verwendete API eine DOM-ähnliche API sein wird, aber ich würde es auch sehr nützlich finden, wenn es eine API auf niedrigerer Ebene gäbe, die es mir ermöglicht, den Token-Stream zu konsumieren oder auf einer Besucherschnittstelle signalisiert zu werden diese großen Dokumente, aus denen ich nur einen kleinen Teil der Daten extrahieren möchte.

@mrange - So sehr ich es mag, die Dinge so streng wie möglich zu machen .... dies hängt von der Möglichkeit ab, Änderungen am nicht konformen Code vorzunehmen.

Wenn Sie mit einem Legacy-Dienst interagieren, der unter der Kontrolle eines anderen Unternehmens steht, ist die Möglichkeit, den anstößigen Code zu ändern, nahezu null. Selbst striktes Schreiben ist zwar machbarer, hat aber hier seine eigenen Probleme: Was ist, wenn der anstößige Code erwartet, dass ein nicht konformes Objekt an ihn gesendet wird?

@terrajobst danke! Func<Stream, CancellationToken, Task<T>> und Func<T, CancellationToken, Stream, Task> ist alles, was hier benötigt wird. Mit vielleicht einigen Überladungen für TextReader/Writer, Span und String.

Der Nachteil ist jedoch, wenn Sie den Typ einer anderen Bibliothek serialisieren / deserialisieren möchten und dieser Typ mit Attributen von einem Json-Serializer ausgestattet ist, den Sie nicht verwenden.

@thefringeninja Wenn Sie bereits die Drittanbieterbibliothek für die Objekte verwenden, haben Sie bereits einen Verweis auf den anderen Serializer. Da hat sich nichts geändert.

Ich bin kein Mensch für Panikmache, aber ich denke, @mythz hat einige gültige Punkte.

@terrajobst In Bezug auf das Ökosystem glaube ich nicht, dass eine schnelle Suche nach "json" auf NuGet irgendjemandem viel sagen würde, obwohl es unmöglich ist, jede Bibliothek da draußen zu berücksichtigen. Vielleicht ist der Name ServiceStack.Text nicht gerade der direkteste Ausdruck für "Hey! Ich bin ein Paket, das JSON (de)serialisieren kann!", aber im Laufe der Jahre gab es Benchmarks, die dies vergleichen. Vielleicht ist es ein Fall, dass man die MS-Standardeinstellungen dogfood macht und entweder die Breite und Popularität der Alternativen nicht kennt oder sie intern häufig genug verwendet, um mit ihnen vertraut zu sein.

Ich stimme zu, dass es einige Voreinstellungen geben sollte, um eine Erfahrung zu bieten, die _einfach funktioniert_ out-of-the-box. Wenn andere Bibliotheksautoren im Ökosystem ein Integrationspaket veröffentlichen, wäre es großartig, wenn sie in den Dokumenten, Versionshinweisen usw. Es wäre für das Ökosystem problematisch, es schwer zu entdecken.

Ich hoffe, dass die APIs die Bedürfnisse der Community am besten abbilden und nicht direkt nach Json.NET modelliert werden, wenn das Ziel der Beseitigung der Abhängigkeit aufrichtig ist. Die Quintessenz ist, dass alle Bibliotheksautoren arbeiten müssen, nicht nur ServiceStack, aber die APIs sollten nicht direkt der API von Json.NET ähneln, sonst sind Sie wieder bei einer Abhängigkeit, aber ohne die DLL.

die APIs sollten nicht direkt der API von Json.NET ähneln

... oder die Implementierung eines anderen spezifischen Anbieters.

Ein Teil der Diskussion, die vor der Ankündigung stattfand, beinhaltete die Idee, dass das .Net-Team aus verschiedenen Bibliotheken schöpfen würde, um ein Gefühl dafür zu bekommen, wie verschiedene Probleme gelöst wurden, und dann das zu verwenden, was ihrer Meinung nach am besten zu diesen passt Ideen mit eigenen kombiniert. In vielerlei Hinsicht ist es nicht unähnlich, wie jede andere neue JSON-Bibliothek entwickelt würde. es kommt einfach vor, dass dieser in den Rahmen aufgenommen wird.

Wir sind all-in mit einer leistungsstarken JSON-Bibliothek, die wir nicht selbst erstellen müssen. :)

Bevor Sie etwas besprechen, sollten Sie in Betracht ziehen, die Ergebnisse von Microsoft Research in diesem Bereich zu nutzen (genauer gesagt das No Branching No FSM-Parsing) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -Datenanalyse/

Wir gehen in diese Richtung für Hochleistungs-JSON-Parsing --- abgesehen von Span<T> natürlich ---
cc @terrajobst @karelz

:( Bei all dieser Diskussion über JSON habe ich das Gefühl, dass meine Frage zu Vorlagen fehlgeschlagen ist.

Ich wünschte, ich hätte mehr Zeit für diese Diskussion, denn es war die Hölle, aber ich verstehe, warum es zu dem geworden ist, was es ist. 4.6.1 muss mit Upgrades und Upgrades konsistent bleiben und Breaking Changes werden für den Rest sein.

Ich habe viele zurückgerufene Pakete für Core und 461 gesehen und hoffe, dass diese Art oder Änderung das Problem beheben wird.

Ich mache mir Sorgen, dass uns das Problem der Kaskadierung heimsuchen wird, bitte beweisen Sie uns, dass wir falsch liegen.

// Punktnetz-Entwickler überall

@c0shea

[…] es wäre großartig, wenn sie einen Plug in die Dokumentation, Versionshinweise usw. bekommen könnten, um hervorzuheben, dass es Alternativen über die Standardeinstellungen hinaus gibt.

Ich bin sicher, das wird der Fall sein. In den Dokumenten sind bereits alternative Implementierungen für mehrere Themen aufgeführt, z. B. DI-Container , Protokollierungsanbieter , Swagger-Integration oder EF Core-Datenbankanbieter .

@phillip-haydon
Das Vorlagensystem unterstützt bereits anpassbare Vorlagen, und die vorhandenen Vorlagen haben tatsächlich bereits eine Reihe von Optionen. Schauen Sie sich zB dotnet new mvc --help an, was derzeit möglich ist. Ich bin sicher, Sie könnten dies leicht mit beispielsweise alternativen JSON-Serializer-Integrationen erweitern, und Feature-Requests oder Pull-Requests dafür werden wahrscheinlich bei aspnet/Templates akzeptiert.

@mrange - So sehr ich es mag, die Dinge so streng wie möglich zu machen .... dies hängt von der Möglichkeit ab, Änderungen am nicht konformen Code vorzunehmen.

Wenn Sie mit einem Legacy-Dienst interagieren, der unter der Kontrolle eines anderen Unternehmens steht, ist die Möglichkeit, den anstößigen Code zu ändern, nahezu null. Selbst striktes Schreiben ist zwar machbarer, hat aber hier seine eigenen Probleme: Was ist, wenn der anstößige Code erwartet, dass ein nicht konformes Objekt an ihn gesendet wird?

Vielleicht haben Sie standardmäßig einen strikten Modus und können ihn explizit in einen milderen Modus umschalten

@poke Ich denke, du musst wirklich vue cli ausprobieren und dann dotnew neu versuchen. Das aktuelle dotnet neu... ist... es ist...

Darf ich Sie bitten, sich daran zu erinnern, dass das Parsen von JSON durch die verschiedenen Browser int64-Werte nicht richtig unterstützt und uns die Möglichkeit gibt, Longs als Strings zu serialisieren/deserialisieren? Es ist eines dieser Dinge, die Sie nicht bemerken, bis es Sie hart beißt. Eine Variante davon ist die Möglichkeit zu entscheiden, ob Zahlen standardmäßig in Ints oder Longs deserialisiert werden.

Darf ich Sie bitten, sich daran zu erinnern, dass das Parsen von JSON durch die verschiedenen Browser int64-Werte nicht richtig unterstützt und uns die Möglichkeit gibt, Longs als Strings zu serialisieren/deserialisieren? Es ist eines dieser Dinge, die Sie nicht bemerken, bis es Sie hart beißt. Eine Variante davon ist die Möglichkeit zu entscheiden, ob Zahlen standardmäßig in Ints oder Longs deserialisiert werden.

....Ah, EcmaScript, danke, dass du alles verdoppelt hast. Ich bin mir sicher, dass das in einem anderen Teil des Codes keine Probleme verursacht hat ...

Als Purist mag ich solche Sachen nicht.
Als Realist muss ich dem wohl zustimmen.

Wird ein Teil der neuen JSON-Implementierung in .Net Standard 2.1 sein ?

Ich habe das ein bisschen verfolgt und bin mir nicht sicher, ob ich es übersehen habe. Gibt es eine vorgeschlagene API-Oberfläche oder Schnittstelle, die ich überprüfen kann? Ich bin daran interessiert, die API-Oberfläche für dieses Angebot zu sehen.

Gibt es eine vorgeschlagene API-Oberfläche oder Schnittstelle, die ich überprüfen kann?

Es gibt noch viel zu tun, aber https://github.com/dotnet/corefx/pull/33216 ist ein Anfang. Hier sind die API-Überprüfungshinweise .

UPDATE: Roadmap auch hier verfügbar.

Wie also werden die Funktionen der aspnet 3.0-APIs mit der json.net-API verglichen? Wird json.net in jeder Hinsicht durch die Entwicklung neuer Apps mit nativen APIs auslaufen?

nur die Leistung verbessern oder alle Funktionen von json.net ersetzen?

Das sind erstaunliche Neuigkeiten.

Ich empfehle dringend, mit @neuecc zusammenzuarbeiten. Seine Arbeit mit MessagePack , Utf8Json , ZeroFormatter usw. war phänomenal.

@linkanyway das Ergebnis wäre, eine Teilmenge von json.net zu ersetzen und gleichzeitig neue APIs ohne Zuordnung bereitzustellen.

Ich vermute, die Mehrheit der aspnet-Benutzer hätte keine starke Abhängigkeit von der json.net-Implementierung und wäre in der Lage, nahezu nahtlos zu migrieren.

Gibt es eine vorgeschlagene API-Oberfläche oder Schnittstelle, die ich überprüfen kann?

Es gibt noch viel zu tun, aber dotnet/corefx#33216 ist ein Anfang. Hier sind die API-Überprüfungshinweise .

UPDATE: Roadmap auch hier verfügbar.

@khellang Bekommen wir lang-Hilfe, die wir wirklich in c# in json schreiben können?

Eine weitere gute Bewegung in Richtung OSS. Wird Entwickler anderer kommerzieller Plattformen motivieren, etwas Besseres zu entwickeln, als MS es bereits kostenlos tut, oder vollständig OSS zu werden, wenn sie sich wirklich für die Community interessieren.

Bekommen wir irgendwelche lang-Hilfe, die wir wirklich json in c# schreiben können?

@dotnetchris Ich bin mir nicht sicher, was du mit "lang help" meinst? JSON-Literale? Ich bezweifle, dass das passieren wird. Haben Sie sich die kommende Funktion "Embedded Language" angesehen? Speziell für JSON ?

@khellang das ist sicherlich ein Schritt in die richtige Richtung, aber ich meine volle Unterstützung. Verwenden Sie dieselben Beispielobjekte aus Ihrem Link, ähnlich wie:

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

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

Mit genügend Voodoo, wie z. B. impliziter Tupel-/Werttupel-/Aufzeichnungsobjektgenerierung, damit dies alles auf der Lang-Ebene hinter den Kulissen funktioniert.

Umgekehrt könnte der Compiler die Json-Dienste aufrufen, eine Klasse erstellen und dann mit einer Instanz der Klasse arbeiten, als ob Sie schreiben würden:

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

Bearbeiten: LOL @ Downvoters.

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

@dotnetchris Bei Interesse bitte auf https://github.com/dotnet/roslyn/pull/24110 abstimmen

Bedeutet „eingebaute“ und „plattformbereitgestellte“ JSON APIs, dass es sich nicht um ein separates (Netstandard-)Nuget-Paket handelt? Wenn nicht, warum nicht?

Ich nehme an, das neue freigegebene ASP.NET Core-Framework kann nicht von Nuget-Paketen abhängen, oder doch?

Gibt es nicht bereits einen System.Json- Namespace? Ist dies der Namespace, der für .NET Core 3.0 und letztendlich .NET Standard verwendet/erweitert wird. Dieser Namespace wird bereits auf Xamarin.Android 7.1+, Xamarin.iOS 10.8+ und Xamarin.Mac 3.0+ verwendet (wird möglicherweise nicht so häufig verwendet, ist jedoch verfügbar 😅).

Das Entfernen würde die Abwärtskompatibilität beeinträchtigen. Wenn Sie es verlassen und eine neue API starten, kann dies zu Verwirrung führen. Das Erweitern/Verbessern ohne Entfernen von APIs kann beim Hinzufügen neuer APIs etwas restriktiv sein.

Es wäre toll, Schnittstellen für JsonReader/JsonWriter zu haben, denn es gibt andere Quellen und Ziele als nur Streams. Ich verwende zum Beispiel auch JSON.NET für MongoDB. Es ist schneller und ich muss nicht mehrere Serializer in meinen Anwendungen verwalten.

Ich weiß, dass es die Leistung ein wenig beeinträchtigen könnte, aber es ist sehr nützlich.

@SebastianStehle : JsonReader/JsonWriter sind Abstraktionen auf hoher Ebene, siehe Kommentar von terrajobst

Der Plan für 3.0 sieht wie folgt aus:

1. Integrierte leistungsstarke JSON-APIs. Low-Level-Reader/Writer, ein Stream-basierter Reader/Writer und ein >Serializer.
2. ASP.NET Core ist in Bezug auf die JSON-Komponente steckbar.

Es gibt eine offene Frage, was die Vorlagen für ASP.NET in 3.0 verwenden werden. Abhängig von der Wiedergabetreue, die wir mit 3.0 bereitstellen können, müssen sie möglicherweise das Json.NET-Integrationspaket einbinden. Das Ziel ist jedoch, genügend Wiedergabetreue und Parität zu liefern, um standardmäßig nur von den integrierten abzuhängen.

Die einfach zu verwendende API auf hoher Ebene würde um Streams gewickelt, um leicht von und zu Streams zu deserialisieren (dies ist häufig bei der Serialisierung der Fall. Wenn Sie in Szenarien, in denen Sie keine Streams verwenden können, die beste Leistung erzielen möchten, sollten Sie das niedrige verwenden Level-APIs, die auf Span<T> oder Memory<T> , insbesondere wenn Sie die Daten bereits zur Hand/im Speicher haben, die Sie verwenden möchten und nicht den Overhead von Async haben.

@TsengSR

https://github.com/neuecc/Utf8Json bietet aus Leistungsgründen (virtuelle Aufrufe und Zuweisungen, denke ich) nicht die Funktionalität zum Schreiben benutzerdefinierter Leser/Schreiber und ich dachte, dass sie den gleichen Weg gehen möchten. Aber bisher habe ich noch keinen Serialisierungscode gesehen.

Ich stimme @JonasZ95 und @gregsdennis zu , ich hoffe, die Implementierung ist keine einfache Abstraktion derselben JSON.Net-Implementierungsdetails, sondern konzentriert sich stattdessen darauf, wie sie aussehen _sollte_.

Ich denke auch, dass es als 2 separate Funktionen angegangen werden sollte ...

1. Serialisierung / Deserialisierung
2. json-Version der Serialisierung und Deserialisierung.

Hoffentlich verwendet das ASP.NET Core-Framework eine generische Serialisierungsabstraktion anstelle einer JSON-spezifischen Abstraktion.

Was die Erweiterbarkeit angeht, hoffe ich, dass das Framework die DI-Technik zum Codieren von Abstraktionen (Schnittstellen, keine abstrakten Klassen) verwendet und einfach einen lokalen Standard bereitstellt. Aus Sicht der JSON-Bibliotheksautoren würde dies die größte Erweiterbarkeit bieten, da Sie lediglich eine ASP.NET Core-Adapterklasse bereitstellen müssten, die die Bibliotheksimplementierung der Schnittstellen verwendet, und dann ASP.NET Core für die Verwendung des Bibliotheksadapters konfigurieren müsste.

Die Implementierung für eine Drittanbieterbibliothek könnte in etwa so aussehen:
```C#
// Verweise auf Bibliotheken von Drittanbietern
mit Newtonsoft.Json;

// sehr naives Beispiel für die Kürze, nur um
// mach den Punkt
öffentliche Klasse NewtonsoftAdapter : ISerializer
{
private JsonSerializerSettings _settings;
private Formatierung _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);
}

}

...

// Adapter mit Anpassungsoptionen von Drittanbietern einrichten
var-Einstellungen = neue JsonSerializerSettings
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = newtonsoftAdapter(settings, Formatting.Indented);

// asp.net-Kern konfigurieren
// wobei der Adapter ISerializer implementiert (oder welchen Namen Sie auch immer haben)
// Bibliotheksautoren könnten sogar ihre eigene UseXYZ()-Erweiterungsmethode bereitstellen.
app.UseSerializer (Adapter);
```

Beim SIMD-basierten Textparsing gab es viele Fortschritte, auch bei strukturiertem Text wie JSON . Besteht die Möglichkeit, dass sich die Arbeit in .NET Core diesem Leistungsniveau annähert? Gibt es eine Möglichkeit, diese Techniken anzuwenden?

Hey, sogar Microsoft Research hat einige neue High-Perf- Lösungen !

@AnthonyMastrean Danke, dass

Übrigens, die Autoren von simdjson sagten, dass sie immer noch daran arbeiten, dieses Projekt vollständig zu veröffentlichen (ich denke, mehr doc). Im Moment können Sie einige interessante Diskussionen über dieses Projekt auf HN lesen.

Gibt es eine Möglichkeit, diese Techniken anzuwenden?

.NET Core 3.0 enthält zufällig eine Reihe von plattformabhängigen systeminternen Funktionen, daher ist es definitiv machbar 😄

Für das, was es wert ist, denke ich, dass das Netzwerk in einem Webbereich ein primärer Engpass ist, und obwohl es cool ist, dass Sie Gigabyte innerhalb von Sekunden analysieren können, denke ich, dass das für ein Webprojekt nicht sehr nützlich ist.

Versteh mich nicht falsch, Leistungsoptimierungen wie diese sind super cool und würden wahrscheinlich sogar sehr kleinen JSON-Dokumenten zugute kommen. Aber im Moment denke ich, dass der Fokus bei der neuen Bibliothek darauf liegt, Speicherzuweisungen zu vermeiden und alles sehr nahe an die Netzwerkschicht zu verlagern. Das allein sollte die Performance gegenüber JSON.NET schon deutlich verbessern. Aber wenn die Anfangsarbeit erledigt ist, könnte die Suche nach zusätzlichen Optimierungen eine andere Sache sein.

Wo ich arbeite, parsen wir jeden Tag Terabytes von JSON. Ich kenne auch andere, die .NET und F# verwenden, um auch viele JSON-Dokumente zu verarbeiten. JSON ist mehr als nur ein Server => Browser-Transportmechanismus geworden. Es wird häufig in reinen Backend-Szenarien verwendet.

OFC; es wäre besser für das Backend, auf ein Binärformat wie AVRO/Protobuf umzusteigen, aber das ist oft schwierig und JSON hat einige Vorteile (ich gebe widerwillig zu). Ein wirklich schneller JSON-Parser könnte für Unternehmen, die uns ähnlich sind, buchstäblich 10.000 Dollar pro Monat sparen.

@poke Dieses Projekt fällt unter .NET Core (nicht ASP.NET...), daher ist es für alle Workloads relevant, nicht nur für das Web.

Ich kann der Idee zustimmen, dass es zu spät ist, an dieser speziellen Optimierungstechnik für .NET Core 3.0 zu arbeiten, aber ich hoffe, dass jetzt einige Untersuchungen durchgeführt werden, um sicherzustellen, dass die Optimierung in Zukunft möglich ist (dh ohne brechende Änderungen). ).

Vielleicht ist es besser, so etwas wie eine vereinheitlichte Mapping-Assembly ('System.Text.Json.Mapping') zu erstellen, in der Attribute und andere Dinge zum Zuordnen von JSON zu C#-Klassen definiert werden? Nach der Implementierung dieses Dings können alle vorhandenen JSON-Parser/Writer übernommen werden, um ein einheitliches Mapping zu verwenden. Es wird allen .NET Standard-Anwendungen die Möglichkeit geben, problemlos zwischen verschiedenen JSON-Bibliotheken zu migrieren

@AlexeiScherbakov Neue Abstraktionen helfen nicht wirklich viel. Sie schränken sich einfach wieder ein, indem Sie eine gemeinsame Abstraktion wählen und es wird immer neue Bibliotheken geben, die die Abstraktion nicht verwenden können und mehr benötigen. Das war schon immer so, zB beim Logging .

Ich glaube nicht, dass das Erstellen einer neuen Abstraktion basierend auf dieser neuen Implementierung uns einen Vorteil bringt, insbesondere wenn die Bibliothek sowieso viel weniger funktionsreich gestaltet ist.

Und es gibt tatsächlich bereits eine vorhandene Netzstandard-Abstraktion in Form von DataContract/DataMember, die hoffentlich von dieser Bibliothek respektiert wird (auch wenn diese Abstraktion etwas eingeschränkt ist).

Abgesehen von einem Ignorieren-Attribut können wir nicht eine Milliarde neuer Attribute und Szenarien haben, die wir berücksichtigen müssen. Möchten Sie JSON lieber 1:1 auf Klassen zuordnen, wenn Sie etwas Außergewöhnliches tun oder Legacy unterstützen möchten, verwenden Sie json.net.

Ich persönlich interessiere mich nicht so sehr für JSON <=> C#-Klassen. Ich denke, es ist wichtig, das Konzept des Parsens/Schreibens von JSON vom erstellten C#-Objektmodell vom JSON-Modell zu trennen.
Auf diese Weise kann ich (die sich nicht so sehr für die JSON <=> C#-Klassen interessieren) einen wirklich effizienten Parser haben, ohne über irgendein Objektmodell herumzulaufen.

@mrange dafür sind der Leser und der Autor da

Bedeutet das, dass ich eine Reader/Writer-API in der von der Plattform bereitgestellten JSON-API erwarten kann? Ist das Reader/Writer-Muster das effizienteste?

Es gibt 3 Typen in System.Text.Json ab sofort :

• Utf8JsonReader - eine schnelle, nicht zwischengespeicherte, vorwärtsgerichtete Methode zum Lesen von UTF-8-codiertem JSON-Text.
• Utf8JsonWriter - ^ wie Utf8JsonReader , aber zum Schreiben.
• JsonDocument – ein schreibgeschütztes Dokumentmodell mit wahlfreiem Zugriff für JSON-Nutzlasten.

Alle oben genannten Typen sollten (mehr oder weniger) frei von Zuteilungen sein 👍

Wir haben das simdjson-Papier gepostet: https://arxiv.org/abs/1902.08318

Es wird auch an einer C#-Portierung von simdjson gearbeitet: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

Vielleicht ist es besser, so etwas wie eine vereinheitlichte Mapping-Assembly ('System.Text.Json.Mapping') zu erstellen, in der Attribute und andere Dinge zum Zuordnen von JSON zu C#-Klassen definiert werden? Nach der Implementierung dieses Dings können alle vorhandenen JSON-Parser/Writer übernommen werden, um ein einheitliches Mapping zu verwenden. Es wird allen .NET Standard-Anwendungen die Möglichkeit geben, problemlos zwischen verschiedenen JSON-Bibliotheken zu migrieren

Ich hoffe wirklich, dass die neue Abstraktion nicht auf Attributen beruht. Ich versuche, saubere POCO-Objekte in den zugrunde liegenden Bibliotheken zu verwenden und DI zu verwenden, um zu vermeiden, dass sie von der Implementierung wissen müssen. Ich möchte meine zugrunde liegenden Klassen definitiv nicht mit Attributen ausstatten, die für die Implementierung erforderlich sind. Dies könnte dazu führen, dass zusätzliche Klassen in den UI-Ebenen erstellt werden, die im Wesentlichen nur ein vorhandenes Domänenobjekt Json zuordnen.

Wahrscheinlich wäre eine 1-1-Zuordnung von json zu c#-Klassen ein besserer Ansatz.

Es wäre jedoch schön, wenn es eine Möglichkeit gäbe, nicht benötigte Eigenschaften zu ignorieren und zumindest einige der Serialisierungsaspekte zu kontrollieren (z. B. Camel vs. Pascal-Gehäuse).

@mrange dafür sind der Leser und der Autor da

@davidfowl Bedeutet das, dass die neuen APIs diesen Weg gehen? Ist das Design fertig?

Die Serialisierungsunterstützung ist gerade angekommen . Das zugehörige Problem sagt:

• Aufgrund von Zeitbeschränkungen und um Feedback zu sammeln, ist das Feature-Set als ein minimal praktikables Produkt für 3.0 gedacht.
• Angestrebt werden einfache POCO-Objektszenarien. Diese werden normalerweise für DTO-Szenarien verwendet.
• Die API wurde so konzipiert, dass sie für neue Funktionen in nachfolgenden Versionen und von der Community erweiterbar ist.
• Design-Time-Attribute zum Definieren der verschiedenen Optionen, unterstützen aber weiterhin Modifikationen zur Laufzeit.
• Hohe Leistung mit IL Emit mit Fallback auf Standardreflexion für Kompat.

Es beschreibt auch, wie sie die Enum-Konvertierung, die Nullbehandlung, Camel- vs PascalCasing usw.

Wenn Sie diesbezüglich Feedback haben, sollten Sie Ihre Kommentare in dieser Ausgabe oder im Pull-Request hinterlassen.

@lemire Wow, das ist echt cool. simdjson ist in der Tat superschnell.

Gibt es eine Chance, den

Ich habe diese Implementierungen gefunden: Im TechEmpower-Repository und im ASP.NET-Repository .

@KPixel Das ist Serialisierung, oder? Inzwischen ist simdjson ein Parser... Wenn ich nicht über die Begriffe verwirrt bin, gehen diese Dinge in die entgegengesetzte Richtung?

Mein Fehler. Ich nahm an, dass es einen Deserialisierungsteil gab (der den Parser verwenden würde).

Wird das System.Text.Json ein .net Standard-Nuget-Paket sein? oder ist es nur für .net Core 3.0 verfügbar?

@John0King schau mal hier: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Ich denke, die Benutzerfreundlichkeit sollte auch ein Schwerpunkt des neuen JSON-Pakets sein. Eine Funktion, die meiner Meinung nach enthalten sollte, ist die Unterstützung der JSON-Schemavalidierung. Dafür berechnet Newtonsoft Gebühren. Dies ist so grundlegend, dass es in der Plattform kostenlos zur Verfügung gestellt werden sollte, wie es bei der XML-Schemavalidierung der Fall war.

@jemiller0 Mein Eindruck ist, dass die XML-Validierung etwas gemischt war und das JSON-Schema in der Realität so

@lemire Ja, es ist eine große Sache, wenn Sie Open-Source-Software entwickeln und Ihre Software für alle verfügbar machen möchten. XML-Parsing ist keine gemischte Sache. Es klappt. Das Gleiche gilt für die JSON-Schemavalidierung. Da dies keine integrierte kostenlose Möglichkeit bietet, ist die .NET-Plattform nicht wettbewerbsfähig.

Ich habe noch nie gesehen, dass das Json-Schema in der realen Welt verwendet wird. Trotzdem sollte es nicht Teil der hier besprochenen Implementierung sein. Und auch hier sollte keine der Milliarden anderen Features und Macken von json.net implementiert werden. Dies sollte nichts anderes als eine superleichte schnelle Implementierung sein. Wenn Sie nicht zufrieden sind, dass Sie eine Lizenz für json.net benötigen, um die Json-Validierung zu unterstützen. Erstellen Sie Ihre eigene Open-Source-Implementierung und machen Sie diese frei verfügbar.

@jemiller0

Ich bin wirklich neugierig: Bieten andere Programmiersprachen in ihrer Standardbibliothek JSON-Schemaunterstützung an?

Das Ziel dieser Bibliothek ist es, eine leistungsstarke Low-Level-Bibliothek für die Arbeit mit JSON zu sein. Alles, was nicht das ist, das die meisten der fortgeschritteneren Funktionen von JSON.NET und auch JSON-Schemas enthält, wird nicht Teil davon sein.

Wenn Sie eine JSON-Schemavalidierung wünschen, steht es Ihnen frei, einen Validator zusätzlich zu dieser Bibliothek zu implementieren, der niedrig genug sein sollte, um dies zu ermöglichen.

Ich glaube nicht, dass die JSON-Schemavalidierung in einer Standardbibliothek etwas damit zu tun hat, ob eine Plattform wettbewerbsfähig ist oder nicht.

Das Ziel dieser Bibliothek ist es, eine leistungsstarke Low-Level-Bibliothek für die Arbeit mit JSON zu sein. Alles, was nicht das ist, das die meisten der fortgeschritteneren Funktionen von JSON.NET enthält, wird nicht Teil davon sein.

Abgesehen davon, dass es auch Funktionen auf höherer Ebene enthält, die als Drop-In-Ersatz von Newtonsoft.Json entwickelt wurden

@poke Sie haben das Recht, jede Meinung zu haben, die Sie haben möchten, genau wie ich. XML wird überall verwendet. Daher hat Microsoft zu Recht Validierungsunterstützung in das .NET Framework integriert. Jetzt ist JSON in aller Munde und wird ÜBERALL verwendet, in Konfigurationsdateien, Web-APIs usw. usw. Es ist sinnvoll, das gleiche Maß an Unterstützung für JSON zu haben, das in der Vergangenheit für XML unterstützt wurde. Ich persönlich finde es etwas lächerlich, dass Microsoft dafür zunächst Software von Drittanbietern einsetzt. Das sollte ein Kernmerkmal der Plattform sein.

@lemire Ich werde bald Python überprüfen. An diesem Punkt werde ich entweder feststellen, dass es integriert ist oder als leicht installierbares Paket enthalten ist. Ich wäre sehr überrascht, wenn es nicht so wäre. Ich überlege, NJsonSchema für das zu verwenden, was ich gerade brauche. Ganz oben können Sie sehen, dass die Dokumentation scheiße ist. Ja, sich auf Bibliotheken von Drittanbietern zu verlassen, die qualitativ hochwertig sein können oder nicht, ist eine großartige Idee für Dinge wie die Arbeit mit JSON, das allgegenwärtig ist und überall verwendet wird. Verlassen wir uns alle entweder auf kommerzielle Software oder auf Pakete von Drittanbietern ohne Dokumentation. .NET sollte nicht nur mit anderen Plattformen wie Python übereinstimmen. Sie sollten sie schlagen, indem sie hochwertige Software mit ordnungsgemäßer Dokumentation sofort bereitstellen. Das war historisch so, wie es funktioniert hat. Wo ich arbeite, hassen alle .NET und wollen mich zwingen, Python zu verwenden. Ich weiß nicht, ob Sie es bemerkt haben, aber immer mehr Leute verlassen das Schiff und wechseln zu Python. Meinem Chef zu sagen, dass ich eine Lizenz kaufen muss, um etwas Einfaches wie die Validierung von JSON zu tun, funktioniert nicht. Was ich im Gegenzug bekomme, wird gefragt, warum ich überhaupt .NET verwenden möchte. Egal, dass dies für ein Open-Source-Projekt ist, für das Sie sowieso keine Lizenz erhalten können. Hoffentlich finde ich, dass NJsonSchema einfach funktioniert. Ich weise nur auf eine eklatante Lücke im Framework hin, die für jeden offensichtlich sein sollte, der mit JSON arbeitet.

Ich verwende JSON-Schemas bei der Arbeit und habe eher einen wirklich guten JSON-Parser als einen halbwegs guten JSON-Parser + JSON-Schemavalidator. Auch das AFAIK JSON Schema ist derzeit ein _draft_ 7. Also ein JSON-Schema als externe Bibliothek, die sich schnell zusammen mit dem Schema weiterentwickeln kann, macht für mich Sinn. Es wäre jedoch schön, JSON-Schema in der Roadmap zu haben.

@jemiller0

Es ist sinnvoll, die gleiche Unterstützung für JSON zu haben, die in der Vergangenheit für XML unterstützt wurde.

.Net bietet auch Unterstützung für XSLT und XPath. Wenn Sie "gleiches Support-Level" wünschen, bedeutet das nicht, dass Sie auch eine Version davon für JSON benötigen?

Was ich damit sagen möchte ist: Das JSON-Ökosystem unterscheidet sich vom XML-Ökosystem. Beide haben unterschiedliche Nutzungsmuster und die zugehörigen Technologien haben unterschiedliche Nutzungszahlen und Standardisierungsstufen. Außerdem wurde XML zu .Net hinzugefügt, bevor NuGet, git oder GitHub existierten. Heutzutage ist es viel einfacher und viel akzeptabler, sich auf eine Bibliothek von Drittanbietern zu verlassen.

Also, nein, ich glaube nicht, dass es sinnvoll ist, blind zu sagen "XML hatte das, also muss JSON es auch haben".

Außerdem ist die Validierung einfach orthogonal zum Parsen. Ich wäre absolut in Ordnung, wenn die Validierungsunterstützung irgendwann hinzugefügt würde (möglicherweise in einem anderen Paket insgesamt). Aber es ist überhaupt nicht notwendig für eine ordnungsgemäße Parsing-Unterstützung.

Wir brauchen eine Möglichkeit zur strikten Validierung von Daten in API-REST-Anfragen.
Weil wir das Json, das über die API kommt, ohne Fehler speichern und es später aufgrund von nachgestellten Kommas usw. nicht in JS analysieren können.

Und warum können Sie diese Anfrage jetzt nicht bestätigen?

@phillip-haydon @ freerider7777 Ich denke, dass jeder anständige JSON-Parser die JSON-Spezifikation einhalten und Fehler (und/oder Warnungen) ausgeben sollte, wenn das Dokument nicht wohlgeformt ist (z. B. wenn es nachgestellte Kommas hat). Das ist ziemlich einfach, unterscheidet sich aber auch von der Validierung , bei der die JSON-Daten mit einem Schema verglichen werden (zumindest verwende ich die Begriffe so).

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

Microsoft, eines der größten Softwareentwicklungsunternehmen überhaupt, hat niemanden, der an der Validierung arbeitet. Ein schneller Parser ist wichtiger. Damit können Sie das ungültige JSON mit Lichtgeschwindigkeit analysieren. :-) Es ist niemandem in den Sinn gekommen, dass eine schnelle Validierung nützlich sein könnte. Dies ist genau wie ASP.NET Core, ein schnelles Upgrade auf Web Forms.

Und warum können Sie diese Anfrage jetzt nicht bestätigen?
@phillip-haydon Im Controller-Code mit einem solchen Json:
ModelState.IsValid == true

️

Sie können die Validierung basierend auf Ihrem Json-Schema bereits mit 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>

Ich stimme @lemire zu , es gibt einen Unterschied zwischen der Validierung der Struktur von JSON und der Validierung von JSON Siehe den Kommentar von

Ich glaube nicht, dass die Tatsache, dass sie dies absichtlich nicht mit allem Schnickschnack ausgestattet haben, es zu einem minderwertigen Produkt macht.

Ist dies zufällig mit Vorschau 4 versandt worden?

Gibt es Pläne, den System.Text.Json.Serialization.Policies.JsonValueConverter zu erstellen?class public, um das Ersetzen von Konverterklassen von Json.net zu ermöglichen?

Wird System.Text.Json mit vollem .Net-Support über Nuget ausgeliefert? Es wäre sicherlich schön, eine vollständige Interoperabilität sicherzustellen und die Vorteile des vollständigen Frameworks zu nutzen.

System.Text.Json wurde kürzlich geändert, um netstandard2.0 Binärdateien für den Versand von OOB zu erzeugen; https://github.com/dotnet/corefx/pull/37129 :

Wenn möglich, sollten Sie auf .NET Core 3.0 abzielen und die system.Text.Json-APIs in der Box abrufen. Wenn Sie jedoch Netstandard2.0 unterstützen müssen (z. B. wenn Sie ein Bibliotheksentwickler sind), können Sie unser NuGet-Paket verwenden, das mit Netstandard2.0 kompatibel ist.

profitiert vom vollen Rahmen

Was sind das nochmal? 🤔

@khellang

Meine Vorliebe wäre ein Nuget mit mehreren Geschmacksrichtungen, einschließlich Full Framework (4,5 oder was auch immer akzeptables Minimum), Standard und Core. Die Verwendung von In-Box-Baugruppen ist vorzuziehen.

Das oben verlinkte Problem bezieht sich auf dieses Paket, wird jedoch nicht unterstützt:

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

Gibt es ein aktuelles unterstütztes Paket?

Meine Vorliebe wäre ein Nuget mit mehreren Geschmacksrichtungen, einschließlich Full Framework (4,5 oder was auch immer akzeptables Minimum), Standard und Core.

Warum würden Sie das bevorzugen? Wenn kein Multi-Target erforderlich ist, dh alle verwendeten APIs zum Standard gehören, ist es viel besser, nur ein einziges Target zu haben 😊

Gibt es ein aktuelles unterstütztes Paket?

Ich glaube, es ist noch nicht versendet. Die PR wurde vor Tagen zusammengelegt. Dieses Paket war früher ein Gemeinschaftsprojekt, das jetzt auf MS übertragen wurde.

@khellang es hängt von den Besonderheiten ab - ich habe eine allgemeine Aussage gemacht.

Wenn die Net-Standard-Version etwas von der Net-Core-Version weglassen müsste, was mit der Net-Vollversion möglich wäre, würde ich es vorziehen, wenn alle drei Flavors verfügbar wären. Ich vermute die gleiche allgemeine Argumentation wie die ursprüngliche Aussage aus dem oben verlinkten Problem, dass Benutzer die In-Box-Version bevorzugen.

Beim Hinzufügen einer Referenz zum Nuget-Paket wird automatisch die am besten kompatible Variante ausgewählt. Es ist also keine große Sache. Wenn die konsumierende Bibliothek Net-Standard ist, wird die Net-Standard-Variante ausgewählt.

Meine allgemeine Präferenz für In-Box-Varianten ist, dass ich, wenn ich goto definition schreibe, dekompilierte Quellen erhalte. Wenn ich goto definition auf Net-Standardbibliotheken verwende, sehe ich normalerweise nur Stub-Quellen, die NotImplemented Ausnahmen auslösen.

profitiert vom vollen Rahmen

Was sind das nochmal? 🤔

Viele Anwendungen verwenden .NET Framework nicht, weil sie .NET Core unbedingt meiden wollen, sondern weil .NET Core keine Option ist. Ich verwende .NET Core, wenn es eine Option ist; wenn ich auf Windows - Versionen niedriger als Windows Server 2012 (das Minimum .NET Core - Version 3.0) Ziel, ich habe .NET Framework verwenden. Auch wenn ich mir sicher bin, dass es eine sehr schmerzhafte Entscheidung war, die Unterstützung für Windows Server 2008 R2 und niedriger einzustellen, ist es eine sehr schmerzhafte Entscheidung für jedes Unternehmen mit zahlenden Kunden mit Servern, die sie nicht aktualisieren möchten / oft im Grunde von Grund auf neu erstellen nur damit wir ein etwas neueres Tool verwenden können.

Niemand wäre glücklicher als ich, wenn ich morgen aufhören könnte, .NET Framework zu verwenden, aber selbst mit all den WPF- und Windows Forms-Möglichkeiten in .NET Core 3.0 und darüber hinaus macht Microsoft dies mit seinen Supportrichtlinien praktisch unmöglich. Ich habe versucht, dies mit jedem zu besprechen, der bei Microsoft zuhören würde, aber leider habe ich noch nicht einmal eine E-Mail erhalten, die bestätigt, dass die Nachricht zugestellt wurde.

@JesperTreetop ganz zu schweigen von der fehlenden LTS-Unterstützung für die Versionen von .NET Core, die es wert sind, für ein Unternehmen verwendet zu werden;) .NET Core-Einführung, wenn wir eine 3.x-Version mit LTS-Unterstützung erhalten.

@marksmeltzer Der Blog-Beitrag Introducing .NET 5 von gestern zeigt, dass .Net Core 3.1 LTS sein wird und im November 2019 veröffentlicht werden soll.

Wird dieser neue JSON-Serializer F#-Typen unterstützen?

@rliman Nun, derzeit unterstützt es Guid oder Enum nicht, daher ist es noch ein langer Weg. Ich stimme zu, dass die vollständige Unterstützung für F#-Optionstypen, die ähnlich wie C# nullable sind, IMHO erforderlich sein sollte

Ich persönlich denke, dass dies eine überstürzte Lösung für eine schlechte architektonische Designentscheidung ist. Dies hätte schon vor langer Zeit getan werden sollen.... Jetzt wird es überall viel Schmerz verursachen... Von Bibliotheksentwicklern bis hin zu Unternehmensentwicklern.

Es gibt keinen einfachen Weg, dieses neue "Feature" zu "glätten".

MS versucht, ein Problem zu lösen, das sie in erster Linie verursacht haben. Und jetzt müssen alle den Preis zahlen.

Mit NET Core scheint der Wagen von Anfang an ein wenig zu "schnell" zu sein... Dieser reine "agile" Ansatz muss möglicherweise etwas langsamer werden und alle zu Atem kommen lassen.

Anscheinend sind diese "Features" (breaking changes) mit ASP.NET Core zur neuen Normalität geworden.

Meiner Meinung nach benötigt ASP.NET Core dringend eine Überarbeitung des Architekturentwurfsprozesses. Denn immer wieder machen wir diese "Wir werden es später reparieren"-Funktionen.

Ich entwickle mit ASP.NET Core seit den frühen Betas... Und es ist eine große Verbesserung gegenüber .NET.

Aber das MS-Team sollte einen Moment innehalten und darüber nachdenken, wie es hier das eigentliche Problem angehen kann: überstürzte und inkonsistente architektonische Designentscheidungen.

Gehen Sie einfach zurück und lesen Sie andere Threads ... Es scheint ein wiederkehrendes Thema zu sein.

Vielleicht ist es also an der Zeit, sich hinzusetzen und zu überdenken, was der beste Ansatz ist, um ein stabileres Produkt zu entwickeln.

Classic .NET ist vielleicht nicht so mächtig wie Core... Aber es ist seit 2.0 sehr stabil und konsistent.

Nur meine Meinung.

Hallo @suncodefactory ,
Ich erinnere mich, dass ppl vor einiger Zeit ms angeschrien hat, weil sie keine Open-Source-Bibliotheken verwendet haben, jetzt werden sie dafür verantwortlich gemacht :D
Aus meiner Sicht ist die Aspnet/Core MVC-API seit mvc1/2 sehr stabil! Der Grund, warum aspnet seit 2.0 stabil war, war, dass es sich nie geändert/verbessert hat 😄.
Um ehrlich zu sein, wenn Sie die erweiterten Funktionen einer Serialisierungsbibliothek verwenden, haben Sie die Möglichkeit, darüber nachzudenken und das Problem möglicherweise mit einer für die Aufgabe geeigneten Datenstruktur anzugehen, anstatt so zu tun, als würden alle Serialisierer alle Sprachfunktionen unterstützen das falsche Problem zu lösen und die Serialisierung falsch zu verwenden.
Klarheit, Abwärtskompatibilität und zukünftige Erweiterungen sind das, was meine serialisierbaren dtos antreibt, sehr unterschiedliche Kompromisse, die in gängigen Geschäftslogikobjekten verwendet werden (diese sind privat, haben viele Funktionen usw.).

Wir sind in der Lage, Microservices von Net Framework auf Linux (Net Core) ohne fast jeden Aufwand von Prduct-Teams umzustellen. Ich weiß nicht, wovon ihr redet. Microsoft leistet großartige Arbeit bei der Beschleunigung der Implementierung von Änderungen wie dieser, die längst überfällig waren.

Hallo @suncodefactory ,
Ich erinnere mich, dass ppl vor einiger Zeit ms angeschrien hat, weil sie keine Open-Source-Bibliotheken verwendet haben, jetzt werden sie dafür verantwortlich gemacht :D

Für mich geht es nicht um Bibliotheken von Drittanbietern... Es geht um architektonisches Design, das in diesem speziellen Fall fehlt oder schlichtweg falsch ist.

Außerdem habe ich nie über klassisches asp.net gesprochen... Ich habe über .NET Framework 2.0 gesprochen. Und der Grund, warum es stabil war, war nicht, dass es keine Verbesserungen gab, wie Sie fälschlicherweise behaupten (da .net Core auf .NET 4.6.1 basiert). Der Grund war, dass es gut geplant und gebaut war.

Wie gut aspnet Core im Vergleich zu klassischem asp.net mvc ist, hat nichts mit diesem speziellen Thread zu tun.

In diesem Thread geht es um eine bahnbrechende Änderung, die MS erneut ausliefern wird, ohne darüber gründlich nachzudenken.

Wir sind in der Lage, Microservices von Net Framework auf Linux (Net Core) ohne fast jeden Aufwand von Prduct-Teams umzustellen. Ich weiß nicht, wovon ihr redet. Microsoft leistet großartige Arbeit bei der Beschleunigung der Implementierung von Änderungen wie dieser, die längst überfällig waren.

Änderungen wie diese sollten überhaupt nicht passieren..... Sie sind also mit Breaking Changes zufrieden?

Und zu sagen, dass das Kernteam von asp.net beim Versand von Änderungen großartige Arbeit geleistet hat, ist einfach nicht wahr.

Ich entwickle seit Beta 3 mit asp.net Core und bin mir ziemlich sicher, dass der architektonische Designprozess fehlt.

Wie gut asp.net Core im Vergleich zu Classic ist ... Ich habe keine Einwände, da ich auch glaube, dass es besser ist als Classic.

Aber nur weil asp.net Core besser ist als klassisch, heißt das nicht, dass sie beim Architekturdesign eine großartige Arbeit leisten. Das sind zwei völlig unterschiedliche Themen.

Können wir diese Diskussion bitte auf die JSON-Funktionalität in .NET Core 3 beschränken?

Änderungen wie diese sollten überhaupt nicht passieren..... Sie sind also mit Breaking Changes zufrieden?

Es sollten also keine Verbesserungen vorgenommen werden? Warum sind Sie überhaupt Programmierer, wenn Sie nicht möchten, dass sich Software weiterentwickelt und wächst und besser wird?

@suncodefactory

Änderungen wie diese sollten überhaupt nicht passieren..... Sie sind also mit Breaking Changes zufrieden?

Ah, komm schon, du lässt es so klingen, als ob "Breaking Change" bedeutet, dass du dein Projekt verschrotten und von vorne anfangen musst.

Wie viele Breaking Changes können Sie zählen, die in ASP.NET Core 2.x/3.0 vorhanden waren und mehr als

• Verweis auf ein anderes Paket
• Verwenden eines anderen Namensraums
• Ändern von mehr als 5 Codezeilen
• Entfernen von 1-2 Codezeilen (dh Eigenschaften aus Optionsklassen)

??

@suncodefactory

In diesem Thread geht es um eine bahnbrechende Änderung, die MS erneut ausliefern wird, ohne darüber gründlich nachzudenken.

Wie ist das eigentlich eine _breaking_ Änderung? Die neuen JSON-APIs sind ein völlig neuer Satz von APIs, die in .NET Core eingeführt werden und die vorhandenes Material weder entfernen noch unterbrechen. Ja, Sie werden feststellen, dass irgendwann Dinge und Bibliotheken darauf umgestellt werden, da es verschiedene Optimierungsmöglichkeiten bietet, aber Sie sind nicht gezwungen, dies auf Ihren Code anzuwenden.

Wenn wir insbesondere über ASP.NET Core sprechen, obwohl _"das nichts mit diesem speziellen Thread zu tun hat"_, haben Sie dort die Wahl, Newtonsoft.Json weiterhin zu verwenden, wenn Sie auf einige seiner fortgeschritteneren Funktionen angewiesen sind. Ja, Sie müssen dafür etwas Code ändern, damit es funktioniert, aber ich halte das nicht für wirklich schädlich, wenn man bedenkt, dass Sie dies nur tun müssen, wenn Sie tatsächlich auf die neue Version aktualisieren möchten. Das ist jetzt das Schöne: Sie haben mehr Auswahl.

Wenn Sie dies aus irgendeinem Grund nicht mögen, können Sie sich gerne an das .NET Framework halten, das ein bekanntes, stabiles und festes Feature-Set ist. Das wird eine ganze Weile so bleiben, also können Sie sich voll und ganz darauf verlassen. Aber bitte hör auf, diesen Thread zu benutzen, um deine Anti-New-Stuff-Agenda zu verbreiten, wenn _"das nichts mit diesem speziellen Thread zu tun hat"_.

Zwei Fragen von einem EF Core-Benutzer.

1. Wird System.Text.Json unterstützen? Zirkelverweise können in EF Core-Daten auftreten, wenn Navigationslinks zwischen Klassen in beide Richtungen führen. Json.NET handhabt dies mit Einstellungen wie
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. Mit dem Aufkommen von Klassen im DDD-Stil mit privaten Settern und privaten Konstruktoren können System.Text.Json diese Klassentypen deserialisieren?

@JonPSmith IMO sollte es keine Rolle spielen. Sie sollten eine Entität niemals direkt serialisieren. Sie sollten eine Projektion serialisieren. Dadurch werden Zirkelverweise vermieden und nicht alle Daten verfügbar gemacht, insbesondere wenn Sie der Entität weitere Eigenschaften hinzufügen, die möglicherweise vertraulich sind.

@JonPSmith : Imho sind beide Anwendungsfälle sowohl aus bester Praxis als auch aus DDD-Sicht ungültig.

1. Ich habe noch nie eine Best Practice gesehen, die das direkte Deserialisieren von Entitäten empfiehlt (außer in den einfachsten Tutorial-Beispielen). Rundschreiben sind immer mit Kosten verbunden. Es erfordert ein Tracking von bereits bearbeiteten Objekten, das heißt: Speicherzuweisungen und zusätzliche CPU-Zyklen. Aber eines der Mail-Ziele der neuen JSON-Bibliothek ist es, genau diese Speicherzuweisungen zu vermeiden
2. Ungültig auch, da Sie nie in ein Domänenmodell serialisieren, insbesondere nicht, wenn Sie die Daten über eine Webanforderung wie einen WebApi-Aufruf erhalten. In DDD sollten Sie immer mit Ereignissen/Befehlen arbeiten, den Befehl an Ihre Webanwendung senden, die Entität aus dem Repository abrufen (und dehydrieren) (über ORM-Mapping oder EventSourcing), den Befehl anwenden, beibehalten.

Darüber hinaus ist die neue JSON-API für Hochleistungsszenarien gedacht. Für alles andere, wo Sie umfangreiche Funktionen benötigen, verwenden Sie (und sollten) weiterhin JSON.NET oder was auch immer Ihre Anforderungen erfüllt.

@suncodefactory Dies ist das Gegenteil einer Breaking Change. Derzeit wird JSON.NET in ASP.NET Core 2.2 sowohl vom Framework als auch vom Benutzercode verwendet. Dies kann zu Konflikten mit Ihrer eigenen Verwendung von Newtonsoft.Json führen. Wenn ASP.NET Core 3.0 zu JSON.NET 12.x verschoben wurde und dort ein Problem aufgetreten ist, das Ihre Anwendung beschädigt hat, liegt ein Problem vor.

Sehen Sie sich zum Beispiel Microsoft.Extensions.Configuration.Json 2.2.0 an - es hat eine Abhängigkeit von Newtonsoft.Json 11.0.2. Das ist ein Konfigurationspaket; nichts mit HTTP-Anforderungsbehandlung oder ASP.NET Core MVC zu tun. Oder schauen Sie sich Microsoft.IdentityModel.Protocols.OpenIdConnect an , das es für die Verarbeitung von JSON-Webtoken verwendet; das ist ein heißer Weg, der so viel Leistung wie möglich benötigt. JSON.NET ist keine langsame Bibliothek, aber es schafft ein Gleichgewicht zwischen Leistung, Funktionsumfang und Unterstützung für eine Vielzahl von Benutzerszenarien. Die neue JSON-Bibliothek von Microsoft muss dies nicht tun, da JSON.NET existiert. So kann er sich auf das Handling der absoluten Basics mit maximaler Performance konzentrieren.

.NET hatte schon immer eine eigene JSON-Serialisierungslösung in System.Runtime.Serialization.Json , aber in der Hochleistungswelt von .NET Core ist sie keine sehr gute. Ich möchte sicherlich nicht, dass es aufgerufen wird, um die Anmeldeinformationen bei jeder eingehenden Anfrage zu überprüfen. Eine neue JSON-Bibliothek mit moderner UTF-8-Datenverarbeitung und minimalen Zuweisungen ist sehr willkommen.

Sie können in Ihrer Anwendung weiterhin auf Newtonsoft.Json verweisen und es wie bisher als Deserialisierungs-/Serialisierungspipeline für Anforderungs-/Antwortdaten verwenden. Und von nun an können Sie dies tun, ohne sich Gedanken darüber machen zu müssen, von welcher Version das Core-Framework abhängt. Das ist ein Gewinn für alle.

Danke @phillip-haydon und @TsengSR für deine Gedanken. Ich habe gefragt, ob diese Funktionen unterstützt werden und Sie sagen, dass dies nicht der Fall ist, die verstehen und akzeptieren. Ich werde Json.NET weiterhin für den Fall verwenden, in dem ich EF Core-Klassen serialisieren/deserialisieren muss.

Übrigens. Ich habe einen triftigen Grund für die Serialisierung/Deserialisierung von EF Core-Entitätsklassen im DDD-Stil. Ich habe eine Bibliothek, die eine Funktion enthält, die ich Seed from Production nenne, die es Entwicklern ermöglicht, einen Snapshot von Daten aus einer Produktionsdatenbank zu erstellen, alle privaten Daten zu anonymisieren und dann eine neue Datenbank mit dem Snapshot zu starten.

Ich brauchte diese Funktion für einen meiner Kunden und anstatt nur für sie zu schreiben, baute ich sie in meine Open-Source-Bibliothek EfCore.TestSupport ein, damit andere sie verwenden können (und mein Kunde musste mich nicht dafür bezahlen).

Gibt es einen Plan, [DataContract] , [DataMember] und Freunde zu unterstützen?

Heutzutage ist dies eine Möglichkeit, zu definieren, wie Typen serialisiert/deserialisiert werden sollen (zB der Feldname) auf eine Weise, die keine Abhängigkeit von einer Serialisierungsbibliothek für das Projekt mit sich bringt, das sie verwendet.

Das aktuelle JsonNamingPolicy nur einen String, daher gibt es keine Möglichkeit, die Attribute des Mitglieds zu überprüfen.

Hi.
Wir haben gerade versucht, unsere Mikrodienste auf DotNet Core 3 Preview 6 umzustellen, und wir können unsere unveränderlichen Referenztypen nicht deserialisieren: Klasse mit unveränderlichen Eigenschaften (keine Setter) und nur einem Konstruktor zum Festlegen aller Eigenschaften. Json.net behandelt diese Klassen korrekt.
Ist dies ein Problem der System.Text.Json-API oder ist dies ein Plan, es zu unterstützen?
Danke für eure Antworten

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

Danke @khellang.
Eine Unterstützung ist zwar geplant, jedoch nicht für das 3.0-Release.
Es scheint möglich zu sein, Json.net weiterhin mit DotNet Core 3 zu verwenden, aber ich weiß nicht, wie es geht (das Hinzufügen von Paketreferenzen reicht nicht aus). Gibt es eine Möglichkeit das zu tun?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

Danke für eure Hilfe Jungs.
Es klappt !
Ich habe den Migrationsleitfaden verpasst, in dem alles erklärt wird:

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

IMO json.net ist halb gebacken und es war verfrüht, es zum Standard (dh für Signalr) zu machen, der vorhandenen Code bricht.

Auf der anderen Seite ist die Migration von .NET Core 2.2 auf 3.0 ein großes Versions-Upgrade und selbst wenn das .NET Core-Team die semantische Versionierung nicht strikt befolgt, würde ich erwarten, dass beim Upgrade von einer Version auf eine andere ohne explizite Änderungen Probleme auftreten (wie das explizite Hinzufügen der Bibliothek von Newtonsoft in die Pipeline)

Abschluss angesichts der Tatsache, dass dies eine Ankündigung und kein Problem ist

Obwohl die Community viele Stimmen gegen Verbesserungen hat, ist die schlechte Geschwindigkeit als neues Hochleistungs-Framework inakzeptabel.

Ich weiß, es wurde schon einmal gesagt, aber ich möchte auch meinen Wunsch hinzufügen.

Es wäre wirklich großartig, wenn wir unveränderliche Objekte haben könnten. Ich weiß, dass es möglich ist, indem man Json.NET zur MVC-Pipeline hinzufügt, aber in meinem Fall schlagen alle meine Tests fehl, da ich ReadAsAsync<> das jetzt irgendwo in einer Peer-Abhängigkeit von Microsoft.AspNet.WebApi.Client implementiert ist System.Text.Json

Wir stellen unseren Kunden die .NET Standard Class-Bibliothek zur Verfügung, damit sie unsere Bibliothek verwenden können, um auf jeder Plattform zu arbeiten, die .NET Standard unterstützt. Wir müssen System.Text.Json in unserer Klassenbibliothek verwenden. Wie sieht der Plan aus, System.Text.Json in .NET Standard zu unterstützen?

@alsami

Es wäre wirklich großartig, wenn wir unveränderliche Objekte haben könnten.

Benötigen Sie nur die Möglichkeit, andere daran zu hindern, es zu mutieren, oder benötigen Sie auch die Möglichkeit, neue Instanzen zu erstellen, bei denen Teile intelligent ersetzt werden (wie unveränderliche Sammlungen und Roslyn)? Wenn Sie Ersteres benötigen, sind wir mit den kommenden JsonDocument DOM-APIs für Sie da.

@mwoo-o

Wie sieht der Plan aus, System.Text.Json in .NET Standard zu unterstützen?

Es ist als NuGet-Paket für .NET Standard 2.0 verfügbar :

@terrajobst

Vielen Dank. Wann wird dieses System.Text.Json in das .NET Standard SDK aufgenommen?
Wird der .NET-Standard 3.0 (oder einige andere spätere Release-Versionen) das Paket System.Text.Json enthalten? Wird dies in der Produktionsversion des .NET Core 3.0 SDK passieren?

@terrajobst

Gibt es Pläne, damit die Deserialize-Methode mit PipeReader funktioniert? Oder fügen Sie die Patch-Methode hinzu, die in Streaming-Szenarien verwendet werden kann, in denen nicht alle Daten vorliegen, wenn wir mit der Deserialisierung beginnen.

Hier ist eine vereinfachte Version der vorgeschlagenen 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

Fähigkeit, andere daran zu hindern, es zu mutieren

Nur dies derzeit. Ist eigentlich nur für 'Datentransfer-Objekte'. Großartige Neuigkeiten!

@mwoo-o

Vielen Dank. Wann wird dieses System.Text.Json in das .NET Standard SDK aufgenommen?
Wird der .NET-Standard 3.0 (oder einige andere spätere Release-Versionen) das Paket System.Text.Json enthalten? Wird dies in der Produktionsversion des .NET Core 3.0 SDK passieren?

Es gibt kein .NET-Standard-SDK. .NET Standard ist eine API-Oberfläche, die auf allen unterstützten Plattformen verfügbar ist. Sie können System.Text.Json in jeder Anwendung ausliefern, die auf den unterstützten Plattformen läuft, die vom .NET-Standard unterstützt werden, siehe .NET-Implementierungsunterstützung .

@TsengSR

Es gibt kein .NET-Standard-SDK. .NET Standard ist eine API-Oberfläche, die auf allen unterstützten Plattformen verfügbar ist.

Nun, es gibt einen Projekttyp, mit dem Sie die APIs verwenden können. Ich denke, @mwoo-o fragt, ob wir Pläne haben, System.Text.Json zu .NET Standard hinzuzufügen. Die Antwort ist nein. Jetzt planen wir, dies als NuGet-Paket zu belassen.

Es ist schrecklich. Zu wenige Funktionen, um im Projekt angewendet zu werden.