Runtime: Masa depan JSON di .NET Core 3.0

Ini bagus. Saya mendukung parsing json yang lebih cepat dan lebih sedikit.

Apakah akan ada diskusi tentang fitur-fitur dari json.net yang akan didukung oleh json apis baru? Jika ada, saya pikir dua fitur utama yang muncul dalam pikiran adalah mengganti nama/menyelubungi properti dan mengabaikan properti nol.

Apakah akan ada diskusi tentang fitur-fitur dari json.net yang akan didukung oleh json apis baru?

Ya. Kami telah melakukan beberapa pemikiran awal bahwa kami akan bermigrasi ke CoreFx. Ini akan menjadi fitur yang dirancang & dibangun di tempat terbuka seperti biasa. Selain itu, saya telah menghubungi penulis dari banyak perpustakaan JSON populer dan mengundang mereka untuk meninjau draf awal pengumuman ini. Harapan saya adalah kita dapat bekerja sama untuk membuat komponen JSON yang solid untuk platform sambil juga menjaga ekosistem di atasnya (seperti ASP.NET Core) dapat dipasang untuk memungkinkan orang lain. Pada akhirnya, konsumen yang berbeda akan memiliki tujuan yang berbeda dan dapat memasang pustaka yang berbeda berarti Anda bisa mendapatkan fleksibilitas maksimum dalam memilih komponen yang memiliki biaya/manfaat terbaik untuk aplikasi Anda .

Hai @terrajobst. Akankah JSON baru muncul sebagai permukaan API standar bersih, atau hanya diintegrasikan ke dalam Core untuk saat ini?

Hai @terrajobst. Akankah JSON baru muncul sebagai permukaan API standar bersih, atau hanya diintegrasikan ke dalam Core untuk saat ini?

Ya, pertanyaannya adalah kereta rilis mana yang bisa ditangkapnya. 2.1 mungkin terlalu dini.

Jadi bit parsing JSON yang dimasukkan ke dalam kerangka kerja direncanakan akan tersedia ketika v3.0 masuk ke RTM atau hanya integrasi Apis di ASP.NET Core yang akan selesai (hanya dengan satu implementasi - JSON.NET) yang akan dapat ditukar di a nanti?

Rencana untuk 3.0 adalah sebagai berikut:

1. API JSON berperforma tinggi bawaan. Pembaca/penulis tingkat rendah, pembaca/penulis berbasis Stream , dan pembuat serial.
2. ASP.NET Core dapat dicolokkan ke komponen JSON.

Ada pertanyaan terbuka tentang apa yang akan digunakan oleh templat untuk ASP.NET di 3.0. Bergantung pada kesetiaan yang dapat kami berikan pada 3.0, kami mungkin meminta mereka menarik paket integrasi Json.NET. Namun, tujuannya adalah untuk memberikan fidelitas & paritas yang cukup untuk hanya bergantung pada yang built-in secara default.

Terima kasih - itu membantu menjernihkan segalanya. 👍

Dan beberapa pertanyaan tambahan!

Jika paket integrasi digunakan, apakah akan digunakan di seluruh pipa ASP.NET Core atau hanya di beberapa tempat?
Saya berasumsi Kestrel akan selalu menggunakan pembaca/penulis internal.

Apakah ergonomi Api menjadi:

• Berikan integrasi hanya jika Anda ingin meningkatkan set fitur bawaan.
• Menyediakan paket integrasi selalu tetapi satu akan built-in, mengintegrasikan pembaca/penulis tingkat rendah ke fungsionalitas tingkat yang lebih tinggi.

Dengan asumsi bahwa parser baru ini akan digunakan untuk semua hal JSON bawaan seperti appSettings.json , dapatkah saya mengajukan permintaan awal agar komentar didukung?

Terima kasih.

Ini adalah berita yang luar biasa! Pertanyaan singkat: Paket apa yang akan bergantung pada perpustakaan ini?

Mengapa menemukan kembali roda yang diuji oleh pelanggan produksi? Jika ada masalah dengan Json.Net, kirimkan saja PR karena itu open source.

Saya kira masalah dengan Json.NET adalah bahwa itu tidak dimiliki oleh Microsoft, jadi itu harus diganti. Oh tapi ada yang sudah ada di System.Runtime.Serialization, yang disebut DataContractJsonSerializer. Bisakah Anda menggunakannya, atau apakah sangat menyenangkan untuk membuat kode API baru, DIY, sehingga tidak dapat dihindari?

Alasan saya tidak terlalu senang dengan ini adalah bahwa Json.Net mendukung kasus-kasus tepi seperti misalnya Serikat Terdiskriminasi F#. Tidak terlalu baik, tetapi pada tingkat yang dapat diterima oleh pengembang. Alih-alih, setiap API baru biasanya melupakan hal lain selain kasus penggunaan situs web ASP.NET.

@markrendle Ada pengaturan keikutsertaan di JsonReader (sedang dalam proses) untuk mengizinkan komentar. Sistem konfigurasi kemungkinan akan mengaktifkan pengaturan itu secara default.

@ Thorium Apakah Anda benar-benar membaca OP? Ini menjelaskan mengapa bukan JSON.NET, dan bahwa JSON.NET akan terus didukung secara resmi dengan paket tambahan.

@JamesNK 😄

@ Thorium Json.NET tidak akan hilang. Anda tidak kehilangan apa-apa. Ini adalah opsi lain untuk skenario kinerja sederhana dan tinggi.

@ Thorium Json.NET tidak akan hilang. Anda tidak kehilangan apa-apa. Ini adalah opsi lain untuk skenario kinerja sederhana dan tinggi.

Bagaimana Json dihasilkan agar kompatibel ke belakang?

Misalnya, saya menggunakan SignalR yang menggunakan Json.NET di latar belakang. Sekarang, akankah serikat terdiskriminasi F# saya membuat serial ke struktur serupa sehingga saya tidak akan melawan masalah dengan Azure Signalr Service (backplane) baru yang melemparkan pengecualian runtime karena membuat serialisasi struktur secara berbeda dari perpustakaan SignalR server saya saat ini?

Saya berharap orang lain akan mengambil API baru dengan cepat. Melihatmu ,

Apakah Anda berencana memasukkan kelas seperti JObject dan dukungan untuk dinamis atau ini di luar cakupan fitur ini?

Saya sarankan melihat di salah satu lib ini:

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

ini bisa menjadi cara yang sangat bagus untuk mendapatkan inspirasi.

Akankah DataContractJsonSerializer pembaca/penulis baru ini digunakan secara internal ?

Saya telah menghubungi penulis dari banyak perpustakaan JSON populer dan mengundang mereka untuk meninjau draf awal pengumuman ini. Harapan saya adalah kita dapat bekerja sama untuk membuat komponen JSON yang solid untuk platform sambil juga menjaga ekosistem di atasnya (seperti ASP.NET Core) dapat dipasang untuk memungkinkan orang lain.

Apakah ada alasan mengapa perpustakaan JSON paling populer ke-2 setelah JSON.NET - ServiceStack.Text yang telah di -refactored untuk dibangun di SpanLebah telah dikecualikan? ServiceStack.Text serializers adalah apa yang digunakan untuk mendukung ServiceStack yang merupakan salah satu "Alternative .NET Core compatible Web Framework" paling populer yang

Mungkin perlu meninjau kinerja tinggi berlisensi MIT https://github.com/neuecc/Utf8Json

Ini pasti yang kita butuhkan... saran saya untuk nama kelas utama, gunakan saja " Json ".

@terrajobst saya bertanya-tanya kapan ini akan terjadi ...

Saya selalu bertanya-tanya mengapa JSON.Net ditambahkan sebagai ketergantungan langsung daripada abstraksi (bahkan mengingat itu adalah paket JSON de-facto untuk ekosistem .Net).

Namun, saya pikir menambahkan abstraksi untuk JSON-only entah bagaimana merupakan pemotretan di kaki Anda. Saya pikir abstraksi _serializer_ seperti yang kita miliki di Orleans IExternalSerializer dalam bentuk Microsoft.Extensions.Serialization atau sesuatu akan lebih efektif...

Apakah ada alasan khusus mengapa make hanya JSON? Saya melihat kasus lain di mana orang dapat memasang serializer jenis lain ...

@galvesribeiro Sesuatu seperti IOutputFormatter / IInputFormatter ?

@yaakov-h tidak menyadarinya... Benarkah?

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

Okey... masuk akal sekarang. Jadi di mana abstraksi _new_ JSON-only ini berperan?

Keputusan untuk memulai usaha ini juga merupakan bukti ketidakefisienan System.String (UTF-16 String).
Saya pikir kait JSON baru yang akan mengabstraksi semua penanganan json antara asp.net dan perpustakaan json akan terlihat jauh lebih baik jika Anda menangani tugas untuk membuat BaseType string utf-8 terlebih dahulu.
-> Mungkin membuat System.Utf8String

Ya... Saya ingat @migueldeicaza mengatakan beberapa waktu lalu bahwa suatu hari nanti, dia akan membuat .Net menggunakan utf8 string 😄

@jges42 @galvesribeiro Proposal untuk menambahkan Utf8String adalah https://github.com/dotnet/corefx/issues/30503. Tampaknya itu juga direncanakan untuk .Net Core 3.0.

Akankah JSON API baru ini memiliki jalur kode khusus untuk Utf8String dan char / string , atau apakah pengoptimalan melibatkan membalik status quo, sehingga semua yang bukan UTF-8 harus ditranskodekan ke sana? (Ini tidak selalu melibatkan biaya besar karena hampir tidak ada yang asli UCS-2 UTF-16 string dan masih harus disesuaikan/dipertanggungjawabkan, saya hanya mencoba untuk mendapatkan ide tentang Permukaan API. Melakukan ini agar Kestrel lebih efisien adalah wajar; Saya hanya berharap desainnya mempertimbangkan lebih banyak klien daripada Kestrel.)

@galvesribeiro
Sebenarnya saya pikir Anda mengangkat poin yang bagus. Saya pikir membuat Kerangka Serialisasi yang efisien dan Decoder/Encoder Json yang efisien adalah dua jenis masalah. Saya tahu ada beberapa cara untuk menandai struct sebagai Serializable tetapi saya belum pernah melihatnya digunakan untuk Serialisasi Json.

Proyek Serde dari Rust sebenarnya memiliki konsep yang bagus dengan membagi masalah menjadi 2 masalah:

1. Serialize/Deserialize (Sifat yang mirip dengan Antarmuka di C #) yang berarti semua jenis yang mewarisi dari Antarmuka ini dapat Serialized/Deserialized
2. Serializer/Deserializer adalah implementasi khusus format.

Suatu tipe dapat mengimplementasikan Serialize/Deserialize dengan tangan atau dengan makro (yang dapat dilihat sebagai beberapa bentuk plugin kompiler) yang menghasilkan kode yang diperlukan untuk mengimplementasikan Ciri-ciri tersebut. Jika suatu tipe berisi tipe anak yang tidak mengimplementasikan Sifat-Sifat itu, Ia bahkan akan memperingatkan pada Waktu Kompilasi. Ini adalah konsep yang bagus secara keseluruhan karena itu berarti Anda hanya dapat menulis beberapa objek data dan (de)serialize untuk format yang didukung. Menulis format jauh lebih mudah dengan cara ini.

Saya tidak berpikir semua cara Serde akan berfungsi untuk C # karena itu tidak benar-benar menawarkan atribut khusus jenis apa pun yang mungkin penting untuk beberapa struktur data. Jadi harus ada beberapa pekerjaan yang dilakukan untuk ini. Juga mempertimbangkan Kompilasi AoT akan sangat penting untuk beberapa proyek (WASM) Itu juga harus berfungsi dengan baik dengannya.

Berikut ini tautan ke dokumen Serde untuk membuatnya lebih jelas (Klik 4 Sifat bawah untuk melihat konsepnya):
https://docs.serde.rs

@mythz Lisensi ServiceStack.Text adalah AGPL dengan beberapa pengecualian FOSS - mungkin akan mencegah orang menggunakannya dalam perangkat lunak berpemilik. Juga saya pikir itu memerlukan izin dari hukum bagi karyawan Microsoft untuk bahkan menyentuhnya, dan setiap karyawan yang telah melihat sumbernya mungkin dilarang bekerja di perpustakaan JSON lain atau teknologi terkait.

@poizan42 ServiceStack.Text memiliki lisensi ganda dengan OSS/lisensi komersial gratis untuk digunakan baik di OSS maupun proyek komersial sumber tertutup. Tetapi lisensi kode sumber tidak relevan karena MS sedang mengembangkan implementasinya sendiri.

Pernyataannya adalah bahwa MS berkolaborasi dengan "ekosistem" untuk mengembangkan API serializer JSON "pluggable" - jika ServiceStack yang telah dalam pengembangan aktif dalam hampir satu dekade yang merupakan salah satu dari sedikit suite Perangkat Lunak .NET independen yang telah berhasil mempertahankannya memiliki komunitas sehat independen di luar MS dalam masa hidupnya, yang mempertahankan serializer JSON paling populer ke-2 setelah JSON.NET dan apa yang tampaknya menjadi Kerangka Web yang paling populer ke-2 yang dikembangkan secara aktif (di luar MS), yang berjalan di lebih banyak platform daripada MS mana pun kerangka kerja web tidak dianggap sebagai bagian dari "ekosistem" yang terutama dipengaruhi oleh perubahan ini, saya ingin tahu apa "ekosistem" yang mereka maksud dan mengapa kita dikecualikan dan berapa banyak orang lain yang dikecualikan karena mereka tidak dianggap sebagai bagian dari "ekosistem".

Aku tidak mengerti semua kebencian ini. Asp.net memaksa Anda untuk menggunakan versi json.net tertentu. Mereka mengubahnya sehingga Anda dapat memilih parser JSON mana pun yang Anda inginkan (atau mencampurnya), dan ada OOB default. ServiceStack seharusnya senang dengan perubahan ini dan memantau serta memberikan umpan balik tentang perkembangan ini, daripada hanya mengeluh tentang bagaimana hal itu diabaikan, yang jarang merupakan cara efektif untuk menumbuhkan semangat komunitas yang baik. Saya pribadi mengenal banyak anggota tim .net dan saya yakin mereka tidak bermaksud jahat. Mereka semua adalah pendukung besar OSS dan kerja komunitas.
Secara pribadi, lisensi turunan GPL apa pun akan menjadi penolakan otomatis yang besar bagi saya. Apache atau MIT untuk saya dan pelanggan saya atau kami akan melanjutkan. Tidak ada lisensi ganda yang misterius.

Asp.net memaksa Anda untuk menggunakan versi json.net tertentu

Tidak. Bagaimana?

Aku tidak mengerti semua kebencian ini.

Diperbantukan!

Saya pribadi senang bahwa kami akhirnya dapat menggunakan serializer pilihan kami tanpa harus mengunduh JSON.Net hanya untuk tidak menggunakannya, tetapi masih perlu mengirimkannya karena ASP.Net memiliki referensi keras ke perpustakaan.

(Plug tak tahu malu: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

Aku tidak mengerti semua kebencian ini.

Karena Anda tidak membaca atau memahami komentar saya. Cobalah untuk menanggapi langsung komentar saya (yaitu menggunakan fitur kutipan) daripada membuat narasi Anda sendiri.

Mereka mengubahnya sehingga Anda dapat memilih parser JSON yang Anda inginkan (atau mencampurnya)

Jadi seperti "campuran" ajaib, mereka akan secara otomatis memilih opsi API dan plugability paling optimal yang dapat dipasang oleh serializer .NET yang ada langsung masuk/keluar dan campur ke dalam opsi penyesuaian internal mereka dengan format kawat menjadi persis sama dan semuanya hanya akan bekerja di semua serializer? Dalam hal ini Anda benar, tidak diperlukan pengujian kolaborasi atau integrasi sebelum API dipadatkan. Atau mungkin implementasi Serializer lebih bernuansa dengan berbagai perbedaan dan pendapat dan semuanya tidak hanya akan berfungsi, tidak semua opsi penyesuaian akan diterapkan dengan tepat, format kawat tidak akan sama dan tidak akan mungkin untuk dicapai interop sempurna antara implementasi yang berbeda. The "plugability" yang Anda abaikan membuat perbedaan besar yang dapat menentukan berapa banyak penulisan ulang yang harus kita lakukan dan apakah mungkin untuk mendukung implementasi yang sudah ada dan yang baru ini atau tidak.

ServiceStack seharusnya senang dengan perubahan ini dan memantau serta memberikan umpan balik tentang perkembangan ini,

Yang mana kami tidak diberi kesempatan untuk melakukannya (atau masih tahu bagaimana melakukannya), tetapi terima kasih telah memberi tahu saya bagaimana perasaan saya. Saya lebih suka menilai fungsionalitas, interoperabilitas, dan kompatibilitas perpustakaan sebelum dapat menilai kekuatan masing-masing. Mungkin itu akan menjadi hebat dan akan mudah untuk mendukung kedua implementasi tetapi dari pengalaman beroperasi dengan implementasi serializer yang berbeda penuh dengan ketidakcocokan dan kasus sudut dan ketergantungan pada implementasi dan fitur khusus serialisasi yang berbeda. Prediksi saya adalah bahwa interop antara JSON.NET dan impl default akan sangat bagus karena itulah tujuan desain mereka dan apa yang sedang diuji tetapi pembuat serial lainnya tidak akan seberuntung itu.

daripada hanya mengeluh tentang bagaimana hal itu telah diabaikan, yang jarang merupakan cara yang efektif untuk menumbuhkan semangat komunitas yang baik.

Saya menantang pernyataan mereka bahwa mereka telah mengembangkan ini bekerja sama dengan "ekosistem", .NET memiliki sejarah mematikan ekosistem yang ada setiap kali mereka menggabungkan perpustakaan "default", yang saya juga harapkan akan terjadi di sini (saya berjuang untuk mengingat saat ketika bundling default pernah membantu ekosistem). Namun terlepas dari itu, kita perlu mengembangkan integrasi tanpa batas dengan apa pun yang mereka rilis yang saya ingin dapat akses dan masukan sebelum API dibekukan. Tapi tidak apa-apa, saya tidak berharap Anda peduli bagaimana hal itu memengaruhi kerangka kerja/perpustakaan yang ada yang perlu mendukung implementasi yang ada dan yang akan datang, Anda mungkin hanya khawatir jika JSON.NET tetap didukung atau tidak karena hanya itu yang memengaruhi Anda, tetapi coba pegang asumsi Anda dan beri tahu kami bagaimana perasaan kami tentang menyerap perubahan yang mengganggu seperti ini.

saya berjuang untuk mengingat saat ketika bundling default pernah membantu ekosistem

Oh ayolah!

(Selebihnya saya sebagian besar setuju dengan sentimen Anda)

@mythz Saya terkejut bahwa ini menyebabkan masalah karena hari ini kami menggabungkan perpustakaan JSON pihak ke-3 lainnya ke dalam kerangka kerja. Hanya ada beberapa tempat di mana kami memanggang JSON dan kebanyakan dari mereka memiliki model penyedia yang akan diganti oleh pengguna secara wajar (seperti pemformat MVC).

Prediksi saya adalah bahwa interop antara JSON.NET dan impl default akan sangat bagus karena itulah tujuan desain mereka dan apa yang sedang diuji tetapi pembuat serial lainnya tidak akan seberuntung itu.

Saya sudah dapat memberi tahu Anda bahwa apa yang akan kami kirimkan tidak akan mendukung keseluruhan fitur yang didukung JSON.NET. Jadi itu sudah tidak benar dan sebenarnya, kami berharap itu kurang mampu dalam beberapa kasus (karena alasan kinerja dan ruang lingkup).

Pluggability sebagian besar sudah ada hari ini dan kami memiliki implementasi JSON.NET default di mana-mana. Ini hanya mengubah default itu menjadi serializer JSON baru ...

@abatishchev

Saya benar-benar tidak dapat mengingatnya, kapan menanamkan atau mengadopsi implementasi default dalam kerangka dasar (atau proyek) mereka bermanfaat bagi ekosistem sekitar yang ada? Setiap kali saya melihatnya dibundel misalnya NuGet, MVC, ORM, Pengujian Unit, API Web, dll, itu hanya memiliki efek yang merugikan, secara efektif mengambil oksigen dan motivasi untuk bersaing dalam ruang itu.

Ada saat-saat seperti di mana perpustakaan yang bersaing seperti ASP.NET Ajax gagal bersaing di mana mereka akhirnya meninggalkannya dan mengadopsi jQuery, tetapi saya tidak ingat waktu di mana itu pernah membantu? Catatan: Ini hanya pengamatan saya dari mengikuti .NET setelah beberapa tahun, mungkin ada contoh dan saya ingin tahu beberapa? tetapi dari POV saya, efek default MS memiliki efek merugikan pada ekosistem fungsi yang ada yang digantikannya.

Manfaat @mythz bagi pengguna dari memiliki solusi default oleh Microsoft tidak sama dengan manfaat bagi penulis solusi alternatif. EF adalah ORM terbaik di dunia .NET dan MSTest lebih baik daripada NUnit saat itu. Menurut pendapat saya.

Tapi mari kita tidak membanjiri dan tetap berpegang pada subjek. Bersulang!

@davidfowl Ini hanya mengubah default itu menjadi serializer JSON baru ...

Saya ingin mengusulkan agar tidak ada serializer default dan mengharuskan implementasi diunduh. Jika harus ada default, apakah itu akan dimasukkan ke dalam kerangka kerja atau beberapa perpustakaan terpisah (seperti yang terjadi saat ini)?

Saya ingin mengusulkan agar tidak ada serializer default dan mengharuskan implementasi diunduh. Jika harus ada default, apakah itu akan dimasukkan ke dalam kerangka kerja atau beberapa perpustakaan terpisah (seperti yang terjadi saat ini)?

Itu tidak masuk akal karena pengalamannya akan di bawah standar. Setiap platform modern memiliki JSON bawaan.

@davidfowl Tidak menyebabkan masalah sekarang karena belum dirilis, tetapi kami masih perlu menilai gangguan dan ruang lingkup pekerjaan yang akan ditimbulkannya. Berapa banyak upaya yang diperlukan untuk mendukungnya dengan mulus, apakah kami dapat menerapkan penyesuaian ke impl baru untuk mendukung perilaku kami yang ada, apakah kami dapat mendukung model dan API penyesuaian baru, apakah kami dapat menyesuaikan serializer kami untuk mendukung konfigurasi default/format kawat akan API baru dapat mendukung .NET Core dan .NET Framework - sementara jelas ASP.NET Core 3 akan meninggalkan .NET Framework, tidak jelas apakah API baru akan menggunakan .NET Framework. Hanya tipe .NET Core yang akan melarang kami untuk terus dapat mendukung .NET Core dan .NET Framework.

Saya sudah dapat memberi tahu Anda bahwa apa yang akan kami kirimkan tidak akan mendukung keseluruhan fitur yang didukung JSON.NET. Jadi itu sudah tidak benar dan sebenarnya, kami berharap itu kurang mampu dalam beberapa kasus (karena alasan kinerja dan ruang lingkup).

Saya hanya mengharapkannya untuk mendukung subset fitur JSON.NET, misalnya apakah JSON.NET akan mendukung format kawat default? (Saya berasumsi ya). Akankah impl baru mengadopsi format serialisasi JSON.NET jika memungkinkan (juga dengan asumsi ya).

Berapa banyak upaya yang diperlukan untuk mendukungnya dengan mulus, apakah kami dapat menerapkan penyesuaian ke impl baru untuk mendukung perilaku kami yang ada, apakah kami dapat mendukung model dan API penyesuaian baru, apakah kami dapat menyesuaikan serializer kami untuk mendukung konfigurasi default/format kawat akan API baru dapat mendukung .NET Core dan .NET Framework.

@mythz Saya tidak mengikuti beberapa ini. Saya mencoba mencari tahu seberapa banyak ini membahas API yang ada vs bagaimana mereka akan dikonsumsi. Mungkin kita bisa melihat beberapa skenario konkret?

@mythz satu-satunya perhatian nyata yang saya lihat untuk servicestack adalah jika api baru ini tidak didukung pada .net framework classic, dengan cara itu servicestack tidak akan dapat mendukung .net core dan .net classic, sebagai pelanggan, paket tergantung pada perpustakaan tersebut tidak akan tersedia di .net framework full . Apakah itu kekhawatiran Anda? saya bertanya karena kekhawatiran Anda sebagai contoh konkret tidak jelas.

Juga ini adalah proposal pada tahap awal dan tujuan yang ingin dicapai terlihat cukup menjanjikan. Kritik yang membangun selalu baik untuk setiap proyek oss.

Manfaat @mythz bagi pengguna dari memiliki solusi default oleh Microsoft tidak sama dengan manfaat bagi penulis solusi alternatif.

Dengan ekosistem, saya mengacu pada ekosistem/komunitas perpustakaan .NET di sekitarnya (yang mungkin juga merupakan "ekosistem" dalam OP yang dirujuk) yang menggantikannya yang saya juga berpendapat Pengguna .NET juga mendapat manfaat dari ekosistem yang sehat dengan berbagai pilihan dan lebih banyak kompetisi (sebagaimana ciri ekosistem yang lebih sehat seperti Python, Java, Node, Ruby, PHP, dll).

EF adalah ORM terbaik di dunia .NET

Segera setelah EF dirilis, dengan cepat mengambil sebagian besar pangsa pasar ORM sementara lebih dari 6x lebih lambat dari NHibernate sementara bisa dibilang mendukung lebih sedikit fitur, kutipan dari wawancara InfoQ 2012 saya:

Upaya terbaru mereka pada Lapisan Akses Data ORM dalam Kerangka Entitas telah berdampak negatif pada komunitas ORM NHibernate yang dulunya menonjol dan berkembang juga. Meskipun beberapa kali lebih lambat dari setiap Open Source .NET ORM lainnya , EF telah berhasil menarik lebih banyak unduhan daripada gabungan semua

Ingatlah ini adalah sebelum .NET Core di mana kinerja sekarang menjadi prioritas utama, tetapi ini adalah contoh historis dari efek merugikan default MS pada ekosistem/komunitas yang ada. IMO itu cukup banyak menerima apa yang terjadi pada komunitas yang ada ketika MS memperkenalkan default itulah sebabnya ada dorongan baru-baru ini untuk kembali dari default pengiriman yang bersaing dengan IdentityServer dan AutoMapper.

dan MSTest lebih baik daripada NUnit saat itu.

IMO tidak pernah (dan dukungan R# dari NUnit selalu menjadi AFAICR yang sangat baik) dan fakta bahwa kami tidak dapat menjalankannya lintas platform di Mono berarti perpustakaan yang mendukung lintas platform di Mono (sebelum .NET Core) tidak dapat digunakan dia.

Tapi mari kita tidak membanjiri dan tetap berpegang pada subjek. Bersulang!

Saya juga tidak ingin membajak utas ini, tetapi perlu menyatakan mengapa saya tidak setuju dengan poin Anda.

Sehubungan dengan ini, alasan utama sekarang untuk menggunakan serializer yang berbeda dari JSON.NET adalah kinerja dan mengingat alasan serializer default baru ini adalah kinerja. Karena kebanyakan orang hanya menggunakan default, saya berharap ini memiliki dampak paling nyata pada berbagi JSON.NET sementara alasan utama untuk menggunakan serializer alternatif seharusnya tidak ada lagi dengan impl yang lebih cepat ini. Jadi pada dasarnya saya juga melihat ini berdampak buruk pada ekosistem (perpustakaan) yang ada. IMO ekosistem yang lebih lemah dari lib JSON adalah negatif bersih untuk .NET (bukan sesuatu yang kebanyakan konsumen akan lihat mereka hanya akan menggunakan default dan melupakan opsi lain), tapi itu bukan perhatian utama saya.

@davidfowl @shahid-pk

Meskipun demikian, saya sebenarnya lebih suka bahwa ini ada 8 tahun yang lalu sebagai alasan utama untuk mengembangkan ServiceStack.Text adalah karena serializer .NET Framework JSON sangat lambat. Tapi setelah sekian lama SS.Text telah diperluas dengan sejumlah fitur di semua perpustakaan kami, misalnya kustomisasi untuk mendukung bahasa yang berbeda ServiceStack Supports , opsi kustomisasi JSON yang berbeda ServiceStack Templates , Dukungan blob JSON Tipe Kompleks di ServiceStack .Redis dll.

Jadi sekarang saya fokus untuk menilai apa dampaknya, seperti apa API baru dan opsi plugability, dapatkah kita memasang kembali fitur yang ada ke dalamnya, apakah kita dapat mengadopsi sebagai serializer JSON di SS .NET Core Apps (apa yang akan rusak), akankah ServiceStack.Text dapat mendukung API baru, apakah kami dapat mendukung .NET v4.5, apakah dapat menyesuaikannya untuk mendukung format kawat dari penerapan yang ada, dll. pada dasarnya tidak tahu dampak apa pun pada semua ini atau strategi apa yang akan maju karena saya belum memiliki kesempatan untuk menggunakan atau melihat apa pun. Saya akan mengetahui lebih banyak jawaban ketika saya mendapat kesempatan untuk menggunakannya dan saya jelas ingin memiliki kesempatan untuk menguji integrasi dan memberikan umpan balik dan mengusulkan perubahan sebelum API dibekukan.

@mythz

Apakah ada alasan mengapa perpustakaan JSON paling populer ke-2 setelah JSON.NET - ServiceStack.Text yang telah di -refactored untuk dibangun di atas Span API telah dikecualikan?

Penghilangan itu tidak disengaja. Kami telah secara aktif mencari dan bekerja dengan penulis perpustakaan JSON sebagai bagian dari repo CoreFxLab dan salah satu istilah pencarian dasar seperti "json" di NuGet . Sepertinya perpustakaan Anda tidak muncul. Saya mengerti bahwa ini bisa membuat Anda frustrasi atau mengkhawatirkan, tetapi cobalah untuk memahami situasi dari pihak kami: tim kami tidak dapat diharapkan untuk mengetahui setiap perpustakaan di bawah matahari. Pengumuman ini merupakan bagian dari model pengembangan terbuka kami untuk melibatkan seluruh komunitas. Satu-satunya alasan kami cenderung menjangkau grup yang lebih kecil terlebih dahulu adalah memastikan rencana & pesan kami memiliki tingkat perhatian & kualitas yang wajar sebelum kami membagikannya kepada dunia. Belum ada yang final. Kami secara aktif mencari masukan tambahan.

Saya ingin tahu tentang "ekosistem" mana yang Anda maksud dan berharap untuk "bekerja sama" di sini?

Ekosistem .NET dan khususnya pihak-pihak yang tertarik dengan pemrosesan JSON.

Saya jelas tertarik pada seberapa kompatibel API "pluggable" ini pada akhirnya atau apakah ini berakhir menjadi area lain di mana adopsi dan integrasi perpustakaan MS baru akhirnya membunuh ekosistem yang digantikannya.

Tujuan dari titik ekstensi ASP.NET Core yang direncanakan adalah untuk memungkinkan pelanggan mengganti komponen JSON bawaan dengan pustaka JSON apa pun yang mereka inginkan. Tentu saja, ASP.NET selalu dikirimkan dengan "termasuk baterai", yaitu pengalaman default yang masuk akal. Di masa lalu ini adalah Json.NET dan bergerak maju itu adalah komponen yang disediakan platform. Mengingat bahwa Json.NET agak terprogram ke dalam ASP.NET, rencana baru tampaknya lebih baik untuk orang-orang seperti Anda; jadi saya tidak sepenuhnya yakin bagian mana dari rencana kami yang menurut Anda merupakan ancaman.

Ada pertanyaan terbuka tentang apa yang akan digunakan oleh templat untuk ASP.NET di 3.0.

Bukankah sudah waktunya Template menjadi modular? Seperti mengambil vue.js misalnya.

Membuat aplikasi vue baru memungkinkan Anda memilih hal-hal yang Anda inginkan. Mengapa hal serupa tidak dapat dilakukan untuk asp.net alih-alih membuat 500 templat untuk memenuhi semua skenario.

Berikut adalah contoh nyata untuk fitur di .ASP NET Core 2.2 di mana Pemformat Input/Output JSON non-JSON.NET akan menghadapi masalah dan bagaimana solusi yang dipisahkan dapat membantu:
Fitur ProblemDetails , yang memungkinkan respons kesalahan yang kompatibel dengan RFC 7807 :
https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ProblemDetails.cs

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

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

Kode di atas dijelaskan dengan atribut khusus JSON.NET, termasuk atribut fallback spesifik [JsonExtensionData] , semua properti JSON yang tidak diketahui dideserialisasi ke dalam kamus ini dan konten kamus ini diserialisasikan ke dalam struktur JSON normal.

Setiap Formatter Input/Output JSON alternatif sekarang perlu menangani atribut khusus JSON.NET ini agar dapat membuat serialisasi/deserialisasi tipe ini dengan benar atau menemukan cara lain, yaitu mundur ke JSON.NET untuk tipe ini.

Sekarang, jika kita memiliki spesifikasi fitur yang terdefinisi dengan baik, Input/OutputFormatter untuk JSON perlu didukung untuk 3.0, masalah di atas tidak ada karena atribut ini dapat hidup dalam paket Microsoft.Extension... dan setiap Formatter JSON Kustom dapat menggunakannya untuk mengimplementasikan fungsi ini agar kompatibel.

Sepengetahuan saya, hanya ada beberapa contoh kode sumber "resmi" di ASP.NET Core yang dijelaskan oleh atribut JSON.NET, tetapi saya juga melihat perpustakaan pihak ketiga menggunakan atribut khusus JSON.NET (biasanya untuk menentukan nama atribut melalui [JsonProperty("name")]

FWIW, itulah https://github.com/Tornhoof/SpanJson/issues/63 .

@terrajobst Saya pikir Anda menjawab sebelum Anda membaca komentar saya sebelumnya yang IMO lebih menjelaskan kekhawatiran saya.

Kami secara aktif mencari masukan tambahan.

Di mana? Apakah ada proposal/dokumen API, apakah API sudah dibuat, repo mana yang sedang dikembangkan?

Saya pikir Anda menjawab sebelum Anda membaca komentar saya sebelumnya yang IMO lebih menjelaskan kekhawatiran saya.

Saya sudah membacanya tetapi sepertinya Anda menentang memiliki default apa pun, yang, seperti yang dijelaskan @davidfowl , tidak praktis bagi kami. Maksud saya adalah bahwa rencana kami adalah peningkatan dari apa yang kami miliki saat ini, yaitu secara de facto menghubungkan ke Json.NET. Oleh karena itu pertanyaan saya.

Di mana? Apakah ada proposal/dokumen API, apakah API sudah dibuat, repo mana yang sedang dikembangkan?

Kami sengaja belum melakukan desain coding/API di .NET Core karena kami ingin mengeluarkan pengumuman ini terlebih dahulu. Kami tidak ingin orang membaca daun teh tanpa memberikan konteks yang disediakan pengumuman ini. Dengan kata lain, pantau terus, kami akan segera memublikasikan API dan kode.

@terrajobst Seluruh kesan untuk posting itu

1. Keputusan untuk melakukan perubahan dilakukan.

Ke depan, kami berencana membuat beberapa perubahan pada dukungan JSON kami:

1. Beberapa desain awal sudah selesai
   Kami membutuhkan API JSON berperforma tinggi.
   Hapus ketergantungan dari ASP.NET Core ke Json.NET.
   Menyediakan paket integrasi ASP.NET Core untuk Json.NET.

Semua ini berarti bahwa arah telah diambil. Semua yang diminta dari "ekosistem" adalah untuk menemukan titik nyeri yang jelas yang tidak dapat dijelaskan oleh MS secara realistis.

Kelalaian ServiceStack dan mendiskusikannya sebagai beberapa perpustakaan .NET kelas sekunder menggelikan. Bahkan saya hanya menggunakan perpustakaan yang dikirimkan MS, itu tidak berarti bahwa saya tidak tahu tentang alternatif.

Saya tidak punya masalah dengan MS mengambil keputusan, tetapi jika itu dinyatakan secara langsung, dan tidak ditutupi dengan "umpan balik komunitas" atas keputusan yang sudah diambil.

Itu kesan saya

@terrajobst

Saya sudah membacanya tetapi sepertinya Anda menentang memiliki default

Tidak pernah menyarankan itu, JSON.NET sudah menjadi default sebelum ini. Saya telah menjelaskan secara lebih rinci di atas tetapi untuk mengulangi ini diposisikan untuk mengambil alih default dan menjadi standar defacto baru di mana secara efektif .NET Core hanya akan memiliki 2 serializer JSON di masa depan: default kinerja tinggi defacto baru ini dan JSON. NET untuk fitur khusus. Serializer JSON lainnya akan menjadi niche, misalnya fitur unik ditambahkan untuk mendukung skenario yang berbeda.

Kami sengaja tidak melakukan pengkodean/desain API .NET Core karena kami ingin mendapatkan pengumuman ini terlebih dahulu.

Ok jadi tidak mungkin bagi "orang luar" mana pun untuk mengetahui seberapa baik plugability, extensibility, atau interoperability
akan belum.

Kami tidak ingin orang membaca daun teh tanpa memberikan konteks yang disediakan pengumuman ini. Dengan kata lain, pantau terus, kami akan segera memublikasikan API dan kode.

Jadi itu dikembangkan secara internal? Berapa lama setelah Anda merilisnya, pihak luar harus menguji dan mengusulkan perubahan pada desain API? Perhatian utama saya pada seperti apa tampilan API "plugable" dan "extensible", apakah kita akan dapat "mengambil alih" dan memiliki kontrol penuh untuk format kawat Jenis Ref/Nilai? Bagaimana dengan Tipe bawaan, Enum, bool, intrinsik lainnya, dll? misalnya Sebagai contoh, apakah ia dapat mengonfigurasi bool untuk menerima nilai JSON populer lainnya seperti "yes", "on", "1".

Pertanyaan Lain:

• Bisakah implementasi ini digunakan secara mandiri (dalam paket NuGet terpisah)?
• Apakah bagian "plugable" dari API terkait dengan Kerangka Web atau dapatkah digunakan di tempat lain (mis. Xamarin/UWP)
• Apakah akan mendukung .NET Standard 2.0 atau .NET v4.5?
• Jika tidak, apakah API dapat mendukung .NET Standard 2.0 atau .NET v4.5?

@mythz
Ini tidak benar-benar dikembangkan secara internal (sepengetahuan saya), bagian Pembaca/Penulis dilakukan di corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) dan secara khusus belum ada API tingkat tinggi untuknya di corefxlab.

Secara pribadi, saya akan kecuali bagian API extensible/pluggable menjadi .NET Standard (yaitu atribut dll). Pustaka di corefxlab adalah .NET Standard 1.1 saat ini, tetapi saya membayangkan ini akan berubah tergantung pada tujuan kinerja perpustakaan, dll.

@mythz

Anda tampaknya ingin sekali menerima pernyataan saya dan memasukkannya ke dalam konteks "gelasnya setengah kosong". Saya mengerti, Anda skeptis. Saya sarankan kita menyelamatkan diri kita dari banyak penekanan tombol dan mendiskusikan proposal API konkret daripada membahasnya secara abstrak. Saya cukup yakin bahwa rencana kami akan memberikan poin ekstensi yang Anda butuhkan.

@terrajobst Tidak mencoba untuk skeptis, mencoba untuk mengetahui apa saja kemampuan yang diusulkan tingkat tinggi yang saya asumsikan telah diputuskan (atau apakah semuanya masih TBD?). Pengumuman ini adalah yang pertama yang sebagian besar dari kita pernah mendengarnya, jadi saya mencari beberapa klarifikasi tentang bagaimana plugable, extensible, dan reusable itu dimaksudkan. Apakah System.Text.JsonLab merupakan impl saat ini? apakah ini berarti juga akan mendukung .NET Standard 2.0 dan .NET v4.5?

Ini mungkin fitur yang bagus untuk pembuat perpustakaan, tetapi Anda juga harus mempertimbangkan pengembang perusahaan menggunakan 50 perpustakaan dengan pohon ketergantungan dan mencoba menemukan kompatibilitas di antara mereka. Apakah akan ada konfigurasi pemetaan gaya-pengalihan-pengikatan untuk mencoba mengelola ketidakcocokan?

Percakapan ini tampak tegang, apakah karena orang tersinggung atau karena mereka mencoba membela tindakan yang telah diambil atau tidak. Sulit untuk membaca. Maaf sekitar! Tolong biarkan keadaan saat ini dan lanjutkan.

Tampaknya ada dua alasan untuk perubahan ini. Pertama adalah keinginan untuk meningkatkan kinerja dengan memanfaatkan tipe baru dalam .Net Core.

Selain itu, diketahui bahwa beberapa waktu lalu terjadi kesalahan arsitektur karena menyertakan referensi keras ke JSON.Net, pustaka yang berada di luar .Net. Untuk memperbaikinya, pengenalan implementasi JSON bawaan yang baru harus dibuat bersama dengan antarmuka yang memungkinkan pihak ketiga untuk menggunakan implementasi mereka sendiri.

Apakah ini akan merusak segalanya? Ya! Itu sebabnya pengumuman tersebut memiliki label "perubahan yang melanggar". (Mungkin label itu harus direplikasi di sini.) Dan karena ini dikenal sebagai perubahan besar, diskusi dimulai untuk mengeksplorasi dampaknya. Selain itu, untuk meminimalkan dampak, perpustakaan tambahan yang memungkinkan orang untuk terus menggunakan JSON.Net akan disediakan.

Sebagai penulis perpustakaan, saya sangat tertarik dengan ini, dan saya lebih suka percakapan berlanjut.

@Tornhoof sebagai tanggapan atas contoh Anda, jika saya ingin terus menggunakan JSON.Net, saya juga perlu merujuk pustaka kompatibilitas yang saya sebutkan sebelumnya. Seharusnya sebagian besar plug-and-play, tetapi mungkin ada perubahan. Saya jelas tidak ingin framework (.Net Core) mendikte bahwa serializer yang saya pilih HARUS menggunakan atribut ini untuk serialisasi, terutama ketika serializer saya menggunakan mekanisme berbeda untuk konsep serupa.

Solusi yang diberikan oleh .Net harus lebih umum dari itu. Penyerahan serialisasi model tertentu harus dilakukan oleh implementasi JSON yang dipilih.

@mythz Dari semua yang saya ketahui dan lihat dari orang-orang yang terlibat dalam pembuatan proposal ini, Anda akan mendapatkan kesempatan panjang untuk meninjau dan mengomentari API dan implementasi yang diusulkan sebelum dirilis sebagai stabil. Salah satu tujuan membuat posting ini pada tahap awal adalah untuk menemukan orang-orang seperti Anda secara khusus untuk alasan ini.

@gregsdennis
Saya tidak yakin apa yang Anda maksud dengan lebih umum?
Dengan asumsi pembuat serial Anda memiliki konsep mengesampingkan nama properti json, mengubah perilaku nol dan/atau fallback/catch-semua implementasi dan dengan asumsi bahwa ketiga fitur adalah bagian dari spesifikasi bersama untuk serializer JSON untuk .net core 3.0, maka paket implementasi memetakan atribut tersebut ke detail implementasi internal Anda.
Misalnya, jika perpustakaan Anda lebih suka Anda menggunakan [DataMember] untuk menentukan nama properti (seperti yang dilakukan SpanJson), paket integrasi Anda harus memetakannya dengan mudah.
Saya tidak mengatakan atribut adalah cara yang benar, itu hanya kebetulan menjadi bagian yang terlihat dari contoh kode.

Jelas, dunia yang ideal adalah tidak ada pustaka kerangka kerja ASP.NET Core yang akan menggunakan anotasi khusus untuk mengontrol perilaku serialisasi, tetapi untuk fitur di atas, itu cukup rumit hingga tidak mungkin, karena RFC memerlukan aturan penamaan tertentu untuk diikuti. .

Either way, saya pikir akan ada banyak diskusi tentang fitur-fitur bersama ini, bagaimana menggunakan dan menggambarkannya di masa depan.

Adakah rencana untuk menggunakan instruksi SIMD di parser JSON baru, seperti di RapidJSON?

Referensi: http://rapidjson.org/

Saran yang diusulkan terlihat bagus, tapi tolong coba dan lancarkan " melanggar perubahan " Saya hanya pengguna umum lib pihak ke-3 dan baru-baru ini memiliki salah satu pengalaman ini di mana refleksi tiba-tiba dikeluarkan dari proses pembuatan rilis asli UWP .net (kompiler ).

Jadi tidak ada aplikasi UWP saya yang dapat dibuat dalam mode rilis selama berbulan-bulan karena saya harus menulis ulang semua kode yang menggunakan refleksi di lib pihak ke-3. Saya tahu banyak penulis perpustakaan harus membagi implementasinya lagi untuk mengecualikan refleksi di bagian UWP tersebut. Sebagian besar penulis perpustakaan tidak datang ke pesta dan saya terpaksa melompat kapal. Meskipun MS tampil ke depan dan berkomitmen untuk menerapkan alternatif dalam standar .net 2.1. kita tahu bahwa kenyataan di lapangan adalah .net standar 2.1 akan memakan waktu berbulan-bulan untuk disampaikan dari perubahan awal.

Intinya sederhana, ini adalah proses yang sangat mengganggu bagi saya yang memiliki konsekuensi besar bagi pengguna akhir dan sama sekali tidak "halus" dan tanpa gesekan.

Ini jelas merupakan langkah yang tepat untuk dilakukan.
Saya bertanya-tanya untuk sementara waktu melihat referensi Json.Net ini.

@Tornhoof Saya pikir perlu ada pemisahan yang ditentukan: antarmuka yang perlu diterapkan oleh setiap penyedia agar dapat digunakan dengan .Net Core 3.0, dan implementasi default yang ada di dalamnya.

Antarmuka harus digunakan secara umum mungkin. Mungkin sesederhana mendefinisikan hanya metode Serialize() dan Deserialize() .

Rincian lainnya harus diserahkan kepada implementasi. Jika implementasi default menggunakan atribut untuk mendefinisikan mekanisme penguncian properti khusus, saya setuju dengan itu. Saya pikir itu detail khusus implementasi yang seharusnya tidak menjadi bagian dari antarmuka.

Yang mengatakan, memiliki kemampuan untuk properti kunci khusus bisa menjadi persyaratan, meskipun saya tidak yakin bagaimana itu bisa dikodifikasi.

@gregsdennis Ya Anda benar, saya terutama melihat IInput/OutputFormatter, yang saat ini sudah ada di ASP.NET Core dan khususnya masalah terkait menggantinya dengan versi non-JSON.NET.
Bagaimanapun seperti yang ditunjukkan oleh komentar Anda dan

@Tornhoof setuju. Antarmuka formatter saat ini jelas berbasis JSON.Net, tetapi tidak begitu banyak pada serializer itu sendiri, melainkan pada objek opsi. Tampaknya kita juga membutuhkan cara umum untuk mengomunikasikan opsi (objek opsi umum).

Apakah ini menyiratkan bahwa objek opsi menentukan set fitur minimum untuk implementasi? Saya rasa tidak. Saya baru-baru ini menerapkan formatter untuk serializer saya yang sepenuhnya mengabaikan objek opsi, tetapi itu untuk penggunaan pribadi saya. Jika saya ingin membuatnya untuk kepentingan umum, saya akan mencoba menafsirkan sebanyak mungkin opsi tersebut untuk mendukungnya.

Bukan itu yang sekarang kita lakukan. Opsinya khusus untuk serializer dan tidak ada antarmuka umum untuknya. Pemformat di MVC sudah diperhitungkan dengan benar dan tidak digabungkan dengan apa pun. JsonResult akan memiliki perubahan yang melanggar karena mengambil JsonSerializationOptions secara langsung (tipe JSON.NET).

Saya baru saja akan mengatakan hal yang sama. Kami tidak berencana membangun abstraksi untuk pembaca/penulis/serializer JSON. Itu tidak diperlukan; kerangka kerja baik menangani primitif IO (seperti Stream , TextReader ) atau menyambungkan ke pemrosesan kerangka tingkat yang lebih tinggi (seperti formatter ASP.NET Core).

Berbicara tentang poin rasa sakit: Secara pribadi (dan saya mungkin dalam minoritas yang sangat kecil) saya khawatir tentang sifat longgar dari banyak parser JSON. Ada standar (tm) tetapi sebagian besar parser memilih untuk bersikap lunak dan menerima dokumen yang tidak sesuai. Apa yang buruk tentang itu dalam jangka panjang adalah bahwa pengembang tidak menerapkan standar yang mereka terapkan ke perpustakaan. Jika perpustakaan mengizinkan dokumen yang tidak sesuai, pengembang senang selama semua bit menggunakan perpustakaan yang sama. Rasa sakit muncul ketika mencoba untuk berkomunikasi antara domain yang menggunakan perpustakaan yang berbeda. Tiba-tiba ada masalah karena perpustakaan yang berbeda mendukung rasa JSON yang berbeda.

Haruskah kita menghapus titik-titik sakit dengan membuat perpustakaan JSON selembut mungkin (tetapi mungkin berakhir dengan kompleksitas dan ambiguitas) atau menyerang akar masalahnya; pustaka JSON yang tidak mengonfirmasi.

Karena MS yang berpengaruh mungkin ada banyak hal yang harus diminta agar MS berhasil memenangkan parser JSON yang sesuai untuk meningkatkan interoperabilitas dalam jangka panjang, tetapi saya berharap itu berbeda. Mungkin lunak dalam membaca tetapi ketat dalam menulis?

(Hal-hal yang tidak standar; komentar, tanda koma, string kutipan tunggal, tanpa string kutipan, dan sebagainya)

IMHO, karena JSON berasal dari dunia browser web, tampaknya untuk interoperabilitas kita harus memilih ganda sebagai representasi dasar untuk angka di JSON meskipun standar JSON tidak mengatakan apa-apa tentang perwakilan.

Berbicara tentang API, saya secara implisit menganggap API yang paling umum digunakan adalah DOM seperti API tetapi saya juga akan merasa sangat berguna jika ada API tingkat yang lebih rendah yang memungkinkan saya untuk menggunakan aliran token atau mendapatkan sinyal pada antarmuka pengunjung untuk dokumen-dokumen besar dari mana saya hanya ingin mengekstrak sebagian kecil data.

@mrange - Sebanyak yang saya suka membuat hal-hal seketat mungkin.... melakukannya bergantung pada kemampuan untuk membuat perubahan dalam kode yang tidak sesuai.

Jika Anda berinteraksi dengan layanan lawas di bawah kendali beberapa perusahaan lain, kemampuan untuk mengubah kode yang melanggar hampir nol. Bahkan penulisan yang ketat, meskipun lebih bisa dilakukan, bukannya tanpa masalah sendiri di sini: bagaimana jika kode yang melanggar mengharapkan objek yang tidak sesuai dikirim ke sana?

@terrajobst terima kasih! Func<Stream, CancellationToken, Task<T>> dan Func<T, CancellationToken, Stream, Task> adalah semua yang dibutuhkan di sini. Dengan mungkin beberapa kelebihan untuk TextReader/Writer, Span, dan string.

Namun downside adalah ketika Anda ingin membuat serial / deserialize jenis perpustakaan lain, dan jenis itu dihiasi dengan atribut dari serializer json yang tidak Anda gunakan.

@thefringeninja jika Anda sudah menggunakan perpustakaan pihak ketiga untuk objek, maka Anda sudah memiliki referensi ke serializer lainnya. Tidak ada yang berubah di sana.

Saya bukan orang yang suka mongering ketakutan, tapi saya pikir @mythz memiliki beberapa poin yang valid.

@terrajobst Mengenai ekosistem, meskipun tidak mungkin untuk menjelaskan setiap perpustakaan di luar sana, saya tidak berpikir pencarian cepat "json" di NuGet akan memberi tahu siapa pun banyak. Mungkin nama ServiceStack.Text bukanlah cara yang paling tepat untuk mengatakan "Hei! Saya adalah paket yang dapat (menghapus) serialisasi JSON!", tetapi ada tolok ukur selama bertahun-tahun yang membandingkannya. Mungkin ini adalah kasus dogfooding default MS dan entah tidak mengetahui luas dan popularitas alternatif atau menggunakannya cukup sering secara internal untuk mengenalnya.

Saya setuju bahwa harus ada beberapa default untuk memberikan pengalaman yang _hanya bekerja_ out-of-the-box. Jika penulis perpustakaan lain di ekosistem menerbitkan paket integrasi, akan sangat bagus jika mereka bisa mendapatkan plug di dokumen, catatan rilis, dll. untuk menekankan bahwa ada alternatif di luar default. Membuatnya sulit untuk ditemukan akan menjadi masalah bagi ekosistem.

Harapan saya adalah jika tujuan menghilangkan ketergantungan itu tulus, API harus mewakili kebutuhan komunitas dengan baik dan tidak dimodelkan secara langsung setelah Json.NET. Intinya adalah itu akan membutuhkan pekerjaan dari semua penulis perpustakaan, bukan hanya ServiceStack, tetapi API tidak boleh secara langsung menyerupai API Json.NET, jika tidak, Anda kembali ke apa yang tampak seperti ketergantungan tetapi tanpa dll.

API seharusnya tidak secara langsung menyerupai API Json.NET

... atau implementasi penyedia tertentu lainnya.

Bagian dari diskusi yang terjadi sebelum pengumuman termasuk gagasan bahwa tim .Net akan menggambar dari berbagai perpustakaan untuk merasakan bagaimana berbagai masalah telah diselesaikan, dan kemudian menggunakan apa yang mereka anggap paling cocok untuk itu. ide-ide yang digabungkan dengan ide mereka sendiri. Dalam banyak hal, ini tidak berbeda dengan bagaimana perpustakaan JSON baru lainnya akan dikembangkan; kebetulan yang ini akan dimasukkan dalam kerangka kerja.

Kami siap untuk memiliki perpustakaan JSON berkinerja tinggi yang tidak harus kami buat sendiri. :)

Sebelum membahas apa pun, pertimbangkan untuk memanfaatkan hasil Riset Microsoft di area itu (lebih khusus lagi, penguraian FSM tanpa percabangan) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -data-analitik/

Kami menuju ke arah itu untuk parsing JSON kinerja tinggi --- selain Span<T> tentu saja ---
cc @terrajobst @karelz

:( semua diskusi tentang JSON ini membuat saya merasa pertanyaan saya tentang templat salah.

Saya berharap saya memiliki lebih banyak waktu untuk diskusi ini karena ini adalah neraka tetapi saya mengerti mengapa itu menjadi seperti itu. 4.6.1 harus tetap konsisten dengan pemutakhiran dan pemutakhiran dan perubahan yang melanggar akan dilakukan untuk sisanya.

Saya telah melihat banyak paket yang ditarik kembali untuk inti dan 461 dan saya harap jenis atau perubahan ini akan memperbaikinya.

Saya khawatir masalah cascading akan menghantui kita, tolong buktikan bahwa kita salah.

// pengembang dot net di mana-mana

@c0shea

[…] Akan sangat bagus jika mereka bisa mendapatkan plug di dokumen, catatan rilis, dll. untuk menekankan bahwa ada alternatif di luar default.

Saya yakin itu akan terjadi. Dokumen sudah mencantumkan implementasi alternatif untuk beberapa topik, seperti wadah DI , penyedia logging , integrasi Swagger , atau penyedia basis data EF Core .

@phillip-haydon
Sistem templat sudah mendukung templat yang dapat disesuaikan, dan templat yang ada sebenarnya sudah memiliki sejumlah opsi. Lihat saja misalnya dotnet new mvc --help untuk apa yang saat ini mungkin. Saya yakin Anda dapat dengan mudah memperluasnya dengan misalnya integrasi serializer JSON alternatif, dan permintaan fitur atau permintaan tarik untuk itu kemungkinan akan diterima di aspnet/Templates .

@mrange - Sebanyak yang saya suka membuat hal-hal seketat mungkin.... melakukannya bergantung pada kemampuan untuk membuat perubahan dalam kode yang tidak sesuai.

Jika Anda berinteraksi dengan layanan lawas di bawah kendali beberapa perusahaan lain, kemampuan untuk mengubah kode yang melanggar hampir nol. Bahkan penulisan yang ketat, meskipun lebih bisa dilakukan, bukannya tanpa masalah sendiri di sini: bagaimana jika kode yang melanggar mengharapkan objek yang tidak sesuai dikirim ke sana?

Mungkin memiliki mode ketat secara default dan dapat secara eksplisit mengubahnya ke mode yang lebih lunak

@poke Saya kira Anda benar-benar harus mencoba vue cli dan kemudian coba lagi dotnew baru. Saat ini dotnet baru... adalah... itu...

Bisakah saya meminta Anda mengingat bahwa penguraian JSON berbagai browser tidak mendukung nilai int64 dengan benar, dan memberi kami kemampuan untuk membuat serial/deserialisasi long sebagai string? Itu salah satu hal yang tidak Anda sadari sampai ia menggigit Anda dengan keras. Variasi dalam hal ini adalah kemampuan untuk memutuskan apakah angka-angka dideserialisasi menjadi int atau long secara default.

Bisakah saya meminta Anda mengingat bahwa penguraian JSON berbagai browser tidak mendukung nilai int64 dengan benar, dan memberi kami kemampuan untuk membuat serial/deserialisasi long sebagai string? Itu salah satu hal yang tidak Anda sadari sampai ia menggigit Anda dengan keras. Variasi dalam hal ini adalah kemampuan untuk memutuskan apakah angka-angka dideserialisasi menjadi int atau long secara default.

....Ah, EcmaScript, terima kasih telah membuat segalanya menjadi ganda. Saya yakin itu tidak menyebabkan masalah di beberapa bagian kode lainnya ...

Sebagai seorang purist, saya tidak menyukai hal-hal seperti ini.
Sebagai seorang realis, saya pikir saya harus setuju dengan ini.

Apakah ada bagian dari implementasi JSON baru dalam .Net Standard 2.1 ?

Saya telah mengikuti ini sedikit, dan saya tidak yakin apakah saya melewatkannya. Apakah ada permukaan atau antarmuka API yang diusulkan yang dapat saya tinjau? Saya tertarik melihat luas permukaan API untuk proposal ini.

Apakah ada permukaan atau antarmuka API yang diusulkan yang dapat saya tinjau?

Masih banyak yang harus dilakukan, tetapi https://github.com/dotnet/corefx/pull/33216 adalah permulaan. Berikut catatan tinjauan API .

UPDATE: Roadmap juga tersedia di sini .

jadi bagaimana fitur lengkap api aspnet 3.0 dibandingkan dengan api json.net? Juga, apakah json.net untuk semua maksud dan tujuan akan dihapus secara bertahap oleh pengembangan aplikasi baru dengan api asli?

hanya meningkatkan kinerja atau berarti mengganti semua fungsi json.net?

Ini adalah berita yang luar biasa.

Saya sangat menyarankan untuk mencoba berkolaborasi dengan @neuecc , karyanya dengan MessagePack , Utf8Json , ZeroFormatter dll sangat fenomenal.

@linkanyway hasilnya adalah mengganti subset dari json.net, sambil memberikan api tanpa alokasi yang baru.

Saya menduga sebagian besar pengguna aspnet tidak akan memiliki ketergantungan yang kuat pada implementasi json.net dan akan dapat bermigrasi dengan mulus.

Apakah ada permukaan atau antarmuka API yang diusulkan yang dapat saya tinjau?

Masih banyak yang harus dilakukan, tetapi dotnet/corefx#33216 adalah permulaan. Berikut catatan tinjauan API .

UPDATE: Roadmap juga tersedia di sini .

@khellang Apakah kita akan mendapatkan bantuan lang yang dapat kita tulis json di c# secara nyata?

Satu lagi gerakan bagus ke arah OSS. Akan memotivasi pengembang platform Komersial lainnya untuk mengembangkan sesuatu yang lebih baik daripada yang sudah dilakukan MS secara gratis, atau menjadi OSS sepenuhnya jika mereka benar-benar peduli dengan komunitas.

Apakah kita akan mendapatkan bantuan bahasa agar kita dapat menulis json di c# secara nyata?

@dotnetchris Saya tidak yakin apa yang Anda maksud dengan "bantuan lang"? literal JSON? Aku ragu itu akan terjadi. Sudahkah Anda melihat fitur "bahasa yang disematkan" yang akan datang? Khusus untuk JSON ?

@khellang itu tentu saja merupakan langkah ke arah yang benar, tapi maksud saya dukungan penuh. Menggunakan objek sampel yang sama dari tautan Anda, lebih mirip dengan:

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

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

Dengan voodoo yang cukup, seperti pembuatan objek tuple/valuetuple/record implisit untuk membuat semuanya bekerja pada tingkat bahasa di belakang layar.

Sebaliknya kompiler dapat memanggil layanan json, membuat kelas dan kemudian bekerja dengan turunan kelas seolah-olah Anda menulis:

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

Sunting: LOL @ downvoters.

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

@dotnetchris Jika Anda tertarik, silakan beri suara di https://github.com/dotnet/roslyn/pull/24110. Telah ditutup oleh tim IDE karena kurangnya minat. Tetapi jika ada cukup suara, mungkin itu bisa berubah.

Apakah "built-in" dan "platform yang disediakan" JSON API berarti bahwa itu tidak akan menjadi paket nuget (netstandard) yang terpisah? Jika tidak, mengapa tidak?

Saya kira kerangka kerja bersama ASP.NET Core yang baru tidak dapat bergantung pada paket nuget, atau bisakah?

Bukankah sudah ada Namespace System.Json ? Apakah ini namespace yang akan digunakan/diperluas untuk .NET Core 3.0 dan akhirnya .NET Standard. Namespace itu sudah digunakan di (mungkin tidak banyak digunakan tetapi tersedia ) di Xamarin.Android 7.1+, Xamarin.iOS 10.8+ dan Xamarin.Mac 3.0+.

Menghapusnya akan merusak kompatibilitas ke belakang. Meninggalkannya dan memulai API baru dapat menyebabkan kebingungan. Memperluas/Meningkatkan tanpa menghapus API apa pun mungkin sedikit membatasi saat menambahkan API baru.

Akan sangat bagus untuk memiliki antarmuka untuk JsonReader/JsonWriter, karena ada sumber dan target lain selain aliran. Misalnya saya juga menggunakan JSON.NET untuk MongoDB. Ini lebih cepat dan saya tidak perlu memelihara banyak serializer di aplikasi saya.

Saya tahu ini bisa sedikit mengganggu kinerja, tetapi ini sangat berguna.

@SebastianStehle : JsonReader/JsonWriter adalah abstraksi tingkat tinggi, lihat komentar terrajobst

Rencana untuk 3.0 adalah sebagai berikut:

1. API JSON berperforma tinggi bawaan. Pembaca/penulis tingkat rendah, pembaca/penulis berbasis Aliran , dan >serializer.
2. ASP.NET Core dapat dicolokkan ke komponen JSON.

Ada pertanyaan terbuka tentang apa yang akan digunakan oleh templat untuk ASP.NET di 3.0. Bergantung pada kesetiaan yang dapat kami berikan pada 3.0, kami mungkin meminta mereka menarik paket integrasi Json.NET. Namun, tujuannya adalah untuk memberikan fidelitas & paritas yang cukup untuk hanya bergantung pada yang built-in secara default.

API tingkat tinggi yang mudah digunakan akan dililitkan di sekitar aliran untuk memudahkan deserialisasi dari dan ke aliran (ini sering kali paling umum, saat membuat serial. Jika Anda menginginkan kinerja terbaik dalam skenario di mana Anda tidak dapat menggunakan aliran, Anda harus menggunakan yang rendah API level yang beroperasi pada Span<T> atau Memory<T> , terutama ketika Anda sudah memiliki data/memori yang ingin Anda gunakan dan tidak memiliki overhead async.

@TsengSR

https://github.com/neuecc/Utf8Json tidak menyediakan fungsionalitas untuk menulis pembaca/penulis khusus karena alasan kinerja (panggilan dan alokasi virtual saya kira) dan saya pikir mereka ingin menempuh jalur yang sama. Tapi sejauh ini saya belum melihat kode serialisasi.

Saya setuju dengan @JonasZ95 dan @gregsdennis , saya harap implementasinya tidak akan menjadi abstraksi sederhana dari detail implementasi JSON.Net yang sama tetapi akan fokus pada seperti apa _should_ terlihat.

Saya juga berpikir itu harus didekati sebagai 2 fungsi terpisah ...

1. serialisasi / deserialisasi
2. versi json dari serialisasi dan deserialisasi tersebut.

Semoga kerangka ASP.NET Core akan menggunakan abstraksi serialisasi generik alih-alih abstraksi spesifik JSON.

Sejauh ekstensibilitas, saya berharap kerangka kerja akan menggunakan teknik pengkodean DI untuk abstraksi (antarmuka bukan kelas abstrak) dan hanya menyediakan default lokal. Dari perspektif penulis perpustakaan JSON, ini akan memberikan ekstensibilitas terbesar karena yang harus Anda lakukan hanyalah menyediakan kelas adaptor ASP.NET Core yang menggunakan implementasi perpustakaan dari antarmuka dan kemudian mengonfigurasi ASP.NET Core untuk menggunakan adaptor perpustakaan.

Implementasi untuk perpustakaan pihak ke-3 dapat terlihat seperti ini:
```C#
// referensi perpustakaan pihak ketiga
menggunakan Newtonsoft.Json;

// contoh yang sangat naif untuk singkatnya hanya untuk
// buat intinya
kelas publik NewtonsoftAdapter : ISerializer
{
pribadi JsonSerializerSettings _settings;
Pemformatan pribadi _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);
}

}

...

// atur adaptor dengan opsi penyesuaian pihak ketiga
pengaturan var = JsonSerializerSettings baru
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = new NewtonsoftAdapter(settings, Formatting.Indented);

// konfigurasikan inti asp.net
// di mana adaptor mengimplementasikan ISerializer (atau nama apa pun yang Anda buat)
// penulis perpustakaan bahkan dapat menyediakan metode ekstensi UseXYZ() mereka sendiri.
app.UseSerializer(adaptor);
```

Ada banyak kemajuan dalam penguraian teks berbasis SIMD, termasuk untuk teks terstruktur, seperti JSON . Apakah ada kemungkinan pekerjaan di .NET Core akan mendekati tingkat kinerja ini? Apakah ada cara untuk menggunakan teknik ini?

Hei, bahkan Microsoft Research memiliki beberapa solusi berkinerja tinggi baru!

@AnthonyMastrean Terima kasih telah mengemukakan ini. Saya juga tertarik pada tolok ukur apa pun untuk mendapatkan gambaran tentang bagaimana impl Json saat ini dibandingkan dengan simdjson.

Omong-omong, penulis simdjson mengatakan bahwa mereka masih mengerjakan sepenuhnya penerbitan proyek ini (saya pikir, lebih banyak doc). Untuk saat ini, Anda dapat membaca beberapa diskusi menarik tentang proyek ini di HN .

Apakah ada cara untuk menggunakan teknik ini?

.NET Core 3.0 kebetulan mengirimkan sekelompok intrinsik yang bergantung pada platform , jadi itu pasti bisa dilakukan

Untuk apa nilainya, saya pikir dalam lingkup web, jaringan adalah hambatan utama, dan meskipun keren bahwa Anda dapat mengurai gigabyte dalam hitungan detik, saya tidak berpikir itu sangat berguna untuk proyek web.

Jangan salah paham, pengoptimalan kinerja seperti ini sangat keren dan mungkin akan menguntungkan bahkan dokumen JSON yang sangat kecil. Tetapi untuk saat ini, saya pikir fokus dengan perpustakaan baru adalah untuk menghindari alokasi memori dan memindahkan semuanya sangat dekat ke lapisan jaringan. Itu saja seharusnya sudah banyak meningkatkan kinerja di atas JSON.NET. Tetapi ketika pekerjaan awal selesai, melihat pengoptimalan tambahan mungkin menjadi cerita lain.

Di tempat saya bekerja, kami mengurai tera byte JSON setiap hari. Saya tahu orang lain juga yang menggunakan .NET dan F# untuk memproses banyak dokumen JSON juga. JSON telah menjadi lebih dari sekedar mekanisme transport server => browser. Ini banyak digunakan dalam skenario backend murni.

OFC; akan lebih baik bagi backend untuk beralih ke format biner seperti AVRO/Protobuf tetapi seringkali itu sulit dan JSON memang memiliki beberapa manfaat (dengan enggan saya akui). Memiliki parser JSON yang sangat cepat benar-benar dapat menghemat $10.000 dolar per bulan untuk perusahaan yang serupa dengan kami.

@poke Proyek ini berada di bawah .NET Core (bukan ASP.NET...), jadi relevan untuk semua beban kerja, bukan hanya web.

Saya dapat menyetujui gagasan bahwa sudah terlambat untuk mengerjakan teknik pengoptimalan khusus ini untuk .NET Core 3.0, tetapi saya berharap bahwa beberapa penyelidikan dilakukan sekarang untuk memastikan bahwa pengoptimalan dapat dilakukan di masa mendatang (yaitu tanpa merusak perubahan ).

Mungkin lebih baik membuat sesuatu seperti perakitan pemetaan terpadu ('System.Text.Json.Mapping') di mana mendefinisikan atribut dan hal-hal lain untuk memetakan kelas JSON ke C #? Setelah menerapkan hal ini, semua Parser/Penulis JSON yang ada dapat diadopsi untuk menggunakan pemetaan terpadu. Ini akan memberikan kemampuan untuk semua aplikasi .NET Standard untuk bermigrasi di antara perpustakaan JSON yang berbeda tanpa rasa sakit

@AlexeiScherbakov Abstraksi baru sebenarnya tidak banyak membantu. Anda hanya akan membatasi diri lagi dengan memilih abstraksi umum dan akan selalu ada perpustakaan baru yang tidak dapat menggunakan abstraksi dan membutuhkan lebih banyak. Selalu seperti itu, misalnya dengan logging .

Saya tidak berpikir membuat abstraksi baru berdasarkan implementasi baru ini akan memberi kita manfaat apa pun, terutama ketika perpustakaan dirancang untuk menjadi jauh lebih sedikit kaya fitur.

Dan sebenarnya sudah ada abstraksi standar bersih yang ada dalam bentuk DataContract/DataMember yang saya harap akan dihormati oleh perpustakaan ini (bahkan jika abstraksi itu agak terbatas).

Selain atribut abaikan, kita tidak dapat memiliki satu miliar atribut dan skenario baru untuk dipenuhi. Lebih suka pemetaan JSON 1: 1 ke kelas, jika Anda ingin melakukan sesuatu di luar norma atau mendukung warisan, gunakan json.net.

Secara pribadi saya tidak terlalu peduli dengan JSON <=> Kelas C#. Saya pikir penting untuk memiliki konsep penguraian/penulisan JSON yang terpisah dari model objek C# yang dibuat dari model JSON.
Dengan begitu saya (yang tidak terlalu peduli dengan kelas JSON <=> C#) dapat memiliki parser yang sangat efisien tanpa tersandung beberapa model objek.

@mrange itulah

Apakah itu berarti saya dapat mengharapkan API Pembaca/Penulis di platform yang disediakan JSON API? Apakah pola Pembaca/Penulis yang paling efisien?

Ada 3 jenis di System.Text.Json sampai sekarang :

• Utf8JsonReader - cara cepat, non-cache, forward-only untuk membaca teks JSON yang disandikan UTF-8.
• Utf8JsonWriter - ^ sama seperti Utf8JsonReader , tetapi untuk menulis.
• JsonDocument - model dokumen akses acak read-only untuk payload JSON.

Semua tipe di atas harus (kurang lebih) bebas alokasi 👍

Kami memposting makalah simdjson: https://arxiv.org/abs/1902.08318

Ada juga pekerjaan yang sedang berlangsung pada port C # simdjson: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

Mungkin lebih baik membuat sesuatu seperti perakitan pemetaan terpadu ('System.Text.Json.Mapping') di mana mendefinisikan atribut dan hal-hal lain untuk memetakan kelas JSON ke C #? Setelah menerapkan hal ini, semua Parser/Penulis JSON yang ada dapat diadopsi untuk menggunakan pemetaan terpadu. Ini akan memberikan kemampuan untuk semua aplikasi .NET Standard untuk bermigrasi di antara perpustakaan JSON yang berbeda tanpa rasa sakit

Saya sangat berharap abstraksi baru tidak bergantung pada atribut. Saya mencoba menggunakan objek POCO bersih di perpustakaan yang mendasarinya dan menggunakan DI untuk menghindari mereka harus tahu tentang implementasinya. Saya pasti tidak ingin mendekorasi kelas dasar saya dengan atribut yang diperlukan untuk implementasi. Ini pada akhirnya dapat menyebabkan kelas tambahan dibuat di lapisan ui yang pada dasarnya hanya memetakan objek domain yang ada ke json.

Mungkin 1-1 pemetaan kelas json ke c # akan menjadi pendekatan yang lebih baik, setidaknya dalam beberapa kasus Anda dapat menghindari membuat kelas baru bahkan jika kelas tipe viewmodel masih diperlukan dalam kasus lain.

Akan lebih baik meskipun jika ada semacam cara untuk mengabaikan properti yang tidak diperlukan dan setidaknya mengontrol beberapa aspek serialisasi (seperti casing unta vs pascal).

@mrange itulah

@davidfowl Apakah itu berarti API baru menggunakan rute ini? Apakah desainnya sudah selesai?

Dukungan serialisasi mendarat saat kita berbicara . Masalah terkait mengatakan:

• Karena keterbatasan waktu, dan untuk mengumpulkan umpan balik, set fitur ditujukan untuk produk yang layak minimum untuk 3.0.
• Skenario objek POCO sederhana ditargetkan. Ini biasanya digunakan untuk skenario DTO.
• API dirancang agar dapat diperluas untuk fitur baru di rilis berikutnya dan oleh komunitas.
• Atribut desain-waktu untuk menentukan berbagai opsi, tetapi masih mendukung modifikasi saat run-time.
• Performa tinggi menggunakan IL Emit dengan fallback ke refleksi standar untuk kompatibilitas.

Ini juga merinci bagaimana mereka berencana untuk mendukung konversi enum, penanganan nol, unta vs PascalCasing, dll.

Jika Anda memiliki umpan balik tentang semua ini, Anda harus meninggalkan komentar Anda di masalah itu atau permintaan tarik.

@lemire Wow, itu sangat keren. simdjson memang super cepat.

Adakah kemungkinan Anda dapat menerapkan

Saya menemukan implementasi ini: Di repo TechEmpower dan di repo ASP.NET .

@KPixel Ini serialisasi, kan? Sementara simdjson adalah parser... Kecuali saya bingung dengan istilahnya, hal-hal ini berlawanan arah?

Salahku. Saya berasumsi ada bagian deserialisasi (yang akan menggunakan parser).

Apakah System.Text.Json akan menjadi paket nuget standar .net? atau Itu sesuatu yang hanya tersedia untuk .net core 3.0?

@John0King lihat di sini: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

Saya pikir kegunaan harus menjadi fokus dari paket JSON baru juga. Salah satu fitur yang menurut saya harus dimiliki adalah dukungan validasi skema JSON. Newtonsoft biaya untuk itu. Ini adalah sesuatu yang cukup mendasar sehingga harus disediakan di platform secara gratis, seperti halnya validasi skema XML.

@ jemiller0 Kesan saya adalah bahwa validasi XML agak campuran dan skema JSON telah diadopsi begitu-begitu dalam kata nyata. Anda selalu dapat memiliki pemeriksaan skema melalui perpustakaan sebagai langkah tambahan... Tentu, ini mungkin melibatkan perolehan lisensi perangkat lunak, tetapi apakah ini masalah besar?

@lemire Ya, itu masalah besar, jika Anda mengembangkan perangkat lunak sumber terbuka dan ingin membuat perangkat lunak Anda tersedia untuk semua orang. Penguraian XML bukan tas campuran. Berhasil. Hal yang sama dengan validasi skema JSON. Tidak memiliki cara gratis bawaan untuk melakukan ini membuat platform .NET tidak kompetitif.

Saya belum pernah melihat skema json digunakan di dunia nyata. Meski begitu seharusnya tidak menjadi bagian dari implementasi yang dibahas di sini. Dan tidak satu pun dari miliaran fitur dan kebiasaan lain di json.net yang harus diterapkan di sini juga. Ini seharusnya tidak lebih dari implementasi cepat super ringan. Jika Anda tidak senang karena Anda memerlukan lisensi json.net untuk mendukung validasi json. Buat implementasi open source Anda sendiri dan buat itu tersedia secara bebas.

@jemiller0

Saya benar-benar ingin tahu: apakah bahasa pemrograman lain menawarkan dukungan skema JSON di perpustakaan standar mereka?

Tujuan perpustakaan ini adalah menjadi perpustakaan berperforma tinggi dan tingkat rendah untuk bekerja dengan JSON. Apa pun yang bukan itu, yang mencakup sebagian besar fitur yang lebih canggih dari JSON.NET dan juga skema JSON, tidak akan menjadi bagian dari ini.

Jika Anda ingin validasi skema JSON, Anda bebas mengimplementasikan validator di atas pustaka ini, yang seharusnya cukup rendah untuk memungkinkan Anda melakukannya.

Saya tidak percaya bahwa memiliki validasi skema JSON di perpustakaan standar ada hubungannya dengan platform yang kompetitif atau tidak.

Tujuan perpustakaan ini adalah menjadi perpustakaan berperforma tinggi dan tingkat rendah untuk bekerja dengan JSON. Apa pun yang bukan itu, yang mencakup sebagian besar fitur yang lebih canggih dari JSON.NET tidak akan menjadi bagian dari ini.

Kecuali itu juga akan mencakup fitur tingkat yang lebih tinggi, yang dirancang untuk menjadi pengganti drop-in Newtonsoft.Json 😊

@poke Anda berhak memiliki pendapat apa pun yang ingin Anda miliki, sama seperti saya. XML digunakan di semua tempat. Oleh karena itu, benar, Microsoft menyertakan dukungan validasi dengan .NET Framework. Sekarang, JSON sangat populer dan digunakan DI MANA SAJA, dalam file konfigurasi, API web, dll. dll. Masuk akal untuk memiliki tingkat dukungan yang sama untuk JSON seperti yang secara historis didukung untuk XML. Secara pribadi, saya merasa agak konyol bahwa Microsoft menggunakan perangkat lunak pihak ketiga untuk memulai ini. Itu harus menjadi fitur inti dari platform.

@lemire Saya akan segera memeriksa Python. Pada titik mana saya akan mengetahui bahwa itu built-in, atau disertakan sebagai paket yang mudah diinstal. Saya akan sangat terkejut jika tidak. Saya melihat menggunakan NJsonSchema untuk apa yang saya butuhkan saat ini. Langsung dari atas, Anda dapat melihat dokumentasi menyebalkan. Ya, mengandalkan perpustakaan pihak ketiga yang mungkin atau mungkin tidak berkualitas adalah ide bagus untuk hal-hal seperti bekerja dengan JSON yang benar-benar ada di mana-mana dan digunakan di mana saja. Mari kita mengandalkan perangkat lunak komersial, atau paket pihak ketiga tanpa dokumentasi. .NET seharusnya tidak hanya cocok dengan platform lain seperti Python. Mereka harus mengalahkan mereka dengan menyediakan perangkat lunak berkualitas dengan dokumentasi yang tepat di luar kotak. Ini secara historis cara kerjanya. Di tempat saya bekerja, semua orang membenci .NET dan ingin memaksa saya menggunakan Python. Saya tidak tahu apakah Anda memperhatikan, tetapi, semakin banyak orang yang meninggalkan kapal dan beralih ke Python. Memberi tahu bos saya bahwa saya perlu membeli lisensi untuk melakukan sesuatu yang sederhana seperti memvalidasi JSON tidak akan terbang. Apa yang akan saya dapatkan sebagai imbalannya dipertanyakan mengapa saya ingin menggunakan .NET sejak awal. Tidak peduli fakta, bahwa ini adalah untuk proyek sumber terbuka di mana Anda tidak bisa mendapatkan lisensi. Mudah-mudahan, saya akan menemukan bahwa NJsonSchema hanya berfungsi. Saya hanya menunjukkan kelalaian mencolok dalam kerangka kerja yang harus jelas bagi siapa saja yang bekerja dengan JSON.

Saya menggunakan Skema JSON di tempat kerja dan saya lebih suka memiliki parser JSON yang sangat bagus daripada parser JSON yang setengah bagus + validator skema JSON. Juga Skema JSON AFAIK adalah _draft_ 7 sekarang. Jadi memiliki skema JSON sebagai perpustakaan eksternal yang dapat berkembang dengan cepat bersama dengan skema masuk akal bagi saya. Memiliki Skema JSON di peta jalan akan menyenangkan.

@jemiller0

Masuk akal untuk memiliki tingkat dukungan yang sama untuk JSON seperti yang secara historis didukung untuk XML.

.Net juga menyertakan dukungan untuk XSLT dan XPath. Jika Anda menginginkan "tingkat dukungan yang sama", bukankah itu berarti Anda juga memerlukan beberapa versi untuk JSON?

Yang ingin saya katakan adalah: ekosistem JSON berbeda dari ekosistem XML. Keduanya memiliki pola penggunaan yang berbeda dan teknologi terkait memiliki jumlah penggunaan dan tingkat standarisasi yang berbeda. Juga, XML telah ditambahkan ke .Net sebelum NuGet, git atau GitHub ada. Saat ini, jauh lebih mudah dan lebih dapat diterima untuk mengandalkan perpustakaan pihak ke-3.

Jadi, tidak, saya rasa tidak masuk akal untuk mengatakan "XML memiliki ini, jadi JSON juga harus memilikinya".

Juga, validasi hanya ortogonal untuk parsing. Saya akan baik-baik saja dengan dukungan validasi yang ditambahkan di beberapa titik (mungkin dalam paket lain sama sekali). Tetapi sama sekali tidak diperlukan untuk dukungan penguraian yang tepat.

Kami membutuhkan cara untuk validasi data yang ketat dalam permintaan API REST.
Karena kami menyimpan json yang datang melalui API tanpa kesalahan dan kemudian kami tidak dapat menguraikannya di JS karena tanda koma dan sebagainya.

Dan mengapa Anda tidak dapat memvalidasi permintaan itu sekarang?

@phillip-haydon @freerider7777 Saya pikir setiap parser JSON yang layak harus mematuhi spesifikasi JSON dan membuang kesalahan (dan/atau peringatan) ketika dokumen tidak terbentuk dengan baik (misalnya, ketika memiliki tanda koma). Itu cukup mendasar tetapi juga berbeda dari validasi yang merupakan perbandingan data JSON dengan skema (setidaknya, begitulah cara saya menggunakan istilah).

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

Microsoft, salah satu perusahaan pengembangan perangkat lunak terbesar, tidak memiliki siapa pun untuk mengerjakan validasi. Pengurai cepat lebih penting. Ini akan memungkinkan Anda mengurai JSON yang tidak valid dengan kecepatan cahaya. :-) Tidak terpikir oleh siapa pun bahwa validasi cepat dapat berguna. Ini seperti ASP.NET Core, pemutakhiran cepat ke Formulir Web.

Dan mengapa Anda tidak dapat memvalidasi permintaan itu sekarang?
@phillip-haydon Dalam kode pengontrol dengan json seperti itu:
ModelState.IsValid == benar

️

Anda dapat melakukan validasi berdasarkan skema json Anda dengan 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>

Saya setuju dengan @lemire , ada perbedaan dalam memvalidasi struktur JSON dan memvalidasi JSON terhadap skema. Saya tidak ragu Microsoft telah menghabiskan waktu dan upaya untuk mengimplementasikan yang pertama dengan benar ... yang terakhir adalah kasus sudut dan saya tidak berpikir itu cocok dengan desain umum perpustakaan JSON ini. Saya cukup yakin mereka telah menjelaskan bahwa perpustakaan JSON ini dirancang HANYA untuk menyediakan penguraian yang cepat, efisien, yang diperlukan agar inti asp.net dapat beroperasi. Itu tidak dirancang untuk menyertakan _extras_ yang datang dengan parser newtonsoft. (lihat komentar @poke sebelumnya di utas).

Saya tidak berpikir fakta bahwa mereka sengaja tidak merancang ini untuk datang dengan semua lonceng dan peluit membuatnya menjadi produk yang lebih rendah.

Apakah ini terjadi pada pengiriman dengan pratinjau 4?

Apakah ada rencana untuk membuat System.Text.Json.Serialization.Policies.JsonValueConverterkelas publik untuk memungkinkan penggantian kelas konverter dari Json.net?

Akankah System.Text.Json dikirimkan dengan dukungan .Net penuh melalui nuget? Pasti akan menyenangkan untuk memastikan interop penuh serta memanfaatkan manfaat dari kerangka kerja penuh.

System.Text.Json baru-baru ini diubah untuk menghasilkan biner netstandard2.0 untuk pengiriman OOB; https://github.com/dotnet/corefx/pull/37129 :

Jika memungkinkan, Anda harus menargetkan .NET Core 3.0 dan mendapatkan API System.Text.Json dalam kotak. Namun, jika Anda perlu mendukung netstandard2.0 (misalnya, jika Anda adalah pengembang perpustakaan), Anda dapat menggunakan paket NuGet kami yang kompatibel dengan netstandard2.0.

manfaat dari kerangka kerja lengkap

Apa ini lagi? 🤔

@khellang

Preferensi saya adalah nuget dengan banyak rasa, termasuk kerangka kerja penuh (4,5 atau minimum apa pun yang dapat diterima), standar, dan inti. Menggunakan rakitan kotak lebih disukai.

Masalah tertaut di atas merujuk ke paket ini, tetapi tidak didukung:

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

Apakah ada paket yang didukung saat ini?

Preferensi saya adalah nuget dengan banyak rasa, termasuk kerangka kerja penuh (4,5 atau minimum apa pun yang dapat diterima), standar, dan inti.

Mengapa Anda lebih suka itu? Jika tidak perlu multi-target, yaitu semua API yang digunakan adalah bagian dari standar, jauh lebih baik untuk memiliki satu target saja 😊

Apakah ada paket yang didukung saat ini?

Saya kira belum dikirim. PR digabung beberapa hari yang lalu. Paket itu dulunya adalah proyek komunitas yang sekarang telah ditransfer ke MS.

@khellang itu tergantung pada spesifiknya -- saya membuat pernyataan umum.

Jika versi standar bersih harus menghilangkan apa pun dari versi inti bersih yang dimungkinkan dengan versi lengkap bersih, saya lebih suka ketiga rasa tersedia. Alasan umum yang sama, saya kira, seperti pernyataan asli dari masalah tertaut di atas tentang lebih memilih pengguna untuk menargetkan versi kotak masuk.

Saat menambahkan referensi ke paket nuget, rasa paling cocok yang sesuai akan dipilih secara otomatis. Jadi, itu bukan masalah besar. Jika perpustakaan yang mengkonsumsi adalah standar bersih, maka rasa standar bersih akan dipilih.

Preferensi umum saya untuk rasa dalam kotak adalah ketika saya goto definition , saya mendapatkan sumber yang didekompilasi. Jika saya goto definition pada pustaka standar bersih, saya biasanya hanya melihat sumber rintisan yang mengeluarkan pengecualian NotImplemented .

manfaat dari kerangka kerja lengkap

Apa ini lagi? 🤔

Banyak aplikasi menggunakan .NET Framework bukan karena mereka benar-benar ingin menjauh dari .NET Core tetapi karena .NET Core bukanlah pilihan. Saya menggunakan .NET Core ketika itu adalah opsi; ketika saya harus menargetkan versi Windows yang lebih rendah dari Windows Server 2012 (minimal versi .NET Core 3.0), saya harus menggunakan .NET Framework. Meskipun saya yakin itu adalah keputusan yang sangat menyakitkan untuk menghentikan dukungan untuk Windows Server 2008 R2 dan di bawahnya, ini adalah keputusan yang sangat menyakitkan bagi setiap perusahaan dengan pelanggan yang membayar dengan server yang tidak ingin mereka tingkatkan/seringkali pada dasarnya dibuat ulang dari awal hanya agar kita dapat menggunakan alat yang sedikit lebih baru.

Tidak ada yang akan lebih bahagia dari saya jika saya bisa berhenti menggunakan .NET Framework besok, tetapi bahkan dengan semua peluang WPF dan Windows Forms di .NET Core 3.0 dan seterusnya, Microsoft membuat hal itu menjadi kemustahilan praktis dengan kebijakan dukungannya. Saya telah mencoba mendiskusikan hal ini dengan siapa saja yang mau mendengarkan di Microsoft, tetapi sayangnya, saya belum menerima email sebanyak yang menyatakan bahwa pesan tersebut telah terkirim.

@JesperTreetop belum lagi kurangnya dukungan LTS untuk versi .NET Core yang layak digunakan untuk perusahaan;) Saya berharap kami akan mendapatkan dukungan LTS pada 3.x - sebagai arsitek .NET org saya, saya akan mendorong Adopsi .NET Core jika kami mendapatkan versi 3.x dengan dukungan LTS.

@marksmeltzer Posting blog Memperkenalkan .NET 5 dari kemarin menunjukkan bahwa .Net Core 3.1 akan menjadi LTS dan direncanakan akan dirilis pada November 2019.

Akankah serializer JSON baru ini mendukung tipe F#?

@rliman yah saat ini tidak mendukung Guid atau Enum sehingga perjalanannya masih panjang. Saya setuju bahwa dukungan penuh untuk tipe opsi F# yang serupa dengan C# nullable harus diperlukan IMHO

Saya pribadi berpikir ini adalah solusi terburu-buru untuk keputusan desain arsitektur yang buruk. Ini seharusnya sudah dilakukan sejak lama.... Sekarang akan menyebabkan banyak masalah di mana-mana... Dari pengembang perpustakaan hingga pengembang perusahaan.

Tidak ada cara mudah untuk "memuluskan" "fitur" baru ini.

Ini adalah MS yang mencoba memecahkan masalah yang mereka sebabkan sejak awal. Dan sekarang semua orang harus membayar harganya.

Dengan NET Core tampaknya dari awal bahwa gerobak sedikit "cepat" ... Pendekatan "gesit" murni ini mungkin perlu sedikit melambat dan membiarkan semua orang mengatur napas.

Sepertinya dengan ASP.NET Core "fitur" ini (melanggar perubahan) telah menjadi normal baru.

Menurut pendapat saya ASP.NET Core sangat membutuhkan pengerjaan ulang proses desain arsitektur mereka. Karena berkali-kali terus membuat fitur "kami akan memperbaikinya nanti".

Saya telah mengembangkan dengan ASP.NET Core sejak masih dalam versi beta awal... Dan ini merupakan peningkatan besar pada .NET.

Tetapi tim MS harus berhenti sejenak dan berpikir bagaimana mereka dapat mengatasi masalah sebenarnya di sini: Keputusan desain arsitektur yang terburu-buru dan tidak konsisten.

Kembali saja dan baca utas lainnya... Sepertinya ini adalah tema yang berulang.

Jadi, mungkin inilah saatnya untuk duduk dan memikirkan kembali pendekatan terbaik apa untuk membuat produk yang lebih stabil.

Klasik .NET mungkin tidak sekuat Core... Tapi sangat stabil dan konsisten sejak 2.0.

Hanya pendapat saya.

Hai @suncodefactory ,
saya ingat beberapa waktu lalu ketika ppl meneriaki ms karena tidak menggunakan perpustakaan opensource, sekarang mereka disalahkan karena melakukannya :D
Dari sudut pandang saya, Aspnet/core MVC api sudah sangat stabil sejak mvc1/2 ! Alasan mengapa aspnet stabil sejak 2.0 adalah karena aspnet tidak pernah berubah/ditingkatkan sama sekali .
Sejujurnya jika Anda menggunakan fitur lanjutan dari perpustakaan serialisasi, Anda memiliki kesempatan untuk memikirkan kembali dan mungkin mendekati masalah dengan struktur data yang sesuai untuk tugas tersebut, alih-alih berpura-pura bahwa semua pembuat serial mendukung semua fitur bahasa, imo itu masalah yang salah untuk dipecahkan, dan cara yang salah untuk menggunakan serialisasi.
Kejelasan, kompatibilitas mundur, dan ekstensi masa depan adalah apa yang mendorong dto serial saya, pertukaran yang sangat berbeda yang digunakan dalam objek logika bisnis umum (yang bersifat pribadi, memiliki banyak fungsi, dll.)

Kami dapat memindahkan layanan mikro dari kerangka kerja bersih ke Linux (inti bersih) tanpa upaya apa pun dari tim produk. Aku tidak tahu apa yang kalian bicarakan. Microsoft melakukan pekerjaan yang hebat dalam mempercepat implementasi perubahan seperti ini yang telah lama tertunda.

Hai @suncodefactory ,
saya ingat beberapa waktu lalu ketika ppl meneriaki ms karena tidak menggunakan perpustakaan opensource, sekarang mereka disalahkan karena melakukannya :D

Bagi saya intinya bukan tentang perpustakaan pihak ketiga ... Ini tentang desain arsitektur yang dalam hal ini kurang atau hanya salah.

Saya juga tidak pernah berbicara tentang asp.net klasik... Saya berbicara tentang .NET Framework 2.0. Dan alasannya stabil bukan karena tidak ada perbaikan seperti yang Anda klaim secara salah (karena .net core didasarkan pada .NET 4.6.1). Alasannya karena direncanakan dan diarsitektur dengan baik.

Adapun seberapa bagus aspnet core vs classic asp.net mvc yang tidak ada hubungannya dengan utas khusus ini.

Utas ini adalah tentang perubahan besar yang akan dikirimkan MS sekali lagi tanpa memikirkannya secara menyeluruh.

Kami dapat memindahkan layanan mikro dari kerangka kerja bersih ke Linux (inti bersih) tanpa upaya apa pun dari tim produk. Aku tidak tahu apa yang kalian bicarakan. Microsoft melakukan pekerjaan yang hebat dalam mempercepat implementasi perubahan seperti ini yang telah lama tertunda.

Perubahan seperti ini seharusnya tidak terjadi sama sekali..... Jadi Anda senang melanggar perubahan?

Dan mengatakan bahwa tim inti asp.net telah melakukan pekerjaan yang baik dalam pengiriman perubahan sama sekali tidak benar.

Saya telah mengembangkan dengan asp.net core sejak beta 3 dan saya cukup yakin proses desain arsitekturnya kurang.

Adapun seberapa bagus asp.net core vs classic... Saya tidak keberatan karena saya juga percaya lebih baik daripada klasik.

Tetapi hanya karena inti asp.net lebih baik daripada klasik tidak berarti mereka melakukan pekerjaan desain arsitektur yang hebat. Keduanya adalah topik yang sama sekali berbeda.

Bisakah kita membatasi diskusi ini pada fungsionalitas JSON di .NET Core 3?

Perubahan seperti ini seharusnya tidak terjadi sama sekali..... Jadi Anda senang melanggar perubahan?

Jadi tidak ada perbaikan yang harus dilakukan? Mengapa Anda bahkan seorang programmer jika Anda tidak ingin perangkat lunak berkembang dan tumbuh dan menjadi lebih baik?

@suncodefactory

Perubahan seperti ini seharusnya tidak terjadi sama sekali..... Jadi Anda senang melanggar perubahan?

Ah, ayolah, Anda membuatnya terdengar seperti "melanggar perubahan" berarti Anda harus membatalkan proyek Anda dan memulai dari awal.

Berapa banyak perubahan yang dapat Anda hitung yang ada di ASP.NET Core 2.x/3.0 yang membutuhkan lebih dari

• Referensi paket yang berbeda
• Menggunakan namespace yang berbeda
• Mengubah lebih dari 5 baris kode
• Menghapus 1-2 baris kode (yaitu Properti dari kelas Opsi)

??

@suncodefactory

Utas ini adalah tentang perubahan besar yang akan dikirimkan MS sekali lagi tanpa memikirkannya secara menyeluruh.

Bagaimana sebenarnya perubahan _breaking_ ini? JSON API yang baru adalah kumpulan API yang benar-benar baru yang diperkenalkan di .NET Core yang tidak menghapus atau merusak hal-hal yang sudah ada. Ya, Anda akan melihat banyak hal dan pustaka beralih ke sana pada akhirnya karena ia menawarkan peluang pengoptimalan yang berbeda, tetapi Anda tidak dipaksa untuk menerapkannya pada kode Anda.

Berbicara tentang ASP.NET Core khususnya meskipun _“itu tidak ada hubungannya dengan utas khusus ini”_, Anda memiliki pilihan di sana untuk tetap menggunakan Newtonsoft.Json jika Anda bergantung pada beberapa fitur yang lebih canggih. Ya, Anda harus mengubah beberapa kode untuk membuatnya berfungsi, tetapi saya tidak menganggap itu benar-benar melanggar mengingat Anda hanya perlu melakukannya jika Anda benar-benar ingin meningkatkan ke versi baru. Itu hal yang menyenangkan sekarang: Anda memiliki lebih banyak pilihan.

Jika Anda tidak menyukai ini karena alasan apa pun, silakan tetap menggunakan .NET Framework yang dikenal, set fitur stabil dan tetap. Itu akan tinggal di sana cukup lama, jadi Anda benar-benar dapat bergantung padanya. Tapi tolong berhenti menggunakan utas ini untuk menyebarkan agenda anti-barang baru Anda ketika _“itu tidak ada hubungannya dengan utas khusus ini”_.

Dua pertanyaan dari pengguna EF Core.

1. Akankah System.Text.Json mendukung referensi melingkar? Referensi melingkar dapat terjadi pada data EF Core di mana ada tautan navigasi yang berjalan dua arah di antara kelas. Json.NET menangani ini dengan pengaturan seperti
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. Dengan munculnya kelas bergaya DDD dengan setter pribadi dan konstruktor pribadi, dapatkah System.Text.Json membatalkan serialisasi kelas jenis ini?

@JonPSmith IMO seharusnya tidak masalah. Anda tidak boleh membuat serial entitas secara langsung. Anda harus membuat serial proyeksi. Ini menghindari referensi melingkar, dan tidak mengekspos semua data, terutama saat Anda menambahkan lebih banyak properti ke entitas yang mungkin menjadi sensitif.

@JonPSmith : Imho kedua kasus penggunaan tidak valid dari praktik terbaik dan sudut pandang DDD.

1. Saya belum pernah melihat praktik terbaik yang merekomendasikan deserializing entitas secara langsung (kecuali dalam contoh tutorial paling sederhana). Referensi melingkar selalu datang dengan biaya. Ini membutuhkan pelacakan objek yang sudah diproses, ini berarti: alokasi memori dan siklus CPU tambahan. Tetapi salah satu tujuan email dari perpustakaan JSON baru adalah untuk menghindari alokasi memori ini
2. Tidak valid juga, karena Anda tidak pernah membuat serial menjadi model Domain, terutama saat Anda mendapatkan data melalui permintaan web seperti panggilan WebApi. Di DDD Anda harus selalu bekerja dengan acara/perintah, mengirim perintah ke aplikasi web Anda, mendapatkan (dan mengeringkan) entitas dari repositori (melalui pemetaan ORM atau EventSourcing), menerapkan perintah, bertahan.

Selain itu, JSON API baru adalah untuk skenario kinerja tinggi. Untuk semua hal lain di mana Anda memerlukan rangkaian fitur yang kaya, Anda (dan harus) tetap menggunakan JSON.NET atau apa pun yang memenuhi kebutuhan Anda.

@suncodefactory Ini adalah kebalikan dari perubahan yang melanggar. Saat ini, di ASP.NET Core 2.2, JSON.NET digunakan oleh kerangka kerja dan juga oleh kode pengguna. Ini berpotensi menyebabkan konflik dengan penggunaan Anda sendiri atas Newtonsoft.Json; jika ASP.NET Core 3.0 pindah ke JSON.NET 12.x dan ada semacam masalah di sana yang merusak aplikasi Anda, Anda akan mendapat masalah.

Misalnya, lihat Microsoft.Extensions.Configuration.Json 2.2.0 - ia memiliki ketergantungan pada Newtonsoft.Json 11.0.2. Itu adalah paket konfigurasi; tidak ada hubungannya dengan penanganan permintaan HTTP atau ASP.NET Core MVC. Atau lihat Microsoft.IdentityModel.Protocols.OpenIdConnect , yang menggunakannya untuk menangani Token Web JSON; itu jalur panas yang membutuhkan kinerja sebanyak mungkin. JSON.NET bukan perpustakaan yang lambat menurut standar apa pun, tetapi ia menyeimbangkan antara kinerja, kekayaan fitur, dan dukungan untuk sejumlah besar skenario pengguna. Pustaka JSON baru Microsoft tidak perlu melakukan itu, karena JSON.NET ada. Sehingga dapat fokus menangani dasar-dasar mutlak dengan performa maksimal.

.NET selalu memiliki solusi serialisasi JSON sendiri di System.Runtime.Serialization.Json , tetapi di dunia kinerja tinggi .NET Core itu bukan solusi yang sangat bagus. Saya tentu tidak ingin itu dipanggil untuk memeriksa kredensial pada setiap permintaan yang masuk. Pustaka JSON baru, dengan penanganan data UTF-8 modern dan alokasi minimal, sangat disambut.

Anda masih dapat mereferensikan Newtonsoft.Json dalam aplikasi Anda, dan terus menggunakannya sebagai saluran deserialisasi/serialisasi untuk data permintaan/tanggapan seperti sebelumnya. Dan mulai sekarang, Anda akan dapat melakukannya tanpa khawatir tentang versi mana kerangka kerja Inti bergantung. Itu adalah kemenangan untuk semua orang.

Terima kasih @phillip-haydon dan @TsengSR atas pemikiran Anda. Saya bertanya apakah fitur ini akan didukung dan Anda mengatakan tidak, yang mengerti dan menerima. Saya akan terus menggunakan Json.NET untuk kasus di mana saya perlu membuat serial/deserialisasi kelas EF Core.

OMONG-OMONG. Saya memang memiliki alasan yang valid untuk membuat serial/deserialisasi kelas entitas EF Core gaya DDD. Saya memiliki perpustakaan yang berisi fitur yang saya sebut Seed from Production yang memungkinkan pengembang mengambil snapshot data dari database produksi, menganonimkan data pribadi apa pun, dan kemudian menyemai database baru dengan snapshot.

Saya memerlukan fitur ini untuk satu di klien saya dan alih-alih menulis hanya untuk mereka, saya membangunnya ke perpustakaan sumber terbuka EfCore.TestSupport sehingga orang lain dapat menggunakannya (dan klien saya tidak perlu membayar saya untuk itu).

Apakah ada rencana untuk mendukung [DataContract] , [DataMember] dan teman-teman?

Hari ini ini adalah cara untuk menentukan bagaimana tipe harus membuat serial/deserialisasi (misalnya nama bidang) dengan cara yang tidak membawa ketergantungan ke perpustakaan serialisasi apa pun ke proyek yang menggunakannya.

JsonNamingPolicy ini hanya mengambil string sehingga tidak ada cara untuk memeriksa atribut anggota.

Hai.
Kami baru saja mencoba untuk mengalihkan layanan mikro kami ke DotNet core 3 preview 6 dan kami tidak dapat melakukan deserialize tipe referensi kami yang tidak dapat diubah: kelas dengan properti yang tidak dapat diubah (tanpa penyetel) dan hanya satu konstruktor untuk mengatur semua properti. Json.net menangani kelas-kelas ini dengan benar.
Apakah ini masalah kebutuhan System.Text.Json API atau apakah ini rencana untuk mendukungnya ?
Terima kasih atas tanggapan Anda

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

Terima kasih @khellang.
Dukungan memang direncanakan tetapi tidak untuk rilis 3.0.
Tampaknya mungkin untuk terus menggunakan Json.net dengan DotNet core 3 tetapi saya tidak tahu bagaimana melakukannya (menambahkan referensi paket tidak cukup). Apakah ada cara untuk melakukan itu?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

Terima kasih atas bantuan Anda.
Berhasil !
Saya melewatkan panduan migrasi di mana semuanya dijelaskan:

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

IMO json.net setengah matang dan menjadikannya default (yaitu untuk signalr) yang memecahkan kode yang ada adalah prematur.

Di sisi lain, migrasi dari .NET Core 2.2 ke 3.0 adalah peningkatan versi utama dan bahkan jika tim .NET Core tidak secara ketat mengikuti versi semantik, saya berharap hal-hal akan rusak saat memutakhirkan dari satu versi ke versi lain tanpa perubahan eksplisit (seperti menambahkan perpustakaan Newtonsoft secara eksplisit di dalam pipa)

Penutupan mengingat ini adalah pengumuman dan bukan masalah

Meskipun komunitas memiliki banyak suara menentang peningkatan, sebagai kerangka kerja berkinerja tinggi yang baru, kecepatan yang buruk tidak dapat diterima.

Saya tahu itu telah dikatakan sebelumnya, tetapi saya ingin menambahkan keinginan saya juga.

Akan sangat luar biasa jika kita dapat memiliki objek yang tidak dapat diubah. Saya tahu itu mungkin dengan menambahkan Json.NET ke MVC-Pipeline tetapi dalam kasus saya, semua pengujian saya gagal karena saya menggunakan ReadAsAsync<> yang sekarang diimplementasikan di suatu tempat dalam ketergantungan rekan Microsoft.AspNet.WebApi.Client dan itu bergantung pada System.Text.Json

Kami menyediakan perpustakaan .NET Standard Class kepada pelanggan sehingga mereka dapat menggunakan perpustakaan kami untuk bekerja pada platform apa pun yang mendukung .NET Standard. Kita perlu menggunakan System.Text.Json di perpustakaan kelas kita. Apa rencana untuk mendukung System.Text.Json di .NET Standard?

@alsami

Akan sangat luar biasa jika kita dapat memiliki objek yang tidak dapat diubah.

Apakah Anda hanya memerlukan kemampuan untuk mencegah orang lain memutasikannya atau apakah Anda juga memerlukan kemampuan untuk membuat instance baru dengan suku cadang yang diganti dengan cerdas (seperti koleksi yang tidak dapat diubah dan Roslyn)? Jika Anda membutuhkan yang pertama, kami telah membantu Anda dengan DOM API JsonDocument .

@mwoo-o

Apa rencana untuk mendukung System.Text.Json di .NET Standard?

Ini tersedia sebagai paket NuGet untuk .NET Standard 2.0: System.Text.Json .

@terrajobst

Terima kasih. Kapan System.Text.Json ini akan disertakan dalam .NET Standard SDK?
Akankah .NET standar 3.0 (atau beberapa versi rilis lain yang lebih baru) menyertakan paket System.Text.Json? Apakah itu akan terjadi dalam rilis produksi .NET Core 3.0 SDK?

@terrajobst

Apakah ada rencana untuk membuat metode Deserialize bekerja dengan PipeReader? Atau tambahkan metode Patch yang dapat digunakan dalam skenario streaming di mana kita tidak memiliki semua data saat memulai deserialization.

Berikut adalah versi sederhana dari API yang diusulkan:

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

kemampuan untuk mencegah orang lain mengubahnya

Hanya ini saat ini. Benar-benar hanya untuk 'data-transfer-objek'. Kabar baik!

@mwoo-o

Terima kasih. Kapan System.Text.Json ini akan disertakan dalam .NET Standard SDK?
Akankah .NET standar 3.0 (atau beberapa versi rilis lain yang lebih baru) menyertakan paket System.Text.Json? Apakah itu akan terjadi dalam rilis produksi .NET Core 3.0 SDK?

Tidak ada .NET Standard SDK. .NET Standard adalah permukaan API, tersedia di semua Platform yang didukung. Anda dapat mengirimkan System.Text.Json dalam aplikasi apa pun yang menjalankan target platform yang didukung yang didukung oleh .NET Standard, lihat dukungan implementasi .NET .

@TsengSR

Tidak ada .NET Standard SDK. .NET Standard adalah permukaan API, tersedia di semua Platform yang didukung.

Nah, ada jenis proyek yang memungkinkan Anda menggunakan API. Saya pikir @mwoo-o menanyakan apakah kami memiliki rencana untuk menambahkan System.Text.Json ke .NET Standard. Jawabannya adalah tidak. Benar, sekarang kami berencana meninggalkan ini menjadi paket NuGet.

Ini mengerikan. Terlalu sedikit fungsi untuk diterapkan dalam proyek.