Runtime: .NET Core 3.0 में JSON का भविष्य

यह भी खूब रही। मैं जेसन पार्सिंग को तेज और कम आवंटित करने के लिए हूं।

क्या json.net की उन विशेषताओं के बारे में चर्चा होगी जिनका समर्थन नया json apis करेगा? अगर वहाँ है, तो मुझे लगता है कि दो प्रमुख विशेषताएं जो दिमाग में आती हैं, वे नाम बदलना/आवरण करना और अशक्त गुणों की अनदेखी करना होगा।

क्या json.net की उन विशेषताओं के बारे में चर्चा होगी जिनका समर्थन नया json apis करेगा?

हां। हमने कुछ शुरुआती सोच के साथ काम किया है कि हम CoreFx में माइग्रेट करेंगे। यह एक ऐसी सुविधा होगी जिसे हमेशा की तरह खुले में डिजाइन और निर्मित किया गया है। इसके अलावा, मैं कई लोकप्रिय JSON लाइब्रेरी के लेखकों तक पहुंचा हूं और उन्हें इस घोषणा के शुरुआती ड्राफ्ट की समीक्षा करने के लिए आमंत्रित किया है। मेरी आशा है कि हम मंच के लिए एक ठोस JSON घटक बनाने के लिए एक साथ काम कर सकते हैं, जबकि इसके ऊपर पारिस्थितिकी तंत्र (जैसे ASP.NET कोर) को दूसरों के लिए अनुमति देने के लिए प्लग करने योग्य रखते हैं। अंत में, अलग-अलग उपभोक्ताओं के अलग-अलग लक्ष्य होंगे और एक अलग लाइब्रेरी में प्लग-इन करने में सक्षम होने का मतलब है कि आप उस घटक को चुनने में अधिकतम लचीलापन प्राप्त कर सकते हैं जिसमें आपके ऐप के लिए सर्वोत्तम लागत/लाभ है।

अरे @terrajobst। क्या नया JSON नेटस्टैंडर्ड एपीआई सतह के रूप में दिखाई देगा, या अभी के लिए कोर में एकीकृत होगा?

अरे @terrajobst। क्या नया JSON नेटस्टैंडर्ड एपीआई सतह के रूप में दिखाई देगा, या अभी के लिए कोर में एकीकृत होगा?

हां, सवाल सिर्फ इतना है कि वह कौन सी रिलीज ट्रेन पकड़ सकती है। 2.1 बहुत जल्दी हो सकता है।

तो फ्रेमवर्क में बेक किए गए JSON पार्सिंग बिट्स को उपलब्ध होने की योजना है जब v3.0 RTM में जाता है या केवल ASP.NET कोर में एकीकरण एपिस पूरा होगा (केवल एक कार्यान्वयन के साथ - JSON.NET) जो एक पर स्वैपेबल होगा बाद की तिथि?

3.0 की योजना इस प्रकार है:

1. अंतर्निहित उच्च-प्रदर्शन JSON APIs। निम्न स्तर का पाठक/लेखक, एक Stream आधारित पाठक/लेखक, और एक धारावाहिक।
2. ASP.NET Core JSON घटक के लिए प्लग करने योग्य wrt है।

एक खुला प्रश्न है कि 3.0 में ASP.NET के लिए कौन से टेम्प्लेट उपयोग करेंगे। निष्ठा के आधार पर हम 3.0 तक प्रदान कर सकते हैं हम उन्हें Json.NET एकीकरण पैकेज में खींच सकते हैं। हालाँकि, लक्ष्य पर्याप्त निष्ठा और समानता प्रदान करना है जो केवल डिफ़ॉल्ट रूप से अंतर्निहित लोगों पर निर्भर करता है।

धन्यवाद - इससे चीजों को साफ़ करने में मदद मिलती है। मैं

और कुछ अतिरिक्त प्रश्न!

यदि एकीकरण पैकेज का उपयोग किया जाता है, तो क्या इसका उपयोग संपूर्ण ASP.NET कोर पाइपलाइन में या केवल कुछ स्थानों पर किया जाएगा?
मुझे लगता है कि Kestrel हमेशा आंतरिक पाठकों/लेखकों का उपयोग करेगा।

क्या एपी एर्गोनॉमिक्स होगा:

• एकीकरण की आपूर्ति तभी करें जब आप बिल्ट-इन सुविधा सेट को बढ़ाना चाहते हैं।
• हमेशा एक एकीकरण पैकेज की आपूर्ति करें लेकिन एक अंतर्निहित होगा, निम्न स्तर के पाठक/लेखकों को उच्च स्तर की कार्यक्षमता में एकीकृत करना।

यह मानते हुए कि इस नए पार्सर का उपयोग सभी अंतर्निहित JSON सामग्री जैसे appSettings.json , क्या मैं टिप्पणियों का समर्थन करने के लिए प्रारंभिक अनुरोध कर सकता हूं?

धन्यवाद।

यह कमाल की खबर है! त्वरित प्रश्न: यह पुस्तकालय किन पैकेजों पर निर्भर करेगा?

उत्पादन ग्राहकों द्वारा परीक्षण किए गए पहिये को फिर से क्यों बनाया जाए? अगर Json.Net में कोई समस्या है, तो बस एक पीआर भेजें क्योंकि यह खुला स्रोत है।

मुझे लगता है कि Json.NET के साथ समस्या यह है कि यह Microsoft के स्वामित्व में नहीं है, इसलिए इसे प्रतिस्थापित करना होगा। ओह, लेकिन पहले से ही System.Runtime.Serialization में एक है, जिसे DataContractJsonSerializer कहा जाता है। क्या आप इसका उपयोग कर सकते हैं, या नए एपीआई, DIY को कोड करना इतना मजेदार है कि इसे टाला नहीं जा सकता है?

इसका कारण यह है कि मैं इससे बहुत खुश नहीं हूं क्योंकि Json.Net पहले से ही किनारे के मामलों का समर्थन करता है जैसे एफ # डिस्क्रिमिनेटेड यूनियन। विशेष रूप से अच्छी तरह से नहीं, लेकिन एक स्तर पर डेवलपर्स इसके साथ रह सकते हैं। इसके बजाय कोई भी नया एपीआई आमतौर पर ASP.NET-वेबसाइट के उपयोग के मामले के अलावा कुछ भी भूल जाता है।

@markrendle टिप्पणियों की अनुमति देने के लिए JsonReader (कार्य प्रगति पर है) पर एक ऑप्ट-इन सेटिंग है। कॉन्फ़िगरेशन सिस्टम डिफ़ॉल्ट रूप से उस सेटिंग को सक्षम करेगा।

@ थोरियम क्या आपने वास्तव में ओपी पढ़ा था? यह बताता है कि JSON.NET क्यों नहीं, और JSON.NET को ऐड-इन पैकेज के साथ आधिकारिक रूप से समर्थित होना जारी रहेगा।

@JamesNK

@ थोरियम Json.NET दूर नहीं जा रहा है। आप कुछ भी नहीं खो रहे हैं। यह सरल और उच्च प्रदर्शन परिदृश्यों के लिए एक और विकल्प है।

@ थोरियम Json.NET दूर नहीं जा रहा है। आप कुछ भी नहीं खो रहे हैं। यह सरल और उच्च प्रदर्शन परिदृश्यों के लिए एक और विकल्प है।

कैसे उत्पन्न होगा Json पिछड़े संगत होने के लिए?

उदाहरण के लिए, मैं सिग्नलआर का उपयोग कर रहा हूं जो पृष्ठभूमि में Json.NET का उपयोग कर रहा है। अब, क्या मेरी F# भेदभाव वाली यूनियनें समान संरचनाओं के लिए क्रमबद्ध होंगी ताकि मैं अपने सर्वर की वर्तमान सिग्नलआर लाइब्रेरी की तुलना में अलग-अलग संरचनाओं को क्रमबद्ध करने के कारण रनटाइम अपवादों को फेंकने वाली नई Azure सिग्नल सेवा (बैकप्लेन) के साथ मुद्दों से नहीं लड़ूंगा?

मुझे उम्मीद है कि अन्य लोग नए एपीआई को जल्दी से उठाएंगे। आपको देखकर, @AzureCosmosDB ;-)

क्या आप जॉब्जेक्ट जैसी कक्षा और डायनामिक के लिए समर्थन शामिल करने की योजना बना रहे हैं या यह इस सुविधा के दायरे से बाहर है?

मैं इस libs में से एक में एक नज़र डालने की सलाह देता हूं:

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

यह प्रेरणा पाने का एक बहुत अच्छा तरीका हो सकता है।

क्या DataContractJsonSerializer इस नए पाठक/लेखक का आंतरिक रूप से उपयोग किया जाएगा?

मैं कई लोकप्रिय JSON लाइब्रेरी के लेखकों के पास पहुंचा हूं और उन्हें इस घोषणा के शुरुआती ड्राफ्ट की समीक्षा करने के लिए आमंत्रित किया है। मेरी आशा है कि हम मंच के लिए एक ठोस JSON घटक बनाने के लिए एक साथ काम कर सकते हैं, जबकि इसके ऊपर पारिस्थितिकी तंत्र (जैसे ASP.NET कोर) को दूसरों के लिए अनुमति देने के लिए प्लग करने योग्य रखते हैं।

क्या कोई कारण है कि JSON.NET के बाद दूसरी सबसे लोकप्रिय JSON लाइब्रेरी - ServiceStack.Text जिसे पहले से ही शहद की मक्खी बहिष्कृत किया गया है? ServiceStack.Text serializers का उपयोग ServiceStack को शक्ति प्रदान करने के लिए किया जाता है जो कि सबसे लोकप्रिय "वैकल्पिक .NET कोर संगत वेब फ्रेमवर्क" में से एक है जो .NET में अधिक प्लेटफॉर्म पर चलने का समर्थन करता है । मैं उत्सुक हूं कि आप किस "पारिस्थितिकी तंत्र" का जिक्र कर रहे हैं और यहां "एक साथ काम" करने की उम्मीद कर रहे हैं? मुझे स्पष्ट रूप से इस बात में दिलचस्पी होगी कि ये "प्लग करने योग्य" एपीआई कितने संगत हैं या क्या यह एक और क्षेत्र है जहां नए एमएस पुस्तकालयों को अपनाने और एकीकरण समाप्त होने वाले पारिस्थितिक तंत्र को मारने के लिए समाप्त होता है।

यह एमआईटी लाइसेंस प्राप्त उच्च-प्रदर्शन https://github.com/neuecc/Utf8Json की समीक्षा करने लायक हो सकता है

यह निश्चित रूप से हमें चाहिए ... मुख्य वर्ग के नाम के लिए मेरा सुझाव, बस " Json " का उपयोग करें।

@terrajobst मैं सोच रहा था कि ऐसा कब होगा ...

मैं हमेशा सोच रहा था कि JSON.Net को एक अमूर्तता के बजाय प्रत्यक्ष निर्भरता के रूप में क्यों जोड़ा गया था (यहां तक ​​​​कि यह .Net पारिस्थितिकी तंत्र के लिए वास्तविक JSON पैकेज है)।

हालाँकि, मुझे लगता है कि JSON के लिए एक अमूर्त जोड़ना-केवल किसी तरह आपके पैरों पर एक शूट है। मुझे लगता है कि हमारे पास ऑरलियन्स IExternalSerializer में Microsoft.Extensions.Serialization आकार में एक _serializer_ अमूर्तता है या कुछ और अधिक प्रभावी होगा ...

क्या JSON-only बनाने का कोई विशेष कारण है? मैं अन्य मामलों को देखता हूं जहां लोग अन्य प्रकार के धारावाहिकों को प्लग कर सकते हैं ...

@galvesribeiro IOutputFormatter / IInputFormatter जैसा कुछ?

@ yaakov-h उन लोगों से अवगत नहीं था ... क्या वे हैं?

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

ठीक है ... अब समझ में आता है। तो यह _new_ JSON-only एब्स्ट्रैक्शन कहां खेलने के लिए आता है?

इस उपक्रम को शुरू करने का निर्णय भी System.String (UTF-16 String) की अक्षमता के बारे में एक वसीयतनामा है।
मुझे लगता है कि नया JSON हुक जो एएसपीनेट और एक जेसन लाइब्रेरी के बीच सभी जेसन हैंडलिंग को सारगर्भित करेगा, यदि आप पहले यूटीएफ -8 स्ट्रिंग बेसटाइप बनाने के लिए कार्य से निपटते हैं तो यह काफी बेहतर दिखाई देगा।
-> शायद एक सिस्टम बनाएं। Utf8String

हाँ... मुझे याद है @migueldeicaza ने कुछ समय पहले कहा था कि किसी दिन, वह .Net को utf8 स्ट्रिंग्स का उपयोग करेगा

@jges42 @galvesribeiro Utf8String जोड़ने का प्रस्ताव https://github.com/dotnet/corefx/issues/30503 है। ऐसा लगता है कि यह .Net Core 3.0 के लिए भी योजनाबद्ध है।

क्या इन नए JSON API में Utf8String और char / string दोनों के लिए समर्पित कोड पथ होंगे, या ऑप्टिमाइज़ेशन में यथास्थिति को फ़्लिप करना शामिल है, ताकि वह सब कुछ जो UTF-8 नहीं है इसके बजाय इसे ट्रांसकोड करना होगा? (इसमें आवश्यक रूप से एक बड़ी लागत शामिल नहीं है क्योंकि लगभग कुछ भी string का मूल UCS-2 UTF-16 नहीं है और अभी भी इसके लिए अनुकूलित/लेखा किया जाना है, मैं बस इसका एक विचार प्राप्त करने की कोशिश कर रहा हूं एपीआई सतह। Kestrel को और अधिक कुशल बनाने के लिए ऐसा करना उचित है; मुझे उम्मीद है कि डिजाइन Kestrel की तुलना में अधिक ग्राहकों को मानता है।)

@galvesribeiro
वास्तव में मुझे लगता है कि आप एक अच्छी बात उठाते हैं। मुझे लगता है कि एक कुशल सीरियलाइजेशन फ्रेमवर्क बनाना और एक कुशल जेसन डिकोडर/एनकोडर दो तरह की समस्याएं हैं। मुझे पता है कि किसी संरचना को Serializable के रूप में चिह्नित करने के कुछ तरीके हैं लेकिन मैंने इसे कभी भी किसी भी जेसन सीरियलाइजेशन के लिए उपयोग नहीं किया है।

रस्ट की सेर्डे परियोजना वास्तव में समस्या को 2 समस्याओं में विभाजित करके एक अच्छी अवधारणा है:

1. Serialize/Deserialize (C# में इंटरफेस के समान लक्षण) जिसका अर्थ है कि इस इंटरफ़ेस से प्राप्त होने वाला कोई भी प्रकार क्रमबद्ध/deserialized हो सकता है
2. Serializer/Deserializer प्रारूप विशिष्ट कार्यान्वयन है।

एक प्रकार या तो हाथ से या मैक्रो (जिसे एक कंपाइलर प्लगइन के कुछ रूप के रूप में देखा जा सकता है) द्वारा सीरियलाइज/डिसेरियलाइज लागू कर सकता है जो उन लक्षणों को लागू करने के लिए आवश्यक कोड उत्पन्न करता है। यदि किसी प्रकार में एक बच्चा प्रकार होता है जो उन लक्षणों को लागू नहीं करता है तो यह संकलन समय पर भी चेतावनी देगा। यह समग्र रूप से एक अच्छी अवधारणा है क्योंकि इसका मतलब है कि आप कुछ डेटा ऑब्जेक्ट्स को किसी भी समर्थित प्रारूप के लिए (डी) क्रमबद्ध कर सकते हैं। इस तरह से एक प्रारूप लिखना बहुत आसान है।

मुझे नहीं लगता कि सर्डे के तरीके सभी सी # के लिए काम करेंगे क्योंकि यह वास्तव में किसी भी प्रकार की विशिष्ट विशेषताओं की पेशकश नहीं करता है जो कुछ डेटा संरचनाओं के लिए महत्वपूर्ण हो सकते हैं। तो इसके लिए कुछ काम करना होगा। इसके अलावा एओटी संकलन पर विचार करना कुछ परियोजनाओं (डब्ल्यूएएसएम) के लिए बहुत महत्वपूर्ण होगा, इसे इसके साथ अच्छी तरह से काम करना चाहिए।

इसे और अधिक स्पष्ट करने के लिए सर्डे डॉक्स का लिंक यहां दिया गया है (अवधारणा को देखने के लिए नीचे के 4 लक्षणों पर क्लिक करें):
https://docs.serde.rs

@mythz ServiceStack.Text का लाइसेंस कुछ FOSS अपवाद के साथ AGPL है - यह शायद लोगों को मालिकाना सॉफ़्टवेयर में इसका उपयोग करने से रोकेगा। इसके अलावा, मुझे लगता है कि इसे छूने के लिए Microsoft कर्मचारियों के लिए कानूनी से मंजूरी की आवश्यकता है, और किसी भी कर्मचारी ने स्रोत को देखा है, उसे किसी अन्य JSON लाइब्रेरी या संबंधित तकनीक पर काम करने से रोक दिया जा सकता है।

@ poizan42 ServiceStack.Text दोहरे लाइसेंस के साथ OSS/वाणिज्यिक लाइसेंस दोनों के साथ OSS और बंद स्रोत वाणिज्यिक परियोजनाओं दोनों में उपयोग करने के लिए स्वतंत्र है। लेकिन स्रोत कोड लाइसेंस अप्रासंगिक हैं क्योंकि एमएस अपना कार्यान्वयन विकसित कर रहा है।

दावा यह था कि एमएस "प्लग करने योग्य" जेएसओएन सीरिएलाइज़र एपीआई विकसित करने के लिए "पारिस्थितिकी तंत्र" के साथ सहयोग कर रहा था - यदि सर्विसस्टैक लगभग एक दशक में सक्रिय विकास में रहा है जो कुछ स्वतंत्र .NET सॉफ़्टवेयर सूटों में से एक है जो इसे बनाए रखने में कामयाब रहा है अपने जीवनकाल में एमएस के बाहर खुद का स्वतंत्र स्वस्थ समुदाय, जो JSON.NET के बाद दूसरा सबसे लोकप्रिय JSON सीरिएलाइज़र बनाए रखता है और जो दूसरा सबसे लोकप्रिय सक्रिय रूप से विकसित वेब फ्रेमवर्क (एमएस के बाहर) प्रतीत होता है, जो किसी भी एमएस की तुलना में अधिक प्लेटफॉर्म पर चलता है। वेब ढांचे को "पारिस्थितिकी तंत्र" का हिस्सा नहीं माना जाता है जो मुख्य रूप से इन परिवर्तनों से प्रभावित है, मैं उत्सुक हूं कि वे किस "पारिस्थितिकी तंत्र" का जिक्र कर रहे हैं और हमें क्यों बाहर रखा जा रहा है और कितने अन्य को बाहर रखा जा रहा है क्योंकि वे हैं "पारिस्थितिकी तंत्र" का हिस्सा नहीं माना जाता है।

मैं यह सब आक्रोश नहीं समझता। Asp.net ने आपको json.net के एक विशिष्ट संस्करण का उपयोग करने के लिए मजबूर किया। वे इसे बदल रहे हैं ताकि आप जो भी JSON पार्सर चाहते हैं उसे चुन सकें (या इसे मिलाएं), और एक डिफ़ॉल्ट ओओबी है। सर्विसस्टैक को इस परिवर्तन के बारे में खुश होना चाहिए और इस विकास पर निगरानी और प्रतिक्रिया प्रदान करनी चाहिए, न कि केवल इस बारे में रोना चाहिए कि इसे कैसे अनदेखा किया गया था, जो शायद ही कभी एक अच्छी सामुदायिक भावना को बढ़ावा देने का एक प्रभावी तरीका है। मैं व्यक्तिगत रूप से .net टीम के कई सदस्यों को जानता हूं और मुझे विश्वास है कि उनका कोई द्वेष नहीं था। वे सभी ओएसएस और सामुदायिक कार्य के बड़े समर्थक हैं।
व्यक्तिगत रूप से कोई भी जीपीएल व्युत्पन्न लाइसेंस मेरे लिए एक बड़ी स्वचालित संख्या होगी। अपाचे या एमआईटी मेरे और मेरे ग्राहकों के लिए या हम आगे बढ़ेंगे। कोई रहस्यमय दोहरी लाइसेंस नहीं।

Asp.net ने आपको json.net के एक विशिष्ट संस्करण का उपयोग करने के लिए मजबूर किया

नहीं। ऐसा कैसे?

मैं यह सब आक्रोश नहीं समझता।

दूसरा!

मुझे व्यक्तिगत रूप से खुशी है कि हम अंततः JSON.Net को डाउनलोड किए बिना अपनी पसंद के सीरिएलाइज़र का उपयोग करने में सक्षम होंगे, केवल इसका उपयोग न करने के लिए, लेकिन फिर भी इसे शिप करने की आवश्यकता है क्योंकि ASP.Net के पास पुस्तकालय के लिए एक कठिन संदर्भ है।

(बेशर्म प्लग: https://github.com/gregsdennis/Manatee.Json)

@dotMorten

मैं यह सब आक्रोश नहीं समझता।

क्योंकि आपने या तो मेरी टिप्पणियों को पढ़ा या समझा नहीं है। अपनी खुद की कहानी बनाने के बजाय सीधे मेरी टिप्पणियों का जवाब देने की कोशिश करें (अर्थात उद्धरण सुविधा का उपयोग करें)।

वे इसे बदल रहे हैं ताकि आप जो भी JSON पार्सर चाहें चुन सकें (या इसे मिलाएं)

तो एक जादू "मिश्रण" की तरह, वे स्वचालित रूप से सबसे इष्टतम एपीआई और प्लगेबिलिटी विकल्प चुनेंगे जो मौजूदा .NET धारावाहिक सीधे प्लग इन/आउट करने में सक्षम होने जा रहे हैं और तार-प्रारूप के साथ अपने आंतरिक अनुकूलन विकल्पों में मिश्रण कर सकते हैं। वही और सब कुछ सभी धारावाहिकों में काम करने जा रहा है? उस स्थिति में आप सही कह रहे हैं कि एपीआई के ठोस होने से पहले किसी सहयोग या एकीकरण परीक्षण की आवश्यकता नहीं है। या शायद सीरियलाइज़र कार्यान्वयन विभिन्न मतभेदों और विचारों के साथ अधिक बारीक हैं और सब कुछ सिर्फ काम करने वाला नहीं है, सभी अनुकूलन विकल्प बिल्कुल लागू नहीं होने जा रहे हैं, वायर-प्रारूप समान नहीं होने वाला है और इसे हासिल करना संभव नहीं है विभिन्न कार्यान्वयन के बीच सही इंटरऑप। आप जिस "प्लगबिलिटी" पर प्रकाश डाल रहे हैं, वह एक बड़ा अंतर बनाता है जो यह निर्धारित कर सकता है कि हमें कितना पुनर्लेखन करना होगा और मौजूदा और इस नए कार्यान्वयन का समर्थन करना संभव होगा या नहीं।

सर्विसस्टैक को इस बदलाव से खुश होना चाहिए और इस विकास पर निगरानी और फीडबैक देना चाहिए,

जो हमें करने का कोई अवसर नहीं दिया गया है (या अभी भी पता है कि कैसे करना है), लेकिन मुझे यह बताने के लिए धन्यवाद कि मुझे कैसा महसूस करना चाहिए। मैं प्रत्येक की ताकत का आकलन करने में सक्षम होने से पहले पुस्तकालय की कार्यक्षमता, अंतःक्रियाशीलता और संगतता का आकलन करना पसंद करूंगा। हो सकता है कि यह बहुत अच्छा होगा और दोनों कार्यान्वयनों का समर्थन करना आसान होगा लेकिन विभिन्न धारावाहिक कार्यान्वयन के साथ अंतःक्रिया करने के अनुभव से असंगतताओं और कोने के मामलों और विभिन्न धारावाहिक-विशिष्ट कार्यान्वयन और सुविधाओं पर निर्भरता से भरा हुआ है। मेरी भविष्यवाणी यह ​​​​है कि JSON.NET और डिफ़ॉल्ट इम्प्लांट के बीच इंटरऑप बहुत अच्छा होगा क्योंकि यह उनका डिज़ाइन लक्ष्य है और इसके खिलाफ क्या परीक्षण किया जा रहा है लेकिन अन्य धारावाहिक भाग्यशाली नहीं होंगे।

इसकी उपेक्षा कैसे की गई, इसके बारे में केवल रोने के बजाय, जो शायद ही कभी एक अच्छी सामुदायिक भावना को बढ़ावा देने का एक प्रभावी तरीका है।

मैं उनके दावे को चुनौती दे रहा हूं कि उन्होंने इसे "पारिस्थितिकी तंत्र" के सहयोग से विकसित किया है, .NET का मौजूदा पारिस्थितिकी तंत्र को हर बार "डिफ़ॉल्ट" पुस्तकालय को बंडल करने का इतिहास रहा है, जिसकी मैं भी उम्मीद कर रहा हूं हो रहा है यहां (मैं एक ऐसे समय को याद करने के लिए संघर्ष कर रहा हूं जब डिफ़ॉल्ट को बंडल करने से पारिस्थितिकी तंत्र को कभी मदद मिली है)। लेकिन परवाह किए बिना, हमें जो कुछ भी वे जारी कर रहे हैं उसके साथ सहज एकीकरण विकसित करने की आवश्यकता है जिसे मैं एपीआई के जमे हुए होने से पहले एक्सेस और इनपुट प्राप्त करने में सक्षम होना चाहता हूं। लेकिन यह ठीक है, मैं आपसे इस बात की परवाह करने की उम्मीद नहीं करता कि यह मौजूदा ढांचे/पुस्तकालयों को कैसे प्रभावित करता है, जिन्हें मौजूदा और भविष्य के कार्यान्वयन का समर्थन करने की आवश्यकता है, आप केवल तभी चिंतित हैं जब JSON.NET समर्थित रहता है या नहीं क्योंकि यह सब आपको प्रभावित करता है, लेकिन अपनी धारणाओं पर पकड़ बनाने की कोशिश करें और हमें बताएं कि हमें इस तरह के विघटनकारी परिवर्तनों को अवशोषित करने के बारे में कैसा महसूस करना चाहिए।

मैं ऐसे समय को याद करने के लिए संघर्ष कर रहा हूं जब डिफ़ॉल्ट को बंडल करने से पारिस्थितिकी तंत्र को कभी मदद मिली है

ओह अब छोड़िए भी!

(बाकी में मैं अधिकतर आपकी भावनाओं से सहमत हूँ)

@mythz मुझे आश्चर्य है कि यह किसी भी समस्या का कारण

मेरी भविष्यवाणी यह ​​​​है कि JSON.NET और डिफ़ॉल्ट इम्प्लांट के बीच इंटरऑप बहुत अच्छा होगा क्योंकि यह उनका डिज़ाइन लक्ष्य है और इसके खिलाफ क्या परीक्षण किया जा रहा है लेकिन अन्य धारावाहिक भाग्यशाली नहीं होंगे।

मैं आपको पहले ही बता सकता हूं कि जो हम शिप करेंगे वह JSON.NET द्वारा समर्थित सुविधाओं के सरगम ​​​​का समर्थन नहीं करेगा। तो यह पहले से ही सच नहीं है और वास्तव में, हम उम्मीद करते हैं कि यह कुछ मामलों में कम सक्षम होगा (प्रदर्शन और दायरे के कारणों के कारण)।

प्लगैबिलिटी ज्यादातर आज पहले से मौजूद है और हमारे पास हर जगह डिफ़ॉल्ट JSON.NET कार्यान्वयन है। यह सिर्फ उस डिफ़ॉल्ट को नया JSON सीरिएलाइज़र बनने के लिए बदल रहा है ...

@abatishchev

मैं वास्तव में किसी को भी याद नहीं कर सकता, जब उनके आधार ढांचे (या परियोजनाओं) में एक डिफ़ॉल्ट कार्यान्वयन को एम्बेड या अपनाने से मौजूदा आसपास के पारिस्थितिकी तंत्र को लाभ हुआ हो? हर बार मैंने इसे बंडल करते हुए देखा है जैसे कि नुगेट, एमवीसी, ओआरएम, यूनिट टेस्टिंग, वेब एपीआई, आदि इसका केवल एक हानिकारक प्रभाव पड़ा है, प्रभावी रूप से उस स्थान के भीतर प्रतिस्पर्धा के लिए ऑक्सीजन और प्रेरणा ले रहा है।

ऐसे समय होते हैं जहां ASP.NET Ajax जैसे प्रतिस्पर्धी पुस्तकालय प्रतिस्पर्धा करने में विफल रहे हैं, जहां उन्होंने इसे छोड़ दिया और jQuery को अपनाया, लेकिन मुझे ऐसा समय याद नहीं है जहां इसने कभी मदद की हो? नोट: यह कई वर्षों के बाद .NET का बारीकी से अनुसरण करने का मेरा अवलोकन है, शायद कुछ उदाहरण हैं और मुझे कुछ के बारे में जानने की उत्सुकता होगी? लेकिन मेरे पीओवी से एमएस डिफॉल्ट के प्रभाव का मौजूदा पारिस्थितिकी तंत्र पर एक हानिकारक प्रभाव पड़ता है जो इसे बदल रहा है।

Microsoft द्वारा डिफ़ॉल्ट समाधान होने से उपयोगकर्ताओं के लिए @mythz लाभ वैकल्पिक समाधान के लेखकों के लिए लाभों के समान नहीं है। EF .NET की दुनिया में सबसे अच्छा ORM है और MSTest उस समय NUnit से बेहतर था। मेरी राय में।

लेकिन आइए बाढ़ न करें और विषय पर टिके रहें। चीयर्स!

@davidfowl यह सिर्फ उस डिफ़ॉल्ट को नया JSON

मैं प्रस्तावित करना चाहता हूं कि कोई डिफ़ॉल्ट धारावाहिक नहीं है और इसके लिए एक कार्यान्वयन डाउनलोड किया जाना चाहिए। यदि कोई डिफ़ॉल्ट होना चाहिए, तो क्या इसे ढांचे या कुछ अलग पुस्तकालय में बेक किया जाएगा (जैसा कि वर्तमान में मामला है)?

मैं प्रस्तावित करना चाहता हूं कि कोई डिफ़ॉल्ट धारावाहिक नहीं है और इसके लिए एक कार्यान्वयन डाउनलोड किया जाना चाहिए। यदि कोई डिफ़ॉल्ट होना चाहिए, तो क्या इसे ढांचे या कुछ अलग पुस्तकालय में बेक किया जाएगा (जैसा कि वर्तमान में मामला है)?

यह अनुचित है क्योंकि अनुभव सबपर होगा। हर आधुनिक प्लेटफॉर्म में JSON बिल्ट इन होता है।

@davidfowl अब समस्या पैदा नहीं कर रहा है क्योंकि यह अप्रकाशित है, लेकिन हमें अभी भी उस व्यवधान और कार्य के दायरे का आकलन करने की आवश्यकता है जिससे यह होने वाला है। इसे निर्बाध रूप से समर्थन करने के लिए कितने प्रयास की आवश्यकता होगी, क्या हम अपने मौजूदा व्यवहार का समर्थन करने के लिए नए इम्प्लांट में अनुकूलन लागू करने में सक्षम होंगे, क्या हम नए अनुकूलन मॉडल और एपीआई का समर्थन करने में सक्षम होंगे, क्या हम समर्थन के लिए अपने सीरियलाइज़र को अनुकूलित करने में सक्षम हैं डिफ़ॉल्ट कॉन्फ़िगरेशन/वायर-प्रारूप नए एपीआई .NET कोर और .NET फ्रेमवर्क दोनों का समर्थन करने में सक्षम होंगे - जबकि यह स्पष्ट है कि ASP.NET Core 3 .NET फ्रेमवर्क को छोड़ देगा, यह स्पष्ट नहीं है कि नए API उपयोग करने जा रहे हैं या नहीं। NET कोर केवल प्रकार हैं जो हमें .NET कोर और .NET फ्रेमवर्क दोनों का समर्थन करने में सक्षम होने से रोकेंगे।

मैं आपको पहले ही बता सकता हूं कि जो हम शिप करेंगे वह JSON.NET द्वारा समर्थित सुविधाओं के सरगम ​​​​का समर्थन नहीं करेगा। तो यह पहले से ही सच नहीं है और वास्तव में, हम उम्मीद करते हैं कि यह कुछ मामलों में कम सक्षम होगा (प्रदर्शन और दायरे के कारणों के कारण)।

मैं केवल यह उम्मीद कर रहा हूं कि यह JSON.NET सुविधाओं के सबसेट का समर्थन करेगा, उदाहरण के लिए JSON.NET डिफ़ॉल्ट वायर-प्रारूप का समर्थन करेगा? (मैं हाँ मान रहा हूँ)। क्या नया इम्प्लांट जहां संभव हो वहां JSON.NET क्रमांकन प्रारूपों को अपनाएगा (हां मानते हुए भी)।

इसे निर्बाध रूप से समर्थन करने के लिए कितने प्रयास की आवश्यकता होगी, क्या हम अपने मौजूदा व्यवहार का समर्थन करने के लिए नए निहितार्थ में अनुकूलन लागू करने में सक्षम होंगे, क्या हम नए अनुकूलन मॉडल और एपीआई का समर्थन करने में सक्षम होंगे, क्या हम समर्थन के लिए अपने धारावाहिक को अनुकूलित करने में सक्षम हैं। डिफ़ॉल्ट कॉन्फ़िगरेशन/वायर-प्रारूप नए एपीआई .NET कोर और .NET फ्रेमवर्क दोनों का समर्थन करने में सक्षम होंगे।

@mythz मैं इनमें से कुछ का पालन नहीं कर रहा हूं। मैं यह पता लगाने की कोशिश कर रहा हूं कि यह मौजूदा एपीआई पर चर्चा कर रहा है कि उनका उपभोग कैसे किया जा रहा है। शायद हम कुछ ठोस परिदृश्य देख सकें?

@mythz कुछ हद तक एकमात्र वास्तविक चिंता है जो मैं देखता हूं , यदि यह नया एपीआई .net फ्रेमवर्क क्लासिक पर समर्थित नहीं है, तो इस तरह

इसके अलावा यह अपने प्रारंभिक चरण में एक प्रस्ताव है और जिस लक्ष्य को प्राप्त करना चाहता है वह काफी आशाजनक लग रहा है। किसी भी ओएस परियोजना के लिए रचनात्मक आलोचना हमेशा अच्छी होती है।

Microsoft द्वारा डिफ़ॉल्ट समाधान होने से उपयोगकर्ताओं के लिए @mythz लाभ वैकल्पिक समाधान के लेखकों के लिए लाभों के समान नहीं है।

पारिस्थितिकी तंत्र द्वारा मैं आसपास के .NET पुस्तकालय पारिस्थितिकी तंत्र/समुदायों का जिक्र कर रहा हूं (जो संभवतः ओपी में "पारिस्थितिकी तंत्र" का भी जिक्र कर रहा है) कि यह प्रतिस्थापित करता है जिसे मैं भी तर्क दूंगा। नेट उपयोगकर्ता भी स्वस्थ पारिस्थितिक तंत्र से लाभान्वित होते हैं विभिन्न प्रकार के विकल्प और अधिक प्रतिस्पर्धा (जैसा कि पायथन, जावा, नोड, रूबी, पीएचपी, आदि जैसे स्वस्थ पारिस्थितिक तंत्र की विशेषता है)।

EF .NET की दुनिया में सबसे अच्छा ORM है

ईएफ जारी होने के तुरंत बाद, यह जल्दी से अधिकांश ओआरएम मार्केटशेयर ले लिया, जबकि 2012 इन्फोक्यू साक्षात्कार से अंश:

एंटिटी फ्रेमवर्क में ओआरएम डेटा एक्सेस लेयर पर उनके नवीनतम प्रयास ने पहले के प्रमुख ओआरएम एनएचबेर्नेट के एक बार संपन्न समुदाय को भी नकारात्मक रूप से प्रभावित किया है। हर दूसरे ओपन सोर्स .NET ORM की तुलना में कई गुना धीमी होने के बावजूद, EF संयुक्त रूप से अन्य सभी

ध्यान रखें कि यह पूर्व .NET कोर था जहां प्रदर्शन अब सर्वोच्च प्राथमिकता है, लेकिन यह हानिकारक प्रभाव का एक ऐतिहासिक उदाहरण है एमएस डिफ़ॉल्ट मौजूदा पारिस्थितिक तंत्र/समुदायों पर है। आईएमओ यह काफी हद तक स्वीकार किया जाता है कि मौजूदा समुदायों के साथ क्या होता है जब एमएस डिफ़ॉल्ट पेश करता है, यही कारण है कि शिपिंग डिफ़ॉल्ट से वापस लौटने के लिए हाल ही में धक्का दिया गया है जो पहचान सर्वर और ऑटोमैपर के साथ प्रतिस्पर्धा करता है।

और MSTest उस दिन NUnit से बेहतर था।

आईएमओ यह कभी नहीं था (और एनयूनीट का आर # समर्थन हमेशा उत्कृष्ट एएफएआईसीआर रहा है) और तथ्य यह है कि हम इसे मोनो पर क्रॉस-प्लेटफ़ॉर्म नहीं चला सकते हैं, जो मोनो पर क्रॉस-प्लेटफ़ॉर्म का समर्थन करते हैं (नेट कोर से पहले) उपयोग नहीं कर सके यह।

लेकिन आइए बाढ़ न करें और विषय पर टिके रहें। चीयर्स!

मैं इस पर भी इस धागे को हाईजैक नहीं करना चाहता, लेकिन यह बताने की जरूरत है कि मैं आपकी बातों से असहमत क्यों हूं।

इसके संबंध में, JSON.NET की तुलना में एक अलग धारावाहिक का उपयोग करने का प्राथमिक कारण प्रदर्शन है और इस नए डिफ़ॉल्ट धारावाहिक का कारण प्रदर्शन है। चूंकि अधिकांश लोग केवल डिफ़ॉल्ट का उपयोग करते हैं, मैं उम्मीद कर रहा हूं कि JSON.NET शेयर पर इसका सबसे अधिक ध्यान देने योग्य प्रभाव होगा, जबकि वैकल्पिक सीरियलाइज़र का उपयोग करने का प्राथमिक कारण अब इस तेज़ इम्प्लांट के साथ मौजूद नहीं होना चाहिए। इसलिए मूल रूप से मैं इसे मौजूदा (पुस्तकालय) पारिस्थितिकी तंत्र पर हानिकारक प्रभाव भी देखता हूं। IMO JSON libs का एक कमजोर पारिस्थितिकी तंत्र .NET के लिए एक शुद्ध नकारात्मक है (ऐसा कुछ नहीं जो अधिकांश उपभोक्ता देखेंगे कि वे केवल डिफ़ॉल्ट का उपयोग करेंगे और अन्य विकल्पों के बारे में भूल जाएंगे), लेकिन यह मेरी मुख्य चिंता नहीं है।

@davidfowl @shahid-pk

इसके बावजूद मैं वास्तव में पसंद करता कि यह 8 साल पहले सर्विसस्टैक विकसित करने के प्राथमिक कारण के रूप में अस्तित्व में था। टेक्स्ट था क्योंकि .NET Framework JSON धारावाहिक बेहद धीमे थे। लेकिन सभी इस समय के बाद SS.Text सभी भर में सुविधाओं हमारे पुस्तकालयों, समर्थन करने के लिए जैसे अनुकूलन की संख्या के साथ बढ़ा दिया गया है विभिन्न भाषाओं ServiceStack समर्थन , विभिन्न ServiceStack में JSON अनुकूलन विकल्प , में JSON समर्थन ServiceStack टेम्पलेट्स , में परिसर प्रकार JSON ब्लॉब समर्थन ServiceStack रेडिस आदि

तो अब मैं इस बात का आकलन करने पर ध्यान केंद्रित कर रहा हूं कि प्रभाव क्या होगा, नया एपीआई और प्लगेबिलिटी विकल्प कैसा दिखेगा, क्या हम मौजूदा सुविधाओं को उस पर वापस ला सकते हैं, क्या हम एसएस में जेएसओएन सीरिएलाइज़र के रूप में अपनाने में सक्षम होंगे। नेट कोर ऐप्स (यह क्या तोड़ देगा), क्या सर्विसस्टैक। टेक्स्ट नए एपीआई का समर्थन करने में सक्षम होगा, क्या हम .NET v4.5 का समर्थन करने में सक्षम होंगे, क्या यह मौजूदा तैनाती के वायर-प्रारूपों का समर्थन करने के लिए इसे अनुकूलित करने में सक्षम होगा, आदि। I मूल रूप से इस पर किसी भी प्रभाव या आगे की रणनीति के बारे में कोई जानकारी नहीं है क्योंकि मुझे अभी तक कुछ भी उपयोग करने या देखने का मौका नहीं मिला है। जब मुझे इसका उपयोग करने का मौका मिलेगा तो मुझे और उत्तर पता चलेंगे और मैं स्पष्ट रूप से एकीकरण का परीक्षण करने और प्रतिक्रिया प्रदान करने और एपीआई के जमने से पहले परिवर्तनों का प्रस्ताव देने का अवसर प्राप्त करना चाहूंगा।

@mythz

- वहाँ एक कारण है कि 2 सबसे लोकप्रिय JSON पुस्तकालय के बाद JSON.NET है ServiceStack.Text जो पहले से ही है स्पैन एपीआई पर निर्मित होने की पुनर्संशोधित दिया बाहर रखा गया है?

चूक जानबूझकर नहीं थी। हमने CoreFxLab रेपो के हिस्से के रूप में JSON लाइब्रेरी लेखकों के साथ सक्रिय रूप से खोज और काम किया है और हमारे एक NuGet पर "json" जैसे बुनियादी खोज शब्दों का उपयोग करके

मैं उत्सुक हूं कि आप किस "पारिस्थितिकी तंत्र" का जिक्र कर रहे हैं और यहां "एक साथ काम" करने की उम्मीद कर रहे हैं?

.NET पारिस्थितिकी तंत्र और विशेष रूप से JSON प्रसंस्करण में रुचि रखने वाले पक्ष।

मुझे स्पष्ट रूप से इस बात में दिलचस्पी होगी कि ये "प्लग करने योग्य" एपीआई कितने संगत हैं या क्या यह एक और क्षेत्र है जहां नए एमएस पुस्तकालयों को अपनाने और एकीकरण समाप्त होने वाले पारिस्थितिक तंत्र को मारने के लिए समाप्त होता है।

नियोजित ASP.NET कोर एक्सटेंशन पॉइंट्स का उद्देश्य ग्राहकों को जो भी JSON लाइब्रेरी चाहिए, उसके साथ बिल्ट-इन JSON घटक को बदलने में सक्षम बनाना है। बेशक, ASP.NET ने हमेशा "बैटरी शामिल", यानी एक उचित डिफ़ॉल्ट अनुभव के साथ भेज दिया है। अतीत में यह Json.NET रहा है और आगे बढ़ते हुए यह एक मंच प्रदान किया गया घटक है। यह देखते हुए कि Json.NET ASP.NET में कुछ हद तक कठोर था, नई योजना आपके जैसे लोगों के लिए नेट-वार बेहतर लगती है; इसलिए मुझे पूरा यकीन नहीं है कि हमारी योजना का कौन सा हिस्सा आपको लगता है कि खतरा है।

एक खुला प्रश्न है कि 3.0 में ASP.NET के लिए कौन से टेम्प्लेट उपयोग करेंगे।

क्या टेम्प्लेट के मॉड्यूलर होने का समय नहीं है? उदाहरण के लिए vue.js लें।

एक नया Vue ऐप बनाने से आप अपनी मनचाही चीज़ें चुन सकते हैं। सभी परिदृश्यों को पूरा करने के लिए 500 टेम्पलेट्स बनाने के बजाय एएसपीनेट के लिए कुछ ऐसा क्यों नहीं किया जा सकता है।

यहाँ .ASP NET Core 2.2 में एक सुविधा के लिए एक ठोस उदाहरण दिया गया है जहाँ गैर-JSON.NET JSON इनपुट/आउटपुट फॉर्मेटर्स को समस्याओं का सामना करना पड़ेगा और एक डिकॉउल्ड समाधान कैसे मदद कर सकता है:
समस्या विवरण सुविधा, जो RFC 7807 संगत त्रुटि प्रतिक्रिया की अनुमति देती है:
https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ProblemDetails.cs

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

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

उपरोक्त कोड JSON.NET विशिष्ट विशेषताओं के साथ एनोटेट किया गया है, जिसमें एक विशिष्ट फ़ॉलबैक विशेषता [JsonExtensionData] , सभी अज्ञात JSON गुण इस शब्दकोश में deserialized हैं और इस शब्दकोश की सामग्री को सामान्य JSON संरचना में क्रमबद्ध किया गया है।

किसी भी वैकल्पिक JSON इनपुट/आउटपुट फ़ॉर्मेटर को अब इन JSON.NET विशिष्ट विशेषताओं को संभालने की आवश्यकता है ताकि इस प्रकार को ठीक से क्रमबद्ध/deserialize करने में सक्षम हो या एक अलग तरीका ढूंढ सकें, यानी इन प्रकारों के लिए JSON.NET पर फॉलबैक।

अब, यदि हमारे पास सुविधाओं का एक अच्छी तरह से परिभाषित विनिर्देश है, तो JSON के लिए एक इनपुट/आउटपुटफॉर्मेटर को 3.0 के लिए समर्थन की आवश्यकता है, उपरोक्त समस्या मौजूद नहीं है क्योंकि ये विशेषताएँ Microsoft.Extension... पैकेज और प्रत्येक कस्टम JSON फ़ॉर्मेटर में रह सकती हैं। संगत होने के लिए इस कार्यक्षमता को लागू करने के लिए उनका उपयोग कर सकता है।

मेरी जानकारी के अनुसार, ASP.NET कोर में "आधिकारिक" स्रोत कोड के केवल कुछ उदाहरण हैं जो JSON.NET विशेषताओं द्वारा एनोटेट किए गए हैं, लेकिन मैंने JSON.NET विशिष्ट विशेषताओं (आमतौर पर निर्दिष्ट करने के लिए) का उपयोग करते हुए तीसरे पक्ष के पुस्तकालयों को भी देखा है। विशेषता नाम [JsonProperty("name")]

FWIW, यही https://github.com/Tornhoof/SpanJson/issues/63 के बारे में है।

@terrajobst मुझे लगता है कि आपने मेरी पिछली टिप्पणी पढ़ने से पहले उत्तर दिया था जो आईएमओ मेरी चिंताओं को और स्पष्ट करता है।

हम सक्रिय रूप से अतिरिक्त प्रतिक्रिया की तलाश कर रहे हैं।

कहा पे? क्या कोई एपीआई प्रस्ताव/दस्तावेज है, क्या एक एपीआई बनाया गया है, इसे किस रेपो के तहत विकसित किया जा रहा है?

मुझे लगता है कि आपने मेरी पिछली टिप्पणी पढ़ने से पहले उत्तर दिया था जो आईएमओ मेरी चिंताओं को और स्पष्ट करता है।

मैंने इसे पढ़ लिया है लेकिन ऐसा लगता है कि आप किसी भी डिफ़ॉल्ट होने का विरोध कर रहे हैं, जैसा कि @davidfowl ने समझाया, हमारे लिए व्यावहारिक नहीं है। मेरा कहना था कि हमारी योजना वर्तमान में हमारे पास जो है, उसमें सुधार है, यानी Json.NET के लिए एक वास्तविक हार्ड-वायरिंग। इसलिए मेरा प्रश्न।

कहा पे? क्या कोई एपीआई प्रस्ताव/दस्तावेज है, क्या एक एपीआई बनाया गया है, इसे किस रेपो के तहत विकसित किया जा रहा है?

हमने जानबूझ कर .NET कोर में अभी तक कोई कोडिंग/एपीआई डिज़ाइन नहीं किया है क्योंकि हम पहले यह घोषणा करना चाहते थे। हम नहीं चाहते थे कि लोग इस घोषणा द्वारा प्रदान किए गए संदर्भ को प्रदान किए बिना चाय की पत्तियों को पढ़ें। दूसरे शब्दों में, देखते रहें, हम जल्द ही एपीआई और कोड प्रकाशित करेंगे।

@terrajobst उस पोस्ट के लिए संपूर्ण प्रभाव

1. परिवर्तन करने का निर्णय लिया जाता है।

आगे बढ़ते हुए, हम अपने JSON समर्थन में कुछ बदलाव करने की योजना बना रहे हैं:

1. कुछ प्रारंभिक डिजाइन किया जाता है
   हमें उच्च-प्रदर्शन वाले JSON API की आवश्यकता है।
   ASP.NET कोर से Json.NET पर निर्भरता निकालें।
   Json.NET के लिए ASP.NET कोर एकीकरण पैकेज प्रदान करें।

यह सब का मतलब है कि दिशा ली जाती है। "पारिस्थितिकी तंत्र" से जो कुछ भी पूछा जाता है, वह स्पष्ट दर्द बिंदुओं को खोजने के लिए होता है, जिनका एमएस वास्तविक रूप से हिसाब नहीं कर सकता था।

सर्विसस्टैक को छोड़ देना और इसे कुछ सेकेंडरी-क्लास .NET लाइब्रेरी के रूप में चर्चा करना हास्यास्पद है। यहां तक ​​कि मैं पूरी तरह से एमएस शिप किए गए पुस्तकालयों पर हूं, इसका मतलब यह नहीं है कि मुझे विकल्पों के बारे में पता नहीं है।

मुझे एमएस के निर्णय लेने में कोई समस्या नहीं है, लेकिन अगर यह सीधे कहा गया था, और पहले से लिए गए निर्णयों पर "सामुदायिक प्रतिक्रिया" के साथ कवर नहीं किया गया था।

यही मेरी धारणा है

@terrajobst

मैंने इसे पढ़ लिया है, लेकिन ऐसा लगता है कि आप कोई डिफ़ॉल्ट होने का विरोध कर रहे हैं

कभी सुझाव नहीं दिया कि, JSON.NET इससे पहले ही डिफ़ॉल्ट था। मैंने ऊपर और अधिक विस्तार से समझाया है, लेकिन इसे दोहराने के लिए डिफ़ॉल्ट को संभालने और नया डिफैक्टो मानक बनने के लिए तैनात किया गया है जहां प्रभावी रूप से .NET कोर के भविष्य में केवल 2 JSON धारावाहिक होंगे: यह नया डिफैक्टो उच्च-प्रदर्शन डिफ़ॉल्ट और JSON। कस्टम सुविधाओं के लिए नेट। अन्य JSON serializers आला बनने जा रहे हैं, उदाहरण के लिए विभिन्न परिदृश्यों का समर्थन करने के लिए अनूठी विशेषताओं को जोड़ा गया है।

हमने जानबूझकर कोई कोडिंग/एपीआई डिज़ाइन .NET कोर नहीं किया है क्योंकि हम पहले यह घोषणा प्राप्त करना चाहते थे।

ठीक है तो किसी भी "बाहरी" के लिए यह जानना संभव नहीं है कि प्लगेबिलिटी, एक्स्टेंसिबिलिटी या इंटरऑपरेबिलिटी कितनी अच्छी है
अभी तक होगा।

हम नहीं चाहते थे कि लोग इस घोषणा द्वारा प्रदान किए गए संदर्भ को प्रदान किए बिना चाय की पत्तियों को पढ़ें। दूसरे शब्दों में, देखते रहें, हम जल्द ही एपीआई और कोड प्रकाशित करेंगे।

तो इसे तब आंतरिक रूप से विकसित किया गया था? आपके द्वारा इसे जारी करने के कितने समय बाद बाहरी लोगों को एपीआई डिज़ाइन में परिवर्तनों का परीक्षण और प्रस्ताव देना होगा? "प्लग करने योग्य" और "एक्स्टेंसिबल" एपीआई कैसा दिखेगा, इस बारे में मेरी प्राथमिक चिंता, क्या हम "अधिग्रहण" करने में सक्षम होंगे और रेफरी/वैल्यू प्रकारों के वायर प्रारूप के लिए पूर्ण नियंत्रण रखेंगे? बिल्ट-इन टाइप्स, एनम्स, बूल, अन्य इंट्रिनिक्स आदि के बारे में क्या? उदाहरण के तौर पर यह "हां", "चालू", "1" जैसे अन्य लोकप्रिय JSON मानों को स्वीकार करने के लिए bool को कॉन्फ़िगर करने में सक्षम होगा।

अन्य सवाल:

• क्या इस कार्यान्वयन को स्टैंड-अलोन (एक अलग NuGet पैकेज में) इस्तेमाल किया जा सकता है?
• क्या एपीआई का "प्लग करने योग्य" हिस्सा वेब फ्रेमवर्क से जुड़ा है या इसे कहीं और इस्तेमाल किया जा सकता है (जैसे Xamarin/UWP)
• क्या यह .NET मानक 2.0 या .NET v4.5 का समर्थन करेगा?
• यदि नहीं, तो क्या एपीआई .NET मानक 2.0 या .NET v4.5 का समर्थन करने में सक्षम होंगे?

@mythz
यह वास्तव में आंतरिक रूप से विकसित नहीं हुआ है (मेरी जानकारी के अनुसार), पाठक/लेखक भाग corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/) में किया जाता है। Json) और विशेष रूप से इसके लिए अभी तक corefxlab में कोई उच्च-स्तरीय API नहीं है।

व्यक्तिगत रूप से, मैं एक्स्टेंसिबल/प्लग करने योग्य एपीआई भागों को छोड़कर .NET मानक (यानी विशेषताएँ आदि) होना चाहता हूँ। इस समय corefxlab में पुस्तकालय .NET मानक 1.1 है, लेकिन मुझे लगता है कि यह पुस्तकालय आदि के प्रदर्शन लक्ष्यों के आधार पर बदल जाएगा।

@mythz

आप मेरे बयानों को लेने के लिए उत्सुक प्रतीत होते हैं और उन्हें "ग्लास आधा खाली है"-संदर्भ में डाल देते हैं। मैं समझ गया, आपको संदेह है। मेरा सुझाव है कि हम अपने आप को कीस्ट्रोक्स का एक गुच्छा बचाएं और सार में चर्चा करने के विरोध में ठोस एपीआई प्रस्तावों पर चर्चा करें। मुझे पूरा विश्वास है कि हमारी योजना आपको आवश्यक विस्तार बिंदु प्रदान करेगी।

@terrajobst संदेहास्पद होने की कोशिश नहीं कर रहा है, यह जानने की कोशिश कर रहा है कि उच्च स्तरीय प्रस्तावित क्षमताएं क्या हैं जो मैं मान रहा हूं कि पहले ही तय किया जा चुका है (या वे सभी अभी भी टीबीडी हैं?) यह घोषणा हममें से अधिकांश ने पहली बार इसके बारे में सुना है, इसलिए मैं इस बारे में कुछ स्पष्टीकरण के बाद था कि यह कैसे प्लग करने योग्य, एक्स्टेंसिबल और पुन: प्रयोज्य होने का इरादा है। क्या System.Text.JsonLab वर्तमान प्रभाव है? क्या इसका मतलब यह है कि यह .NET मानक 2.0 और .NET v4.5 का भी समर्थन करेगा?

पुस्तकालय निर्माताओं के लिए यह एक अच्छी सुविधा हो सकती है, लेकिन आपको निर्भरता वाले पेड़ों के साथ 50 पुस्तकालयों का उपयोग करने वाले उद्यम डेवलपर्स पर भी विचार करना होगा और उनके बीच संगतता खोजने की कोशिश करनी होगी। क्या बेमेल को प्रबंधित करने का प्रयास करने के लिए बाध्यकारी-रीडायरेक्ट-शैली मैपिंग-कॉन्फ़िगरेशन होगा?

यह बातचीत किनारे पर लगती है, चाहे लोगों को किसी तरह से नाराज किया गया हो या क्योंकि वे उस कार्रवाई का बचाव करने की कोशिश कर रहे थे जो की गई थी या नहीं की गई थी। पढ़ना मुश्किल है। चारों ओर क्षमा करें! कृपया वर्तमान स्थिति को रहने दें और आगे बढ़ें।

ऐसा लगता है कि इस बदलाव के दो कारण हैं। सबसे पहले .Net Core के भीतर नए प्रकारों का उपयोग करके बेहतर प्रदर्शन की इच्छा है।

इसके अतिरिक्त, यह माना गया था कि कुछ समय पहले एक वास्तुशिल्प त्रुटि हुई थी जिसमें JSON.Net के कठिन संदर्भ शामिल थे, एक पुस्तकालय जो बाहरी रूप से .Net पर रहता है। इसे ठीक करने के लिए, एक नए, अंतर्निहित JSON कार्यान्वयन की शुरूआत उन इंटरफेस के साथ की जानी चाहिए जो तीसरे पक्ष को अपने स्वयं के कार्यान्वयन का उपयोग करने की अनुमति देते हैं।

क्या इससे चीजें टूट जाएंगी? हां! इसलिए घोषणा पर "ब्रेकिंग चेंजेस" लेबल है। (हो सकता है कि उस लेबल को यहां दोहराया जाना चाहिए।) और चूंकि यह एक महत्वपूर्ण बदलाव के रूप में जाना जाता है, इसलिए प्रभाव का पता लगाने के लिए एक चर्चा शुरू की गई थी। इसके अतिरिक्त, प्रभाव को कम करने के लिए, एक अतिरिक्त पुस्तकालय जो लोगों को JSON.Net का उपयोग जारी रखने की अनुमति देता है, की आपूर्ति की जाएगी।

एक पुस्तकालय लेखक के रूप में मुझे वास्तव में इसमें दिलचस्पी है, और मैं चाहूंगा कि बातचीत आगे बढ़े।

@Tornhoof आपके उदाहरणों के जवाब में, अगर मैं JSON.Net का उपयोग जारी रखना चाहता हूं, तो मुझे पहले उल्लेख की गई संगतता लाइब्रेरी का भी संदर्भ देना होगा। यह ज्यादातर प्लग-एंड-प्ले होना चाहिए , लेकिन इसमें बदलाव हो सकते हैं। मैं निश्चित रूप से नहीं चाहता कि ढांचा (.नेट कोर) यह निर्देशित करे कि मेरे द्वारा चुने गए धारावाहिक को क्रमबद्धता के लिए इन विशेषताओं का उपयोग करना चाहिए, खासकर जब मेरा धारावाहिक समान अवधारणाओं के लिए एक अलग तंत्र का उपयोग करता है।

नेट द्वारा प्रदान किया गया समाधान उससे अधिक सामान्य होना चाहिए। विशिष्ट मॉडल क्रमांकन सौंपने को चुने गए JSON कार्यान्वयन द्वारा किया जाना चाहिए।

@mythz इस प्रस्ताव को बनाने में शामिल लोगों से जो कुछ भी मैं जानता हूं और देखा है, उससे आपको प्रस्तावित एपीआई और कार्यान्वयन पर समीक्षा और टिप्पणी करने से पहले इसे स्थिर रूप से जारी करने का एक लंबा मौका मिलेगा। इस पोस्ट को इतनी प्रारंभिक अवस्था में बनाने का एक उद्देश्य विशेष रूप से इस कारण से आप जैसे लोगों को खोजना था।

@gregsdennis
मुझे यकीन नहीं है कि अधिक सामान्य के साथ आपका क्या मतलब है?
मान लें कि आपके सीरिएलाइज़र में जेसन संपत्ति के नामों को ओवरराइड करने, उनके शून्य व्यवहार और/या फ़ॉलबैक/कैच-सभी कार्यान्वयन को बदलने और यह मानते हुए कि सभी तीन सुविधाएं जेएसओएन सीरिएलाइज़र के लिए .net कोर 3.0 के लिए साझा विनिर्देश का हिस्सा हैं, फिर कार्यान्वयन पैकेज उन विशेषताओं को आपके आंतरिक कार्यान्वयन विवरण में मैप करता है।
उदाहरण के लिए, यदि आपकी लाइब्रेरी आपको पसंद करती है तो गुणों का नाम निर्दिष्ट करने के लिए [DataMember] का उपयोग करें (जैसे SpanJson करता है) आपके एकीकरण पैकेज को इसे आसानी से मैप करना चाहिए।
मैं यह नहीं कह रहा हूं कि विशेषताएँ सही तरीका हैं, यह सिर्फ कोड उदाहरण का एक दृश्य भाग होता है।

जाहिर है, आदर्श दुनिया यह होगी कि कोई भी ASP.NET कोर फ्रेमवर्क लाइब्रेरी क्रमांकन व्यवहार को नियंत्रित करने के लिए किसी विशिष्ट एनोटेशन का उपयोग नहीं करेगी, लेकिन जैसा कि ऊपर की सुविधा के लिए, यह असंभव से काफी जटिल है, क्योंकि RFC को कुछ नामकरण नियमों का पालन करने की आवश्यकता होती है। .

किसी भी तरह, मुझे लगता है कि इन साझा सुविधाओं, भविष्य में उनका उपयोग और वर्णन करने के तरीके पर कई चर्चाएं होंगी।

नए JSON पार्सर में SIMD निर्देशों का उपयोग करने की कोई योजना है, जैसे कि RapidJSON में?

संदर्भ: http://rapidjson.org/

प्रस्तावित सुझाव अच्छा लग रहा है, लेकिन कृपया " ब्रेकिंग चेंजेस" की कोशिश करें और सुचारू करें, मैं सिर्फ 3 पार्टी के कामों का एक सामान्य उपयोगकर्ता हूं और हाल ही में इनमें से एक अनुभव था जहां प्रतिबिंब को अचानक यूडब्ल्यूपी से बाहर रखा गया था। नेट देशी रिलीज बिल्ड प्रक्रिया (कंपाइलर) )

इसलिए मेरा कोई भी UWP ऐप महीनों तक रिलीज़ मोड में नहीं बनाया जा सका क्योंकि मुझे उन सभी कोड को फिर से लिखना पड़ा जो 3rd पार्टी libs में प्रतिबिंब का उपयोग करते थे। मुझे पता है कि उन यूडब्ल्यूपी भागों में प्रतिबिंब को बाहर करने के लिए कई पुस्तकालय लेखकों को अपने कार्यान्वयन को फिर से विभाजित करना पड़ा। अधिकांश पुस्तकालय लेखक पार्टी में नहीं आए और मुझे जहाज पर कूदने के लिए मजबूर किया गया। हालांकि एमएस सामने आया और .net मानक 2.1 में एक विकल्प को लागू करने के लिए प्रतिबद्ध है। हम जानते हैं कि जमीनी स्तर पर वास्तविकता .net मानक 2.1 है जिसे शुरुआती ब्रेकिंग परिवर्तन से वितरित होने में महीनों लगेंगे।

बिंदु सरल है, यह मेरे लिए एक बेहद विघटनकारी प्रक्रिया थी जिसका अंतिम उपयोगकर्ताओं के लिए बड़े पैमाने पर परिणाम थे और यह "चिकनी" और घर्षण रहित कुछ भी था।

निश्चित तौर पर यह सही कदम है।
मैं थोड़ी देर के लिए इस Json.Net संदर्भ को देखकर सोच रहा हूं।

@Tornhoof मुझे लगता है कि एक परिभाषित अलगाव की आवश्यकता है: इंटरफेस जो प्रत्येक प्रदाता को नेट कोर 3.0 के साथ उपयोग करने के लिए लागू करने की आवश्यकता होगी, और डिफ़ॉल्ट कार्यान्वयन जो इसमें बनाया गया है।

इंटरफेस जितना संभव हो उतना सामान्य उपयोग होना चाहिए। शायद केवल Serialize() और Deserialize() विधियों को परिभाषित करने जितना सरल।

अन्य विवरण कार्यान्वयन पर छोड़ दिए जाने चाहिए। यदि डिफ़ॉल्ट कार्यान्वयन ने कस्टम प्रॉपर्टी कुंजीयन तंत्र को परिभाषित करने के लिए एक विशेषता का उपयोग किया है, तो मैं इसके साथ ठीक हूं। मुझे लगता है कि यह एक कार्यान्वयन-विशिष्ट विवरण है जो इंटरफ़ेस का हिस्सा नहीं होना चाहिए।

उस ने कहा, कस्टम-कुंजी गुणों की क्षमता होने की आवश्यकता हो सकती है, हालांकि मुझे यकीन नहीं है कि इसे कैसे संहिताबद्ध किया जा सकता है।

@gregsdennis हाँ आप सही कह रहे हैं, मैं मुख्य रूप से IInput/OutputFormatter को देख रहा था, जो पहले से ही ASP.NET कोर में मौजूद है और विशेष रूप से गैर-JSON.NET संस्करणों के साथ उन्हें बदलने के संबंध में समस्याएं।
वैसे भी जैसा कि आपकी और @mythz टिप्पणियां दिखाती हैं, मुझे लगता है कि स्कोप परिभाषा दिलचस्प हो जाएगी और शायद यह आसान नहीं है (मुझे डीआई इंटरफ़ेस चश्मा के साथ समस्याएं याद हैं)। इसलिए बेहतर है कि इस प्रक्रिया में कई अलग-अलग दृष्टिकोणों को जल्दी शामिल किया जाए।

@ टोर्नहोफ सहमत हुए। वर्तमान फ़ॉर्मेटर इंटरफेस साफ़ JSON.Net आधारित है, लेकिन इतना नहीं serializer पर ही नहीं, बल्कि विकल्पों वस्तु पर कर रहे हैं। ऐसा लगता है कि हमें विकल्पों को संप्रेषित करने के लिए एक सामान्य तरीके की भी आवश्यकता होगी (एक सामान्य विकल्प वस्तु)।

क्या इसका मतलब यह है कि विकल्प ऑब्जेक्ट कार्यान्वयन के लिए न्यूनतम सुविधा निर्धारित करता है? मुझे नहीं लगता कि यह करता है। मैंने हाल ही में अपने धारावाहिक के लिए एक फॉर्मेटर लागू किया है जो विकल्प ऑब्जेक्ट को पूरी तरह से अनदेखा करता है, लेकिन यह मेरे निजी उपयोग के लिए था। अगर मैं सार्वजनिक उपयोग के लिए एक बनाना चाहता हूं, तो मैं उन विकल्पों में से अधिक से अधिक व्याख्या करने की कोशिश करूंगा ताकि उनका समर्थन किया जा सके।

ऐसा नहीं है कि अब हम चीजें कैसे कर रहे हैं। विकल्प धारावाहिक विशिष्ट हैं और उनके लिए कोई सामान्य इंटरफ़ेस नहीं है। एमवीसी में फॉर्मेटर्स पहले से ही सही तरीके से तैयार किए गए हैं और किसी भी चीज़ के साथ नहीं हैं। JsonResult में ब्रेकिंग परिवर्तन होंगे क्योंकि यह सीधे JsonSerializationOptions (JSON.NET प्रकार) लेता है।

में भी यही बात कहने वाला था। हम JSON रीडर/लेखक/धारावाहिक के लिए एक अमूर्त बनाने की योजना नहीं बनाते हैं। इसकी आवश्यकता नहीं है; फ्रेमवर्क या तो आईओ प्राइमेटिव्स (जैसे Stream , TextReader ) में डील करते हैं या उच्च-स्तरीय फ्रेमवर्क प्रोसेसिंग (जैसे ASP.NET कोर फॉर्मेटर्स) में प्लग इन करते हैं।

दर्द बिंदुओं की बात करना: व्यक्तिगत रूप से (और मैं बहुत कम अल्पसंख्यक में होने की संभावना है) मैं कई JSON पार्सर्स की ढीली प्रकृति के बारे में चिंतित हूं। एक मानक (tm) है, लेकिन अधिकांश पार्सर्स ने उदार होना चुना और गैर-अनुरूपता वाले दस्तावेज़ों को स्वीकार किया। इसके बारे में लंबे समय में क्या बुरा है कि डेवलपर्स एक मानक के लिए लागू नहीं करते हैं जो वे एक पुस्तकालय के लिए लागू करते हैं। यदि पुस्तकालय गैर-अनुरूपता वाले दस्तावेज़ की अनुमति देता है तो डेवलपर्स तब तक खुश रहते हैं जब तक कि सभी बिट एक ही पुस्तकालय का उपयोग करते हैं। विभिन्न पुस्तकालयों का उपयोग करने वाले डोमेन के बीच संवाद करने का प्रयास करते समय दर्द उत्पन्न होता है। अचानक एक समस्या है क्योंकि विभिन्न पुस्तकालय JSON के विभिन्न स्वादों का समर्थन करते हैं।

क्या हमें JSON लाइब्रेरी को यथासंभव उदार बनाकर दर्द बिंदुओं को दूर करना चाहिए (लेकिन शायद जटिलता और अस्पष्टता के साथ समाप्त होता है) या मूल कारण पर हमला करना चाहिए; गैर-पुष्टि JSON पुस्तकालय।

चूंकि प्रभावशाली एमएस शायद लंबे समय में इंटरऑपरेबिलिटी में सुधार के लिए जेएसओएन पार्सर्स को सफलतापूर्वक चैंपियन बनाने के लिए एमएस के लिए पूछने के लिए बहुत कुछ है, लेकिन मेरी इच्छा है कि यह अलग हो। शायद पढ़ने में उदार हों लेकिन लिखने में सख्त हों?

(चीजें मानक में नहीं हैं; टिप्पणियाँ, अनुगामी अल्पविराम, एकल उद्धरण तार, कोई उद्धरण तार आदि नहीं)

IMHO, चूंकि JSON वेबब्रोसर की दुनिया से उपजा है, ऐसा लगता है कि इंटरऑपरेबिलिटी के लिए हमें JSON में संख्याओं के लिए अंतर्निहित प्रतिनिधित्व के रूप में डबल चुनना चाहिए, भले ही JSON मानक प्रतिनिधि के बारे में कुछ नहीं कहता है।

एपीआई के बारे में बोलते हुए, मुझे लगता है कि सबसे अधिक इस्तेमाल किया जाने वाला एपीआई एपीआई की तरह एक डोम होगा, लेकिन मुझे यह भी बहुत उपयोगी लगेगा यदि निचले स्तर का एपीआई था जो मुझे टोकन स्ट्रीम का उपभोग करने या विज़िटर इंटरफ़ेस पर सिग्नल प्राप्त करने की इजाजत देता था। वे बड़े दस्तावेज़ जिनसे मैं डेटा का एक छोटा सा हिस्सा निकालना चाहता हूँ।

@mrange - जितना मैं चीजों को यथासंभव सख्त बनाना पसंद करता हूं .... ऐसा करना गैर-अनुरूप कोड में परिवर्तन करने की क्षमता पर निर्भर करता है।

यदि आप किसी अन्य कंपनी के नियंत्रण में एक लीगेसी सेवा के साथ इंटरैक्ट कर रहे हैं, तो आपत्तिजनक कोड को बदलने की क्षमता शून्य के करीब है। यहां तक ​​​​कि सख्त-ऑन-राइट, जबकि अधिक करने योग्य, यहां अपनी समस्याओं के बिना नहीं है: क्या होगा यदि आपत्तिजनक कोड को एक गैर-अनुरूप वस्तु प्राप्त करने की उम्मीद है?

@terrajobst धन्यवाद! Func<Stream, CancellationToken, Task<T>> और Func<T, CancellationToken, Stream, Task> वह सब कुछ है जो यहां आवश्यक है। टेक्स्ट रीडर/राइटर, स्पैन और स्ट्रिंग के लिए शायद कुछ ओवरलोड के साथ।

हालांकि नकारात्मक पक्ष यह है कि जब आप किसी अन्य पुस्तकालय के प्रकार को क्रमबद्ध/deserialize करना चाहते हैं, और उस प्रकार को एक जेसन सीरिएलाइज़र से विशेषताओं से सजाया गया है जिसका आप उपयोग नहीं कर रहे हैं।

@thefringeninja यदि आप पहले से ही वस्तुओं के लिए तृतीय पक्ष लाइब्रेरी का उपयोग कर रहे हैं, तो आपके पास पहले से ही अन्य धारावाहिक का संदर्भ है। वहां कुछ भी नहीं बदला है।

मैं डर फैलाने वालों में से नहीं हूं, लेकिन मुझे लगता है कि

@terrajobst पारिस्थितिकी तंत्र के बारे में, हालांकि वहां हर पुस्तकालय के लिए खाते में असंभव है, मुझे नहीं लगता कि NuGet पर "जेसन" की त्वरित खोज किसी को भी बताने जा रही थी। शायद नाम ServiceStack.Text कहने का सबसे आम तरीका नहीं है "अरे! मैं एक पैकेज हूं जो JSON को क्रमबद्ध कर सकता है!", लेकिन इसकी तुलना करने वाले वर्षों में बेंचमार्क रहे हैं। शायद यह एमएस डिफॉल्ट्स को डॉगफूड करने का मामला है और या तो विकल्पों की चौड़ाई और लोकप्रियता को नहीं जानता है या उनसे परिचित होने के लिए आंतरिक रूप से पर्याप्त रूप से उनका उपयोग करता है।

मैं सहमत हूं कि ऐसा अनुभव प्रदान करने के लिए कुछ डिफ़ॉल्ट होना चाहिए जो _just काम करता है_ आउट-ऑफ-द-बॉक्स। यदि पारिस्थितिकी तंत्र में अन्य पुस्तकालय लेखक एक एकीकरण पैकेज प्रकाशित करते हैं, तो यह बहुत अच्छा होगा यदि वे डॉक्स में प्लग प्राप्त कर सकें, नोट जारी कर सकें, आदि पर जोर दिया जा सके कि चूक से परे विकल्प हैं। इसे खोजना कठिन बनाना पारिस्थितिकी तंत्र के लिए समस्याग्रस्त होगा।

मेरी आशा है कि यदि निर्भरता को दूर करने का लक्ष्य ईमानदार है, तो एपीआई को समुदाय की जरूरतों का सबसे अच्छा प्रतिनिधित्व करना चाहिए और सीधे Json.NET के बाद तैयार नहीं किया जाना चाहिए। लब्बोलुआब यह है कि इसे सभी लाइब्रेरी लेखकों से काम की आवश्यकता होगी, न केवल सर्विसस्टैक, बल्कि एपीआई को सीधे Json.NET के एपीआई के समान नहीं होना चाहिए, अन्यथा आप एक निर्भरता की तरह दिखते हैं लेकिन डीएलएल के बिना वापस आ जाते हैं।

एपीआई सीधे Json.NET के एपीआई के समान नहीं होने चाहिए

... या किसी अन्य विशिष्ट प्रदाता का कार्यान्वयन।

घोषणा से पहले हुई चर्चा के हिस्से में यह विचार शामिल था कि .Net टीम विभिन्न पुस्तकालयों से यह महसूस करने के लिए तैयार होगी कि विभिन्न समस्याओं को कैसे हल किया गया है, और फिर जो वे मानते हैं उसका उपयोग करने के लिए उन लोगों के लिए सबसे उपयुक्त होगा। विचारों को अपनों से मिला दिया। कई मायनों में, यह इससे भिन्न नहीं है कि कोई अन्य नई JSON लाइब्रेरी कैसे विकसित की जाएगी; ऐसा होता है कि इसे ढांचे के भीतर शामिल किया जाएगा।

हम एक उच्च-प्रदर्शन JSON लाइब्रेरी रखने में पूरी तरह से तैयार हैं, जिसे हमें स्वयं बनाने की आवश्यकता नहीं है। :)

कुछ भी चर्चा करने से पहले, उस क्षेत्र पर माइक्रोसॉफ्ट रिसर्च के परिणामों का लाभ उठाने पर विचार करें (अधिक विशेष रूप से, नो ब्रांचिंग नो एफएसएम पार्सिंग) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -डेटा विश्लेषण/

हम उच्च प्रदर्शन JSON पार्सिंग के लिए उस दिशा में जा रहे हैं --- Span<T> के अलावा ---
cc @terrajobst @karelz

:( JSON की यह सारी चर्चा मुझे महसूस कराती है कि टेम्प्लेट पर मेरा प्रश्न गलत हो गया है।

काश मेरे पास इस चर्चा के लिए और समय होता क्योंकि यह नर्क रहा है लेकिन मैं देखता हूं कि यह जो है वह क्यों बन गया है। 4.6.1 को अपग्रेड और अपग्रेड के अनुरूप रहना होगा और ब्रेकिंग परिवर्तन बाकी के लिए होगा।

मैंने कोर और 461 के लिए बहुत सारे रिकॉल किए गए पैकेज देखे हैं और मुझे उम्मीद है कि यह प्रकार या परिवर्तन इसे ठीक कर देगा।

मुझे चिंता है कि कैस्केडिंग मुद्दा हमें परेशान करेगा, कृपया हमें गलत साबित करें।

// डॉट नेट देव हर जगह

@c0shea

[...] यह बहुत अच्छा होगा यदि वे दस्तावेज़ों में प्लग प्राप्त कर सकें, नोट जारी कर सकें, आदि इस बात पर ज़ोर दे सकें कि डिफ़ॉल्ट से परे विकल्प हैं।

मुझे यकीन है कि ऐसा ही होगा। डॉक्स पहले से ही कई विषयों के लिए वैकल्पिक कार्यान्वयन सूचीबद्ध करता है, जैसे DI कंटेनर , लॉगिंग प्रदाता , स्वैगर एकीकरण , या EF कोर डेटाबेस प्रदाता ।

@ फिलिप-हेडन
टेम्प्लेट सिस्टम पहले से ही अनुकूलन योग्य टेम्प्लेट का समर्थन करता है, और मौजूदा टेम्प्लेट में वास्तव में पहले से ही कई विकल्प हैं। वर्तमान में जो संभव है उसके लिए बस dotnet new mvc --help । मुझे यकीन है कि आप इसे आसानी से विस्तारित कर सकते हैं उदाहरण के लिए वैकल्पिक JSON सीरियलाइज़र एकीकरण, और इसके लिए फीचर अनुरोध या पुल अनुरोध संभवतः aspnet/Templates पर स्वीकार किए जाएंगे।

@mrange - जितना मैं चीजों को यथासंभव सख्त बनाना पसंद करता हूं .... ऐसा करना गैर-अनुरूप कोड में परिवर्तन करने की क्षमता पर निर्भर करता है।

यदि आप किसी अन्य कंपनी के नियंत्रण में एक लीगेसी सेवा के साथ इंटरैक्ट कर रहे हैं, तो आपत्तिजनक कोड को बदलने की क्षमता शून्य के करीब है। यहां तक ​​​​कि सख्त-ऑन-राइट, जबकि अधिक करने योग्य, यहां अपनी समस्याओं के बिना नहीं है: क्या होगा यदि आपत्तिजनक कोड को एक गैर-अनुरूप वस्तु प्राप्त करने की उम्मीद है?

हो सकता है कि डिफ़ॉल्ट रूप से एक सख्त मोड हो और इसे अधिक उदार मोड में स्पष्ट रूप से स्विच करने में सक्षम हो

@poke मुझे लगता है कि आपको वास्तव में vue cli आज़माने की ज़रूरत है और फिर dotnew new का पुनः प्रयास करें। वर्तमान डॉटनेट नया... है... यह है...

क्या मैं कृपया अनुरोध कर सकता हूं कि आप याद रखें कि JSON के विभिन्न ब्राउज़रों की पार्सिंग int64 मानों का ठीक से समर्थन नहीं करती है, और हमें स्ट्रिंग्स के रूप में लंबे समय तक क्रमबद्ध/deserialize करने की क्षमता प्रदान करती है? यह उन चीजों में से एक है जिसे आप तब तक नोटिस नहीं करते जब तक कि यह आपको कड़ी मेहनत न करे। इस पर एक भिन्नता यह तय करने में सक्षम हो रही है कि क्या संख्याओं को डिफ़ॉल्ट रूप से ints या longs में deserialized किया जाता है।

क्या मैं कृपया अनुरोध कर सकता हूं कि आप याद रखें कि JSON के विभिन्न ब्राउज़रों की पार्सिंग int64 मानों का ठीक से समर्थन नहीं करती है, और हमें स्ट्रिंग्स के रूप में लंबे समय तक क्रमबद्ध/deserialize करने की क्षमता प्रदान करती है? यह उन चीजों में से एक है जिसे आप तब तक नोटिस नहीं करते जब तक कि यह आपको कड़ी मेहनत न करे। इस पर एक भिन्नता यह तय करने में सक्षम हो रही है कि क्या संख्याओं को डिफ़ॉल्ट रूप से ints या longs में deserialized किया जाता है।

....आह, एक्मास्क्रिप्ट, सब कुछ दोगुना करने के लिए धन्यवाद। मुझे यकीन है कि इससे कोड के किसी अन्य भाग में समस्या नहीं हुई है ...

एक शुद्धतावादी के रूप में, मैं इस तरह की चीजों को नापसंद करता हूं।
एक यथार्थवादी के रूप में, मुझे लगता है कि मुझे इससे सहमत होना होगा।

क्या नए JSON कार्यान्वयन का कोई भाग .Net Standard 2.1 में होगा ?

मैं इसका थोड़ा सा अनुसरण कर रहा हूं, और मुझे यकीन नहीं है कि मैंने इसे याद किया है। क्या कोई प्रस्तावित एपीआई सतह या इंटरफ़ेस है जिसकी मैं समीक्षा कर सकता हूं? मुझे इस प्रस्ताव के लिए एपीआई सतह क्षेत्र देखने में दिलचस्पी है।

क्या कोई प्रस्तावित एपीआई सतह या इंटरफ़ेस है जिसकी मैं समीक्षा कर सकता हूं?

अभी भी बहुत कुछ करना बाकी है, लेकिन एपीआई समीक्षा नोट्स हैं ।

अद्यतन: रोडमैप भी यहाँ उपलब्ध

तो कैसे सुविधा पूर्ण होगी aspnet 3.0 api की तुलना json.net api से की जाएगी? साथ ही, क्या सभी उद्देश्यों और उद्देश्यों के लिए json.net देशी एपीआई के साथ नए ऐप्स के विकास से चरणबद्ध हो जाएगा?

बस प्रदर्शन में सुधार करें या इसका मतलब है कि json.net के सभी फ़ंक्शन को बदलें?

यह आश्चर्यजनक खबर है।

मैं दृढ़ता से अनुशंसा करता हूं कि @neuecc के साथ सहयोग करने का प्रयास करें MessagePack , Utf8Json , ZeroFormatter आदि के साथ उनका काम अभूतपूर्व रहा है।

@linkanyway परिणाम नया आवंटन एपिस प्रदान करते हुए, json.net के सबसेट को प्रतिस्थापित करना होगा।

मुझे संदेह है कि अधिकांश aspnet उपयोगकर्ताओं के पास json.net कार्यान्वयन के लिए कोई मजबूत निर्भरता नहीं होगी और वे लगभग मूल रूप से माइग्रेट करने में सक्षम होंगे।

क्या कोई प्रस्तावित एपीआई सतह या इंटरफ़ेस है जिसकी मैं समीक्षा कर सकता हूं?

अभी भी बहुत कुछ करना बाकी है, लेकिन dotnet/corefx#33216 एक शुरुआत है। यहां एपीआई समीक्षा नोट्स हैं ।

अद्यतन: रोडमैप भी यहाँ उपलब्ध

@खेलंग क्या हमें कोई लैंग सहायता मिलने जा रही है जिसे हम असली के लिए सी # में

ओएसएस दिशा में एक और अच्छा आंदोलन। अन्य वाणिज्यिक प्लेटफार्मों के डेवलपर्स को एमएस की तुलना में कुछ बेहतर विकसित करने के लिए प्रेरित करेगा, या पूरी तरह से ओएसएस बन जाएगा यदि वे वास्तव में समुदाय की परवाह करते हैं।

क्या हमें कोई लैंग मदद मिलेगी कि हम असली के लिए सी # में जेसन लिख सकें?

@dotnetchris मुझे यकीन नहीं है कि "लैंग हेल्प" से आपका क्या मतलब है? JSON अक्षर? मुझे संदेह है कि ऐसा होगा। क्या आपने आने वाली "एम्बेडेड भाषा" सुविधा को देखा है? विशेष रूप से JSON के लिए ?

@खेलंग निश्चित रूप से सही दिशा में एक कदम है, लेकिन मेरा मतलब है पूर्ण झटका समर्थन। अपने लिंक से समान नमूना वस्तुओं का उपयोग करना, इसके समान:

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

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

पर्याप्त वूडू के साथ, जैसे कि अंतर्निहित टपल/वैल्यूटुपल/रिकॉर्ड ऑब्जेक्ट जनरेशन, ताकि सभी पर्दे के पीछे लैंग स्तर पर काम कर सकें।

इसके विपरीत संकलक जेसन सेवाओं को लागू कर सकता है, एक वर्ग बना सकता है और फिर कक्षा के एक उदाहरण के साथ काम कर सकता है जैसे कि आपने लिखा था:

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

संपादित करें: एलओएल @ डाउनवॉटर।

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

@dotnetchris यदि आप रुचि रखते हैं, तो कृपया https://github.com/dotnet/roslyn/pull/24110 पर वोट

क्या "बिल्ट-इन" और "प्लेटफ़ॉर्म प्रदान किया गया" JSON API का मतलब है कि यह एक अलग (नेटस्टैंडर्ड) नगेट पैकेज नहीं होगा? अगर नहीं होगा तो क्यों नहीं?

मुझे लगता है कि नया ASP.NET कोर साझा ढांचा nuget pakages पर निर्भर नहीं हो सकता है, या यह कर सकता है?

क्या पहले से कोई System.Json नेमस्पेस नहीं है? क्या यह नाम स्थान है जिसका उपयोग/विस्तार .NET Core 3.0 और अंततः .NET मानक के लिए किया जा रहा है। Xamarin.Android 7.1+, Xamarin.iOS 10.8+ और Xamarin.Mac 3.0+ पर उस नेमस्पेस का पहले से ही उपयोग किया जा चुका है (इसका इतना उपयोग नहीं किया जा सकता है लेकिन उपलब्ध 😅)।

इसे हटाने से पश्चगामी संगतता टूट जाएगी। इसे छोड़कर एक नया एपीआई शुरू करने से कुछ भ्रम हो सकता है। नए एपीआई जोड़ते समय किसी भी एपीआई को हटाए बिना इसे विस्तारित/बढ़ाना थोड़ा प्रतिबंधित हो सकता है।

JsonReader/JsonWriter के लिए इंटरफेस होना बहुत अच्छा होगा, क्योंकि केवल स्ट्रीम के अलावा अन्य स्रोत और लक्ष्य हैं। उदाहरण के लिए मैं MongoDB के लिए JSON.NET का भी उपयोग करता हूं। यह तेज़ है और मुझे अपने अनुप्रयोगों में एकाधिक धारावाहिक बनाए रखने की आवश्यकता नहीं है।

मुझे पता है कि यह प्रदर्शन को थोड़ा नुकसान पहुंचा सकता है, लेकिन यह बहुत उपयोगी है।

@SebastianStehle: JsonReader / JsonWriter उच्च स्तर कपोल-कल्पना कर रहे हैं, terrajobst देखते टिप्पणी

3.0 की योजना इस प्रकार है:

1. अंतर्निहित उच्च-प्रदर्शन JSON APIs। निम्न स्तर का पाठक/लेखक, एक स्ट्रीम आधारित पाठक/लेखक , और एक >धारावाहिक।
2. ASP.NET Core JSON घटक के लिए प्लग करने योग्य wrt है।

एक खुला प्रश्न है कि 3.0 में ASP.NET के लिए कौन से टेम्प्लेट उपयोग करेंगे। निष्ठा के आधार पर हम 3.0 तक प्रदान कर सकते हैं हम उन्हें Json.NET एकीकरण पैकेज में खींच सकते हैं। हालाँकि, लक्ष्य पर्याप्त निष्ठा और समानता प्रदान करना है जो केवल डिफ़ॉल्ट रूप से अंतर्निहित लोगों पर निर्भर करता है।

उच्च स्तरीय, प्रयोग करने में आसान एपीआई को स्ट्रीम के चारों ओर लपेटा जाएगा ताकि आसानी से और स्ट्रीम से डिसेरिएलाइज़ किया जा सके (यह अक्सर सबसे आम होता है, जब क्रमबद्ध किया जाता है। यदि आप उन परिदृश्यों में सर्वश्रेष्ठ प्रदर्शन चाहते हैं जहां आप स्ट्रीम का उपयोग नहीं कर सकते हैं, तो आपको निम्न का उपयोग करना चाहिए स्तर एपीआई जो Span<T> या Memory<T> , खासकर जब आपके पास डेटा पहले से ही हाथ में है/मेमोरी में आप इनका उपयोग करना चाहते हैं और एसिंक का ओवरहेड नहीं है।

@त्सेंगएसआर

https://github.com/neuecc/Utf8Json प्रदर्शन कारणों (वर्चुअल कॉल और आवंटन मुझे लगता है) के कारण कस्टम पाठक/लेखक लिखने की कार्यक्षमता प्रदान नहीं करता है और मैंने सोचा कि वे उसी रास्ते पर जाना चाहेंगे। लेकिन अभी तक मैंने अभी तक कोई क्रमबद्धता कोड नहीं देखा है।

मैं @ JonasZ95 और @gregsdennis से सहमत हूं, मुझे उम्मीद है कि कार्यान्वयन समान JSON.Net कार्यान्वयन विवरण का एक सरल अमूर्त नहीं होगा बल्कि इसके बजाय यह _ चाहिए_ जैसा दिखता है पर ध्यान केंद्रित करेगा।

मुझे यह भी लगता है कि इसे 2 अलग-अलग कार्यों के रूप में देखा जाना चाहिए ...

1. क्रमांकन / अक्रमांकन
2. उक्त क्रमांकन और अक्रमांकन का json संस्करण।

उम्मीद है कि ASP.NET कोर फ्रेमवर्क JSON विशिष्ट अमूर्त के बजाय एक सामान्य क्रमांकन अमूर्तता का उपयोग करेगा।

जहां तक ​​एक्स्टेंसिबिलिटी की बात है, मुझे उम्मीद है कि फ्रेमवर्क एब्स्ट्रैक्शन को कोडिंग की DI तकनीक का उपयोग करेगा (इंटरफेस अमूर्त वर्ग नहीं) और बस एक स्थानीय डिफ़ॉल्ट प्रदान करता है। JSON लाइब्रेरी लेखकों के दृष्टिकोण से यह सबसे बड़ी एक्स्टेंसिबिलिटी प्रदान करेगा क्योंकि आपको बस एक ASP.NET कोर एडॉप्टर क्लास प्रदान करना है जो इंटरफेस के लाइब्रेरी कार्यान्वयन का उपयोग करता है और फिर लाइब्रेरी एडेप्टर का उपयोग करने के लिए ASP.NET कोर को कॉन्फ़िगर करता है।

किसी तृतीय पक्ष पुस्तकालय के लिए कार्यान्वयन कुछ इस तरह दिख सकता है:
```सी#
// तीसरे पक्ष के पुस्तकालयों का संदर्भ लें
न्यूटनसॉफ्ट.जेसन का उपयोग करना;

// संक्षिप्तता के लिए बहुत ही भोला उदाहरण सिर्फ to
// मुद्दे पर आए
पब्लिक क्लास न्यूटनसॉफ्ट एडेप्टर: ISerializer
{
निजी JsonSerializerSettings _settings;
निजी स्वरूपण _format;

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

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

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

}

...

// तीसरे पक्ष के अनुकूलन विकल्पों के साथ सेटअप एडेप्टर
वर सेटिंग्स = नया JsonSerializerSettings
{
मिसिंग मेम्बरहैंडलिंग = न्यूटनसॉफ्ट.जेसन.मिसिंग मेम्बरहैंडलिंग
};
var एडॉप्टर = नया न्यूटनसॉफ्ट एडेप्टर (सेटिंग्स, फ़ॉर्मेटिंग। इंडेंटेड);

// asp.net कोर कॉन्फ़िगर करें
// जहां एडेप्टर ISerializer लागू करता है (या आप जो भी नाम लेकर आते हैं)
// पुस्तकालय लेखक अपनी खुद की UseXYZ() एक्सटेंशन विधि भी प्रदान कर सकते हैं।
app.UseSerializer (एडाप्टर);
```

SIMD- आधारित टेक्स्ट पार्सिंग में बहुत प्रगति हुई है, जिसमें संरचित टेक्स्ट, जैसे JSON शामिल है । क्या इस बात की कोई संभावना है कि .NET Core में काम इस प्रदर्शन स्तर तक पहुंच जाएगा? क्या इन तकनीकों का उपयोग करने का कोई तरीका है?

अरे, यहां तक ​​कि माइक्रोसॉफ्ट रिसर्च के पास भी कुछ नए हाई-परफ सॉल्यूशंस हैं !

@ एंथनी मास्ट्रियन इसे लाने के लिए धन्यवाद। मुझे इस बात का अंदाजा लगाने के लिए किसी भी बेंचमार्क में दिलचस्पी है कि यह वर्तमान Json impl simdjson से कैसे तुलना करता है।

वैसे, सिमडसन के लेखकों ने कहा कि वे अभी भी इस परियोजना को पूरी तरह से प्रकाशित करने पर काम कर रहे हैं (मुझे लगता है, अधिक डॉक्टर)। अभी के लिए, आप एचएन पर इस परियोजना की कुछ

क्या इन तकनीकों का उपयोग करने का कोई तरीका है?

.NET Core 3.0 प्लेटफॉर्म पर निर्भर इंट्रिनिक्स का एक गुच्छा शिप करने के लिए होता है, इसलिए यह निश्चित रूप से करने योग्य है

इसके लायक क्या है, मुझे लगता है कि एक वेब स्कोप में, नेटवर्क एक प्राथमिक बाधा है, और यह अच्छा है कि आप सेकंड के भीतर गीगाबाइट्स को पार्स कर सकते हैं, मुझे नहीं लगता कि यह वेब प्रोजेक्ट के लिए बहुत उपयोगी है।

मुझे गलत मत समझो, इस तरह के प्रदर्शन अनुकूलन बहुत अच्छे हैं और शायद बहुत छोटे JSON दस्तावेज़ों को भी लाभान्वित करेंगे। लेकिन अभी के लिए, मुझे लगता है कि नई लाइब्रेरी का ध्यान स्मृति आवंटन से बचने और सब कुछ नेटवर्क परत के बहुत करीब से स्थानांतरित करने पर है। अकेले ही JSON.NET पर पहले से ही प्रदर्शन में काफी सुधार करना चाहिए। लेकिन जब प्रारंभिक कार्य किया जाता है, तो अतिरिक्त अनुकूलन को देखना एक और कहानी हो सकती है।

जहां मैं काम करता हूं हम रोजाना JSON के टेरा बाइट्स को पार्स करते हैं। मैं दूसरों के बारे में भी जानता हूं जो बहुत सारे JSON दस्तावेज़ों को संसाधित करने के लिए .NET और F# का उपयोग करता है। JSON सिर्फ सर्वर => ब्राउज़र परिवहन तंत्र से अधिक बन गया है। शुद्ध बैकएंड परिदृश्यों में इसका बहुत उपयोग किया जाता है।

ओएफसी; बैकएंड के लिए AVRO/Protobuf जैसे बाइनरी प्रारूप में स्विच करना बेहतर होगा, लेकिन अक्सर यह मुश्किल होता है और JSON के कुछ लाभ होते हैं (मैं अनिच्छा से स्वीकार करता हूं)। वास्तविक तेज़ JSON पार्सर होने से सचमुच हमारे जैसी कंपनियों के लिए $10,000 डॉलर प्रति माह की बचत हो सकती है।

@poke यह प्रोजेक्ट .NET कोर (ASP.NET नहीं...) के अंतर्गत आता है, इसलिए यह सभी वर्कलोड के लिए प्रासंगिक है, न कि केवल वेब के लिए।

मैं इस विचार पर सहमत हो सकता हूं कि .NET Core 3.0 के लिए इस विशिष्ट अनुकूलन तकनीक पर काम करने में बहुत देर हो चुकी है, लेकिन मुझे उम्मीद है कि भविष्य में अनुकूलन संभव होगा (यानी परिवर्तनों को तोड़े बिना) यह सुनिश्चित करने के लिए अभी कुछ जांच की गई है। )

यूनिफाइड मैपिंग असेंबली ('System.Text.Json.Mapping') जैसा कुछ बेहतर हो सकता है, जहां JSON को C# कक्षाओं में मैप करने के लिए विशेषताओं और अन्य सामान को परिभाषित किया जाए? इस चीज़ को लागू करने के बाद सभी मौजूदा JSON पार्सर्स/राइटर्स को एकीकृत मैपिंग का उपयोग करने के लिए अपनाया जा सकता है। यह सभी .NET मानक अनुप्रयोगों को बिना किसी दर्द के विभिन्न JSON पुस्तकालयों के बीच माइग्रेट करने की क्षमता प्रदान करेगा

@AlexeiScherbakov नए अमूर्त वास्तव में इतना मदद नहीं करते हैं। आप एक सामान्य अमूर्तता को चुनकर अपने आप को फिर से सीमित कर लेंगे और हमेशा नए पुस्तकालय होंगे जो अमूर्तता का उपयोग नहीं कर सकते हैं और अधिक की आवश्यकता होती है। यह हमेशा से ऐसा ही रहा है, उदाहरण के लिए लॉगिंग के साथ ।

मुझे नहीं लगता कि इस नए कार्यान्वयन के आधार पर एक नया अमूर्त बनाने से हमें कोई लाभ मिलेगा, खासकर जब पुस्तकालय को वैसे भी बहुत कम सुविधा संपन्न होने के लिए डिज़ाइन किया गया हो।

और वास्तव में डेटाकंट्रैक्ट/डेटामेम्बर के रूप में पहले से ही एक मौजूदा नेटस्टैंडर्ड एब्स्ट्रैक्शन है जो मुझे आशा है कि यह पुस्तकालय सम्मान समाप्त कर देगा (भले ही वह अमूर्त कुछ हद तक सीमित हो)।

एक अनदेखा विशेषता के अलावा हमारे पास पूरा करने के लिए एक अरब नई विशेषताएँ और परिदृश्य नहीं हो सकते हैं। इसके बजाय कक्षाओं के लिए JSON की 1:1 मैपिंग करेंगे, यदि आप मानक से बाहर कुछ भी करना चाहते हैं या विरासत का समर्थन करना चाहते हैं, तो json.net का उपयोग करें।

व्यक्तिगत रूप से मुझे JSON <=> C# Classes की इतनी परवाह नहीं है। मुझे लगता है कि JSON मॉडल से बनाए गए C# ऑब्जेक्ट मॉडल से JSON को अलग करने/लिखने की अवधारणा होना महत्वपूर्ण है।
इस तरह मैं (जो JSON <=> C# कक्षाओं के बारे में इतना परवाह नहीं करता) किसी प्रकार के ऑब्जेक्ट मॉडल पर राउंड ट्रिपिंग के बिना वास्तव में कुशल पार्सर हो सकता है।

@mrange यही पाठक और लेखक के लिए है

क्या इसका मतलब है कि मैं जेएसओएन एपीआई प्रदान किए गए प्लेटफॉर्म में रीडर/राइटर एपीआई की उम्मीद कर सकता हूं? क्या पाठक/लेखक पैटर्न सबसे कुशल है?

अभी तक System.Text.Json में 3 प्रकार हैं :

• Utf8JsonReader - UTF-8 एन्कोडेड JSON टेक्स्ट को पढ़ने का एक तेज़, गैर-कैश्ड, फ़ॉरवर्ड-ओनली तरीका।
• Utf8JsonWriter - ^ Utf8JsonReader , लेकिन लिखने के लिए।
• JsonDocument - JSON पेलोड के लिए केवल-पढ़ने के लिए रैंडम-एक्सेस दस्तावेज़ मॉडल।

उपरोक्त सभी प्रकार (अधिक या कम) आवंटन मुक्त होना चाहिए

हमने सिमडजसन पेपर पोस्ट किया: https://arxiv.org/abs/1902.08318

simdjson के C# पोर्ट पर भी काम चल रहा है: https://github.com/EgorBo/SimdJsonSharp

cc @EgorBo

यूनिफाइड मैपिंग असेंबली ('System.Text.Json.Mapping') जैसा कुछ बेहतर हो सकता है, जहां JSON को C# कक्षाओं में मैप करने के लिए विशेषताओं और अन्य सामान को परिभाषित किया जाए? इस चीज़ को लागू करने के बाद सभी मौजूदा JSON पार्सर्स/राइटर्स को एकीकृत मैपिंग का उपयोग करने के लिए अपनाया जा सकता है। यह सभी .NET मानक अनुप्रयोगों को बिना किसी दर्द के विभिन्न JSON पुस्तकालयों के बीच माइग्रेट करने की क्षमता प्रदान करेगा

मुझे वाकई उम्मीद है कि नया अमूर्त गुणों पर निर्भर नहीं है। मैं अंतर्निहित पुस्तकालयों में स्वच्छ पीओसीओ वस्तुओं का उपयोग करने की कोशिश करता हूं और कार्यान्वयन के बारे में जानने से बचने के लिए डीआई का उपयोग करता हूं। मैं निश्चित रूप से कार्यान्वयन के लिए आवश्यक विशेषताओं के साथ अपने अंतर्निहित वर्गों को सजाना नहीं चाहता हूं। यह यूआई परतों में अतिरिक्त कक्षाएं बनाने का कारण बन सकता है जो अनिवार्य रूप से केवल मौजूदा डोमेन ऑब्जेक्ट को जेसन में मैप करता है।

शायद जेसन से सी # कक्षाओं की 1-1 मैपिंग एक बेहतर दृष्टिकोण होगा, कम से कम कुछ मामलों में आप नई कक्षाएं बनाने से बच सकते हैं, भले ही अन्य मामलों में व्यूमोडेल प्रकार की कक्षाएं अभी भी आवश्यक हों।

यह अच्छा होगा, हालांकि उन गुणों को अनदेखा करने का कोई तरीका था जिनकी आवश्यकता नहीं है और कम से कम कुछ क्रमबद्धता पहलुओं (जैसे ऊंट बनाम पास्कल आवरण) को नियंत्रित करते हैं।

@mrange यही पाठक और लेखक के लिए है

@davidfowl क्या इसका मतलब है कि नए एपीआई इस मार्ग पर जा रहे हैं? क्या डिजाइन को अंतिम रूप दे दिया गया है?

क्रमांकन समर्थन उतर रहा है जैसा कि हम बोलते हैं । संबंधित मुद्दा कहता है:

• समय की कमी के कारण, और प्रतिक्रिया एकत्र करने के लिए, फीचर सेट 3.0 के लिए न्यूनतम व्यवहार्य उत्पाद के लिए अभिप्रेत है।
• साधारण POCO ऑब्जेक्ट परिदृश्यों को लक्षित किया जाता है। ये आमतौर पर डीटीओ परिदृश्यों के लिए उपयोग किए जाते हैं।
• एपीआई को बाद के रिलीज में और समुदाय द्वारा नई सुविधाओं के लिए एक्स्टेंसिबल होने के लिए डिज़ाइन किया गया है।
• विभिन्न विकल्पों को परिभाषित करने के लिए डिज़ाइन-टाइम विशेषताएँ, लेकिन फिर भी रन-टाइम पर संशोधनों का समर्थन करती हैं।
• COMP के लिए मानक प्रतिबिंब के लिए फॉलबैक के साथ आईएल एमिट का उपयोग करके उच्च प्रदर्शन।

यह भी विवरण देता है कि वे एनम रूपांतरण, नल हैंडलिंग, ऊंट- बनाम पास्कलकेसिंग इत्यादि का समर्थन करने की योजना कैसे बना रहे हैं।

यदि आपके पास इनमें से किसी पर प्रतिक्रिया है, तो आपको उस मुद्दे या पुल अनुरोध में अपनी टिप्पणी छोड़ देनी चाहिए।

@lemire वाह, यह वास्तव में अच्छा है। सिमडसन वास्तव में सुपर फास्ट है।

कोई मौका है कि आप TechEmpower के

मुझे ये कार्यान्वयन मिले: TechEmpower रेपो में और ASP.NET रेपो में ।

@KPixel यह क्रमांकन है, है ना? इस बीच simdjson एक पार्सर है ... जब तक मैं शर्तों के बारे में भ्रमित नहीं हूं, ये चीजें विपरीत दिशाओं में जाती हैं?

मेरा बुरा। मैंने मान लिया कि एक अक्रमांकन भाग था (जो पार्सर का उपयोग करेगा)।

क्या System.Text.Json एक .net मानक nuget पैकेज होगा? या यह कुछ ऐसा है जो केवल .net core 3.0 के लिए उपलब्ध है?

@ John0King यहाँ एक नज़र डालें: https://github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

मुझे लगता है कि प्रयोज्यता नए JSON पैकेज का भी फोकस होना चाहिए। एक विशेषता मुझे लगता है कि इसमें JSON स्कीमा सत्यापन समर्थन होना चाहिए। न्यूटनसॉफ्ट इसके लिए शुल्क लेता है। यह कुछ ऐसा है जो इतना मौलिक है कि इसे मंच में मुफ्त में प्रदान किया जाना चाहिए, जैसा कि एक्सएमएल स्कीमा सत्यापन के मामले में था।

@ jemiller0 मेरी धारणा यह है कि XML सत्यापन कुछ हद तक मिश्रित बैग रहा है और JSON स्कीमा को वास्तविक शब्द में इतना अपनाया गया है। आप हमेशा एक अतिरिक्त कदम के रूप में एक पुस्तकालय के माध्यम से एक स्कीमा जांच कर सकते हैं ... निश्चित रूप से, इसमें सॉफ़्टवेयर लाइसेंस प्राप्त करना शामिल हो सकता है, लेकिन क्या यह एक बड़ी बात है?

@lemire हाँ, यह बड़ी बात है, यदि आप ओपन सोर्स सॉफ़्टवेयर विकसित कर रहे हैं और अपने सॉफ़्टवेयर को सभी के लिए उपलब्ध कराना चाहते हैं। एक्सएमएल पार्सिंग एक मिश्रित बैग नहीं है। यह काम करता है। JSON स्कीमा सत्यापन के साथ वही बात। ऐसा करने के लिए बिल्ट-इन फ्री तरीका न होना .NET प्लेटफॉर्म को अप्रतिस्पर्धी बनाता है।

मैंने वास्तविक दुनिया में कभी भी जेसन स्कीमा का इस्तेमाल नहीं देखा है। फिर भी यह यहां चर्चा किए गए कार्यान्वयन का हिस्सा नहीं होना चाहिए। और json.net में अरबों अन्य सुविधाओं और विचित्रताओं में से कोई भी यहां लागू नहीं किया जाना चाहिए। यह सुपर लाइट वेट फास्ट कार्यान्वयन से ज्यादा कुछ नहीं होना चाहिए। यदि आप इस बात से नाखुश हैं कि आपको json.net के लिए json सत्यापन का समर्थन करने के लिए लाइसेंस की आवश्यकता है। अपना स्वयं का ओपन सोर्स कार्यान्वयन बनाएं और इसे स्वतंत्र रूप से उपलब्ध कराएं।

@ जेमिलर0

मैं वास्तव में उत्सुक हूं: क्या अन्य प्रोग्रामिंग भाषाएं अपने मानक पुस्तकालय में JSON स्कीमा समर्थन प्रदान करती हैं?

इस पुस्तकालय का लक्ष्य JSON के साथ काम करने के लिए एक उच्च प्रदर्शन करने वाला, निम्न-स्तरीय पुस्तकालय होना है। जो कुछ भी ऐसा नहीं है, जिसमें JSON.NET और JSON स्कीमा की अधिकांश उन्नत सुविधाएँ शामिल हैं, वह इसका हिस्सा नहीं होगी।

यदि आप JSON स्कीमा सत्यापन चाहते हैं, तो आप इस पुस्तकालय के शीर्ष पर एक सत्यापनकर्ता को लागू करने के लिए स्वतंत्र हैं, जो आपको ऐसा करने की अनुमति देने के लिए पर्याप्त निम्न स्तर का होना चाहिए।

मुझे विश्वास नहीं है कि एक मानक पुस्तकालय में JSON स्कीमा सत्यापन होने से किसी प्लेटफ़ॉर्म के प्रतिस्पर्धी होने या न होने से कोई लेना-देना नहीं है।

इस पुस्तकालय का लक्ष्य JSON के साथ काम करने के लिए एक उच्च प्रदर्शन करने वाला, निम्न-स्तरीय पुस्तकालय होना है। जो कुछ भी ऐसा नहीं है, जिसमें JSON.NET की अधिकांश उन्नत सुविधाएं शामिल हैं, वह इसका हिस्सा नहीं होगी।

सिवाय इसके कि इसमें उच्च-स्तरीय सुविधाएँ भी शामिल होंगी, जिन्हें Newtonsoft.Json के ड्रॉप-इन प्रतिस्थापन के लिए डिज़ाइन किया गया है।

@poke आप उसके लिए आप हकदार हैं। एक्सएमएल का इस्तेमाल हर जगह किया जाता है। इसलिए, ठीक है, माइक्रोसॉफ्ट ने .NET फ्रेमवर्क के साथ सत्यापन समर्थन शामिल किया। अब, जेएसओएन सभी गुस्से में है और कॉन्फ़िगरेशन फाइलों, वेब एपीआई इत्यादि में हर जगह उपयोग किया जाता है। जेएसओएन के लिए उसी स्तर का समर्थन होना समझ में आता है जैसा ऐतिहासिक रूप से एक्सएमएल के लिए समर्थित था। व्यक्तिगत रूप से, मुझे यह थोड़ा हास्यास्पद लगता है कि Microsoft इसके लिए तीसरे पक्ष के सॉफ़्टवेयर का उपयोग कर रहा है। यह मंच की मुख्य विशेषता होनी चाहिए।

@lemire मैं जल्द ही पायथन की जाँच करूँगा। किस बिंदु पर मुझे या तो पता चलेगा कि यह बिल्ट-इन है, या आसानी से इंस्टॉल करने योग्य पैकेज के रूप में शामिल है। अगर ऐसा नहीं होता तो मुझे बहुत आश्चर्य होता। मैं अभी जो चाहिए उसके लिए मैं NJsonSchema का उपयोग करने पर विचार कर रहा हूं। ठीक ऊपर से, आप देख सकते हैं कि दस्तावेज़ीकरण बेकार है। हाँ, तीसरे पक्ष के पुस्तकालयों पर भरोसा करना जो गुणवत्ता हो सकता है या नहीं भी JSON के साथ काम करने जैसी चीजों के लिए एक अच्छा विचार है जो पूरी तरह से सर्वव्यापी है और हर जगह उपयोग किया जाता है। आइए हम सभी बिना किसी दस्तावेज़ीकरण वाले व्यावसायिक सॉफ़्टवेयर या तीसरे पक्ष के पैकेज पर भरोसा करें। .NET को सिर्फ पायथन जैसे अन्य प्लेटफॉर्म से मेल नहीं खाना चाहिए। उन्हें लीक से हटकर उचित दस्तावेज़ीकरण के साथ गुणवत्तापूर्ण सॉफ़्टवेयर प्रदान करके उन्हें हराना चाहिए। यह ऐतिहासिक रूप से रहा है कि इसने कैसे काम किया है। जहां मैं काम करता हूं, वहां हर कोई .NET से नफरत करता है और मुझे पाइथन का उपयोग करने के लिए मजबूर करना चाहता है। मुझे नहीं पता कि आपने गौर किया है या नहीं, लेकिन, अधिक से अधिक लोग जहाज को छोड़कर पायथन में स्विच कर रहे हैं। अपने बॉस को बताना कि मुझे कुछ सरल करने के लिए लाइसेंस खरीदने की आवश्यकता है जैसे कि JSON को मान्य करना उड़ान नहीं भरेगा। बदले में मुझे क्या मिलेगा, यह सवाल किया जाता है कि मैं पहली बार में .NET का उपयोग क्यों करना चाहूंगा। इस तथ्य पर कभी ध्यान न दें, कि यह एक ओपन सोर्स प्रोजेक्ट के लिए है जहां आपको लाइसेंस नहीं मिल सकता है। उम्मीद है, मुझे पता चलेगा कि NJsonSchema बस काम करता है। मैं सिर्फ ढांचे में एक स्पष्ट चूक की ओर इशारा कर रहा हूं जो कि JSON के साथ काम करने वाले किसी भी व्यक्ति के लिए स्पष्ट होना चाहिए।

मैं काम पर JSON स्कीमा का उपयोग करता हूं और मेरे पास आधे अच्छे JSON पार्सर + JSON स्कीमा सत्यापनकर्ता की तुलना में एक वास्तविक अच्छा JSON पार्सर है। इसके अलावा AFAIK JSON स्कीमा अभी एक _draft_ 7 है। तो जेएसओएन स्कीमा बाहरी पुस्तकालय के रूप में है जो स्कीमा के साथ जल्दी से विकसित हो सकता है, मुझे समझ में आता है। हालांकि रोडमैप में JSON स्कीमा होना अच्छा होगा।

@ जेमिलर0

यह समझ में आता है कि JSON के लिए उसी स्तर का समर्थन है जो ऐतिहासिक रूप से XML के लिए समर्थित था।

.Net में XSLT और XPath के लिए समर्थन भी शामिल है। यदि आप "समान स्तर का समर्थन" चाहते हैं, तो क्या इसका मतलब यह नहीं है कि आपको JSON के लिए उनमें से कुछ संस्करण की भी आवश्यकता होगी?

मैं जो कहना चाह रहा हूं वह है: JSON पारिस्थितिकी तंत्र XML पारिस्थितिकी तंत्र से अलग है। दोनों के अलग-अलग उपयोग पैटर्न हैं और संबंधित तकनीकों में अलग-अलग उपयोग संख्याएं और मानकीकरण स्तर हैं। साथ ही, NuGet, git या GitHub के अस्तित्व में आने से पहले XML को .Net में जोड़ा गया था। आजकल, किसी तृतीय पक्ष लाइब्रेरी पर भरोसा करना बहुत आसान और अधिक स्वीकार्य है।

तो, नहीं, मुझे नहीं लगता कि आँख बंद करके यह कहना समझ में आता है कि "XML के पास यह था, इसलिए JSON के पास भी होना चाहिए"।

साथ ही, सत्यापन पार्सिंग के लिए केवल ऑर्थोगोनल है। मैं कुछ बिंदु पर सत्यापन समर्थन के साथ बिल्कुल ठीक हो जाऊंगा (संभवतः किसी अन्य पैकेज में पूरी तरह से)। लेकिन उचित पार्सिंग समर्थन के लिए यह बिल्कुल भी आवश्यक नहीं है।

हमें एपीआई आरईएसटी अनुरोधों में डेटा के सख्त सत्यापन के लिए एक तरीका चाहिए।
क्योंकि हम बिना त्रुटियों के एपीआई के माध्यम से आने वाले json को सहेजते हैं और बाद में हम इसे JS में पार्स नहीं कर सकते क्योंकि पीछे वाले कॉमा आदि।

और आप अभी उस अनुरोध को मान्य क्यों नहीं कर सकते?

@ phillip-haydon @ freerider7777 मुझे लगता है कि किसी भी सभ्य JSON पार्सर को JSON विनिर्देश का पालन करना चाहिए और जब दस्तावेज़ अच्छी तरह से गठित नहीं होता है तो त्रुटियों (और/या चेतावनियां) फेंकना चाहिए (उदाहरण के लिए, जब इसमें पिछली कॉमा होती है)। यह बहुत ही बुनियादी है, लेकिन सत्यापन से भी अलग है जो एक स्कीमा के साथ JSON डेटा की तुलना है (कम से कम, इस तरह मैं शर्तों का उपयोग करता हूं)।

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

माइक्रोसॉफ्ट, जो वहां की सबसे बड़ी सॉफ्टवेयर विकास कंपनियों में से एक है, के पास सत्यापन पर काम करने वाला कोई नहीं है। एक तेज़ पार्सर अधिक महत्वपूर्ण है। यह आपको अमान्य JSON को प्रकाश की गति से पार्स करने देगा। :-) यह किसी के साथ नहीं हुआ है कि तेजी से सत्यापन उपयोगी हो सकता है। यह ASP.NET Core की तरह ही है, जो वेब फॉर्म में तेजी से डाउन डाउन अपग्रेड है।

और आप अभी उस अनुरोध को मान्य क्यों नहीं कर सकते?
@ फिलिप-हेडन ऐसे जेसन के साथ नियंत्रक कोड में:
ModelState.IsValid == true

‍♂️

आप पहले से ही NSwag + System.ComponentModel.DataAnnotations साथ अपने json स्कीमा के आधार पर सत्यापन कर सकते हैं:

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

मैं @lemire से सहमत @poke की टिप्पणी देखें)।

मुझे नहीं लगता कि उन्होंने जानबूझकर इसे सभी घंटियों और सीटी के साथ आने के लिए डिज़ाइन नहीं किया है, यह इसे एक घटिया उत्पाद बनाता है।

क्या यह पूर्वावलोकन 4 के साथ शिप करने के लिए हुआ था?

क्या System.Text.Json.Serialization.Policies.JsonValueConverter बनाने की योजना है?Json.net से कनवर्टर कक्षाओं को बदलने की अनुमति देने के लिए सार्वजनिक वर्ग?

क्या System.Text.Json nuget के माध्यम से पूर्ण .Net समर्थन के साथ शिप होगा? पूर्ण इंटरऑप सुनिश्चित करने के साथ-साथ पूर्ण ढांचे से लाभों का लाभ उठाना निश्चित रूप से अच्छा होगा।

System.Text.Json को हाल ही में OOB शिपिंग के लिए netstandard2.0 बायनेरिज़ बनाने के लिए बदला गया था; https://github.com/dotnet/corefx/pull/37129 :

यदि संभव हो, तो आपको .NET Core 3.0 को लक्षित करना चाहिए और इन-बॉक्स System.Text.Json API प्राप्त करना चाहिए। हालाँकि, यदि आपको netstandard2.0 का समर्थन करने की आवश्यकता है (उदाहरण के लिए, यदि आप एक पुस्तकालय डेवलपर हैं), तो आप हमारे NuGet पैकेज का उपयोग कर सकते हैं जो netstandard2.0 संगत है।

पूर्ण ढांचे से लाभ

ये फिर क्या हैं? मैं

@खेलंग

मेरी प्राथमिकता पूर्ण ढांचे (4.5 या जो भी स्वीकार्य न्यूनतम), मानक और कोर सहित कई स्वादों के साथ एक नगेट होगी। बॉक्स असेंबलियों में उपयोग करना बेहतर है।

उपरोक्त लिंक किया गया मुद्दा इस पैकेज को संदर्भित करता है, लेकिन यह समर्थित नहीं है:

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

क्या कोई वर्तमान समर्थित पैकेज है?

मेरी प्राथमिकता पूर्ण ढांचे (4.5 या जो भी स्वीकार्य न्यूनतम), मानक और कोर सहित कई स्वादों के साथ एक नगेट होगी।

आप इसे क्यों पसंद करेंगे? यदि बहु-लक्ष्य की कोई आवश्यकता नहीं है, अर्थात सभी उपयोग किए गए एपीआई मानक का हिस्सा हैं, तो केवल एक ही लक्ष्य होना बेहतर है

क्या कोई वर्तमान समर्थित पैकेज है?

मुझे नहीं लगता कि इसे अभी तक भेज दिया गया है। पीआर का विलय कुछ दिन पहले हुआ था। वह पैकेज एक सामुदायिक परियोजना हुआ करती थी जिसे अब एमएस को हस्तांतरित कर दिया गया है।

@खेलंग यह बारीकियों पर निर्भर करता है - मैं एक सामान्य बयान दे रहा था।

यदि नेट मानक संस्करण को नेट कोर संस्करण से कुछ भी छोड़ना पड़ा जो नेट पूर्ण संस्करण के साथ संभव होगा, तो मैं सभी तीन स्वादों को उपलब्ध होना पसंद करूंगा। वही सामान्य तर्क, मुझे संदेह है, ऊपर दिए गए लिंक किए गए मुद्दे से मूल कथन के रूप में उपयोगकर्ताओं को बॉक्स संस्करण को लक्षित करने के लिए पसंद करने के बारे में।

नगेट पैकेज में संदर्भ जोड़ते समय, उपयुक्त सबसे संगत स्वाद स्वचालित रूप से चुना जाएगा। तो, यह कोई बड़ी बात नहीं है। यदि उपभोक्ता पुस्तकालय शुद्ध मानक है, तो शुद्ध मानक स्वाद का चयन किया जाएगा।

बॉक्स फ्लेवर के लिए मेरी सामान्य प्राथमिकता यह है कि जब मैं goto definition , तो मुझे विघटित स्रोत मिलते हैं। अगर मैं नेट मानक पुस्तकालयों पर goto definition हूं, तो मैं आमतौर पर केवल स्टब स्रोत देखता हूं जो NotImplemented अपवाद फेंकते हैं।

पूर्ण ढांचे से लाभ

ये फिर क्या हैं? मैं

कई एप्लिकेशन .NET फ्रेमवर्क का उपयोग इसलिए नहीं करते हैं क्योंकि वे .NET कोर से बिल्कुल दूर रहना चाहते हैं, बल्कि इसलिए कि .NET कोर एक विकल्प नहीं है। मैं .NET कोर का उपयोग करता हूं जब यह एक विकल्प होता है; जब मुझे विंडोज सर्वर 2012 (न्यूनतम .NET कोर 3.0 संस्करण) से कम विंडोज संस्करणों को लक्षित करना है, तो मुझे .NET फ्रेमवर्क का उपयोग करना होगा। जितना मुझे यकीन है कि यह विंडोज सर्वर 2008 आर 2 और उससे नीचे के लिए समर्थन छोड़ने का एक बहुत ही दर्दनाक निर्णय था, सर्वर के साथ ग्राहकों को भुगतान करने वाली प्रत्येक कंपनी के लिए यह एक बहुत ही दर्दनाक निर्णय है कि वे अपग्रेड नहीं करना चाहते हैं/अक्सर मूल रूप से स्क्रैच से फिर से बनाना चाहते हैं बस इसलिए कि हम थोड़े नए टूल का उपयोग कर सकते हैं।

अगर मैं कल .NET फ्रेमवर्क का उपयोग करना बंद कर दूं तो मुझसे ज्यादा खुश कोई नहीं होगा, लेकिन .NET Core 3.0 और उसके बाद के सभी wpf और विंडोज फॉर्म के अवसरों के साथ, Microsoft अपनी समर्थन नीतियों के साथ इसे एक व्यावहारिक असंभव बना रहा है। मैंने इस बारे में किसी से भी चर्चा करने की कोशिश की है जो माइक्रोसॉफ्ट को सुनेगा, लेकिन दुख की बात है कि मुझे अभी तक एक ईमेल प्राप्त नहीं हुआ है जिसमें यह स्वीकार किया गया था कि संदेश दिया गया था।

@JesperTreetop उद्यम के लिए उपयोग करने लायक .NET कोर के संस्करणों के लिए एलटीएस समर्थन की कमी का उल्लेख नहीं करना;) मुझे उम्मीद है कि हमें 3.x पर एलटीएस समर्थन मिलेगा - मेरे संगठन के .NET आर्किटेक्ट के रूप में, मैं इसके लिए जोर दे रहा हूं .NET कोर एडॉप्शन अगर हमें एलटीएस सपोर्ट वाला 3.x वर्जन मिलता है।

@marksmeltzer कल से .NET 5 का परिचय देने वाला ब्लॉग पोस्ट दिखाता है कि .Net Core 3.1 LTS होगा और नवंबर 2019 में रिलीज़ होने की योजना है।

क्या यह नया JSON सीरिएलाइज़र F# प्रकारों का समर्थन करेगा?

@rliman अच्छी तरह से वर्तमान में यह Guid या Enum का समर्थन नहीं करता है, इसलिए इसे जाने का लंबा सफर तय है। मैं सहमत हूं कि एफ # विकल्प प्रकारों के लिए पूर्ण समर्थन सी # शून्य के समान होना आवश्यक होना चाहिए आईएमएचओ

मैं व्यक्तिगत रूप से सोचता हूं कि यह खराब वास्तुशिल्प डिजाइन निर्णय का एक त्वरित समाधान है। यह बहुत पहले हो जाना चाहिए था.... अब यह हर जगह बहुत दर्द देने वाला है... लाइब्रेरी डेवलपर्स से लेकर एंटरप्राइज डेवलपर्स तक।

इस नई "सुविधा" को "सुचारू" करने का कोई आसान तरीका नहीं है।

यह एमएस एक समस्या को हल करने की कोशिश कर रहा है जो उन्होंने पहले स्थान पर किया था। और अब इसकी कीमत सभी को चुकानी पड़ेगी।

नेट कोर के साथ शुरुआत से लगता है कि वैगन थोड़ा "तेज" है ... इस शुद्ध "फुर्तीली" दृष्टिकोण को थोड़ा धीमा करने और सभी को अपनी सांस पकड़ने की आवश्यकता हो सकती है।

ऐसा लगता है कि ASP.NET Core के साथ ये "फीचर्स" (ब्रेकिंग चेंजेस) नए सामान्य हो गए हैं।

मेरी राय में ASP.NET Core को उनकी वास्तुशिल्प डिजाइन प्रक्रिया के पुनर्विक्रय की सख्त जरूरत है। क्योंकि बार-बार ये "हम इसे बाद में ठीक कर देंगे" फीचर बनाते रहते हैं।

मैं ASP.NET कोर के साथ विकास कर रहा हूं क्योंकि यह शुरुआती बीटा में था... और यह .NET पर एक बड़ा सुधार है।

लेकिन एमएस टीम को एक पल के लिए रुकना चाहिए और सोचना चाहिए कि वे यहां वास्तविक समस्या का समाधान कैसे कर सकते हैं: जल्दबाजी और असंगत वास्तुशिल्प डिजाइन निर्णय।

बस वापस जाएं और अन्य सूत्र पढ़ें... ऐसा लगता है कि यह एक आवर्ती विषय है।

तो हो सकता है कि बैठने का समय हो और फिर से सोचें कि अधिक स्थिर उत्पाद बनाने का सबसे अच्छा तरीका क्या है।

क्लासिक .NET कोर जितना शक्तिशाली नहीं हो सकता है... लेकिन यह 2.0 के बाद से बहुत स्थिर और सुसंगत है।

एकदम मेरे विचार।

हाय @suncodefactory ,
मुझे कुछ समय पहले याद है जब पीपीएल ने एमएस पर ओपनसोर्स पुस्तकालयों का उपयोग नहीं करने के लिए चिल्लाया था, अब उन्हें ऐसा करने के लिए दोषी ठहराया जाता है: डी
मेरे दृष्टिकोण से एस्पनेट/कोर एमवीसी एपीआई एमवीसी 1/2 के बाद से बहुत स्थिर रहा है! 2.0 के बाद से एस्पनेट स्थिर होने का कारण यह था कि यह कभी भी नहीं बदला/सुधारा।
ईमानदार होने के लिए यदि आप एक क्रमांकन पुस्तकालय की उन्नत सुविधा का उपयोग कर रहे हैं, तो आपके पास इसके बारे में पुनर्विचार करने का मौका है और शायद कार्य के लिए उपयुक्त डेटा संरचना के साथ समस्या से संपर्क करें, बजाय इसके कि सभी धारावाहिक सभी भाषा सुविधाओं का समर्थन करते हैं, imo यह है हल करने के लिए गलत समस्या, और क्रमबद्धता का उपयोग करने का गलत तरीका।
स्पष्टता, पिछड़ी संगतता और भविष्य के एक्सटेंशन मेरे सीरियल करने योग्य डीटीओ को ड्राइव करते हैं, सामान्य व्यावसायिक तर्क वस्तुओं में उपयोग किए जाने वाले बहुत अलग व्यापार बंद (वे निजी हैं, बहुत सारे कार्य हैं, आदि ..)

हम प्रूडक्ट टीमों के लगभग किसी भी प्रयास के बिना माइक्रोसर्विसेज को नेट फ्रेमवर्क से लिनक्स (नेट कोर) में स्थानांतरित करने में सक्षम हैं। मुझे नहीं पता कि तुम लोग किस बारे में बात कर रहे हो। Microsoft इस तरह के परिवर्तनों के कार्यान्वयन में तेजी लाने के लिए बहुत अच्छा काम कर रहा है जो लंबे समय से लंबित हैं।

हाय @suncodefactory ,
मुझे कुछ समय पहले याद है जब पीपीएल ने एमएस पर ओपनसोर्स पुस्तकालयों का उपयोग नहीं करने के लिए चिल्लाया था, अब उन्हें ऐसा करने के लिए दोषी ठहराया जाता है: डी

मेरे लिए बात तीसरे पक्ष के पुस्तकालयों के बारे में नहीं है ... यह वास्तुशिल्प डिजाइन के बारे में है जिसमें इस विशेष मामले में कमी है या सिर्फ सादा गलत है।

इसके अलावा मैंने क्लासिक एएसपीनेट के बारे में कभी बात नहीं की ... मैं .NET फ्रेमवर्क 2.0 के बारे में बात कर रहा था। और इसके स्थिर होने का कारण यह नहीं था कि कोई सुधार नहीं था जैसा कि आप झूठा दावा करते हैं (चूंकि .net कोर .NET 4.6.1 पर आधारित है)। इसका कारण यह था कि यह अच्छी तरह से योजनाबद्ध और स्थापत्य था।

क्लासिक एएसपीएनटी एमवीसी बनाम एस्पनेट कोर कितना अच्छा है, जिसका इस विशेष धागे से कोई लेना-देना नहीं है।

यह धागा एक ब्रेकिंग बदलाव के बारे में है जिसे एमएस एक बार फिर से पूरी तरह से सोचे बिना शिप करने वाला है।

हम प्रूडक्ट टीमों के लगभग किसी भी प्रयास के बिना माइक्रोसर्विसेज को नेट फ्रेमवर्क से लिनक्स (नेट कोर) में स्थानांतरित करने में सक्षम हैं। मुझे नहीं पता कि तुम लोग किस बारे में बात कर रहे हो। Microsoft इस तरह के परिवर्तनों के कार्यान्वयन में तेजी लाने के लिए बहुत अच्छा काम कर रहा है जो लंबे समय से लंबित हैं।

इस तरह के बदलाव बिल्कुल नहीं होने चाहिए.... तो क्या आप बदलाव को तोड़कर खुश हैं?

और यह कहना कि एएसपीनेट कोर टीम शिपिंग परिवर्तनों में बहुत अच्छा काम कर रही है, बस सच नहीं है।

मैं बीटा 3 के बाद से एएसपीनेट कोर के साथ विकास कर रहा हूं और मुझे पूरा यकीन है कि वास्तुशिल्प डिजाइन प्रक्रिया की कमी है।

क्लासिक बनाम एएसपीनेट कोर कितना अच्छा है ... मुझे कोई आपत्ति नहीं है क्योंकि मैं भी मानता हूं कि क्लासिक से बेहतर है।

लेकिन सिर्फ इसलिए कि एएसपीनेट कोर क्लासिक से बेहतर है इसका मतलब यह नहीं है कि वे एक महान नौकरी वास्तुकला डिजाइन कर रहे हैं। वे दोनों पूरी तरह से अलग विषय हैं।

क्या हम इस चर्चा को .NET Core 3 में JSON कार्यक्षमता तक सीमित कर सकते हैं?

इस तरह के बदलाव बिल्कुल नहीं होने चाहिए.... तो क्या आप बदलाव को तोड़कर खुश हैं?

तो क्या कोई सुधार नहीं होना चाहिए? यदि आप नहीं चाहते कि सॉफ्टवेयर विकसित हो और विकसित हो और बेहतर हो, तो आप एक प्रोग्रामर भी क्यों हैं?

@suncodefactory

इस तरह के बदलाव बिल्कुल नहीं होने चाहिए.... तो क्या आप बदलाव को तोड़कर खुश हैं?

आह, चलो, आप इसे "ब्रेकिंग चेंज" की तरह ध्वनि बनाते हैं, इसका मतलब है कि आपको अपनी परियोजना को स्क्रैप करना होगा और स्क्रैच से शुरू करना होगा।

एएसपी.नेट कोर 2.x/3.0 में कितने ब्रेकिंग परिवर्तन थे जिन्हें आप गिन सकते हैं . से अधिक की आवश्यकता है

• एक अलग पैकेज का संदर्भ
• भिन्न नामस्थान का उपयोग करना
• कोड की 5 से अधिक पंक्तियों को बदलना
• कोड की 1-2 पंक्तियों को हटाना (अर्थात विकल्प वर्गों से गुण)

??

@suncodefactory

यह धागा एक ब्रेकिंग बदलाव के बारे में है जिसे एमएस एक बार फिर से पूरी तरह से सोचे बिना शिप करने वाला है।

यह वास्तव में एक _ब्रेकिंग_ परिवर्तन कैसे है? नया JSON API पूरी तरह से नया API का सेट है जिसे .NET Core में पेश किया गया है जो न तो किसी मौजूदा सामान को हटाता है और न ही तोड़ता है। हां, आप देखेंगे कि चीजें और पुस्तकालय अंततः इसमें बदल जाते हैं क्योंकि यह विभिन्न अनुकूलन अवसर प्रदान करता है, लेकिन आपको इसे अपने कोड पर लागू करने के लिए मजबूर नहीं किया जाता है।

ASP.NET Core के बारे में विशेष रूप से बोलते हुए, हालांकि _“इसका इस विशेष थ्रेड से कोई लेना-देना नहीं है”_, यदि आप इसकी कुछ अधिक उन्नत सुविधाओं पर निर्भर हैं, तो आपके पास Newtonsoft.Json का उपयोग जारी रखने का विकल्प है। हां, आपको इसे काम करने के लिए कुछ कोड बदलना होगा, लेकिन मुझे नहीं लगता कि यह वास्तव में टूट रहा है कि आपको केवल ऐसा करना होगा यदि आप वास्तव में नए संस्करण में अपग्रेड करना चाहते हैं। यह अब अच्छी बात है: आपके पास और विकल्प हैं।

यदि आप इसे किसी भी कारण से नापसंद करते हैं, तो बेझिझक .NET फ्रेमवर्क से चिपके रहें जो ज्ञात, स्थिर और निश्चित फीचर सेट है। वह वहां काफी देर तक रहेगा, इसलिए आप पूरी तरह से उस पर निर्भर हो सकते हैं। लेकिन कृपया अपने नए-नए-विरोधी एजेंडे को फैलाने के लिए इस धागे का उपयोग करना बंद कर दें, जब _“इसका इस विशेष धागे से कोई लेना-देना नहीं है”_।

ईएफ कोर उपयोगकर्ता से दो प्रश्न।

1. क्या System.Text.Json परिपत्र संदर्भों का समर्थन करेगा? ईएफ कोर डेटा में परिपत्र संदर्भ हो सकते हैं जहां कक्षाओं के बीच नेविगेशनल लिंक दोनों तरफ जा रहे हैं। Json.NET इसे सेटिंग्स के साथ संभालता है:
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. निजी बसने वालों और निजी कंस्ट्रक्टरों के साथ डीडीडी-शैली वाले वर्गों के उदय के साथ System.Text.Json इस प्रकार की कक्षाओं को deserialize कर सकते हैं?

@ जोनपीएसमिथ आईएमओ इससे कोई फर्क नहीं पड़ता। आपको कभी भी किसी इकाई को सीधे क्रमबद्ध नहीं करना चाहिए। आपको एक प्रक्षेपण को क्रमबद्ध करना चाहिए। यह परिपत्र संदर्भों से बचा जाता है, और सभी डेटा को उजागर नहीं करता है, खासकर जब आप इकाई में अधिक गुण जोड़ते हैं जो अंततः संवेदनशील हो सकते हैं।

@ जोनपीएसमिथ : इम्हो दोनों उपयोग के मामले सर्वोत्तम अभ्यास और डीडीडी दोनों दृष्टिकोण से अमान्य हैं।

1. मैंने कभी भी एक सर्वोत्तम अभ्यास नहीं देखा है जो सीधे डिसेरिएलाइज़िंग संस्थाओं की सिफारिश करता है (सबसे सरल ट्यूटोरियल उदाहरणों को छोड़कर)। परिपत्र संदर्भ हमेशा एक कीमत पर आते हैं। इसे पहले से संसाधित वस्तुओं की ट्रैकिंग की आवश्यकता है, इसका मतलब है: स्मृति आवंटन और अतिरिक्त सीपीयू चक्र। लेकिन नई JSON लाइब्रेरी का एक मेल लक्ष्य इन मेमोरी आवंटन से बिल्कुल बचना है
2. अमान्य भी, क्योंकि आप कभी भी किसी डोमेन मॉडल में क्रमबद्ध नहीं होते हैं, खासकर तब नहीं जब आपको वेब अनुरोध जैसे वेबएपी कॉल के माध्यम से डेटा प्राप्त होता है। डीडीडी में आपको हमेशा ईवेंट/कमांड के साथ काम करना चाहिए, अपने वेब एप्लिकेशन को कमांड भेजना चाहिए, रिपोजिटरी से इकाई प्राप्त करना (और निर्जलीकरण) करना चाहिए (ओआरएम मैपिंग या इवेंट सोर्सिंग के माध्यम से), कमांड लागू करें, इसे जारी रखें।

उसके ऊपर, नया JSON API उच्च प्रदर्शन परिदृश्यों के लिए है। अन्य सभी चीजों के लिए जहां आपको समृद्ध फीचर सेट की आवश्यकता है, आप (और चाहिए) अभी भी JSON.NET या जो कुछ भी आपकी आवश्यकताओं को पूरा करता है उसका उपयोग करें।

@suncodefactory यह एक ब्रेकिंग चेंज के विपरीत है। अभी, ASP.NET Core 2.2 में, JSON.NET का उपयोग फ्रेमवर्क के साथ-साथ उपयोगकर्ता कोड द्वारा भी किया जाता है। इसमें आपके द्वारा Newtonsoft.Json के उपयोग के साथ टकराव पैदा करने की क्षमता है; यदि ASP.NET Core 3.0 को JSON.NET 12.x में स्थानांतरित कर दिया गया है और वहां किसी प्रकार की समस्या है जिसने आपके आवेदन को तोड़ दिया है, तो आपको एक समस्या होगी।

उदाहरण के लिए, Microsoft.Extensions.Configuration.Json 2.2.0 देखें - इसकी Newtonsoft.Json 11.0.2 पर निर्भरता है। यह एक विन्यास पैकेज है; HTTP रिक्वेस्ट हैंडलिंग या ASP.NET Core MVC से कोई लेना-देना नहीं है। या Microsoft.IdentityModel.Protocols.OpenIdConnect देखें , जो JSON वेब टोकन को संभालने के लिए इसका उपयोग करता है; यह एक गर्म पथ है जिसे यथासंभव अधिक से अधिक प्रदर्शन की आवश्यकता है। JSON.NET किसी भी मानक से धीमी लाइब्रेरी नहीं है, लेकिन यह उपयोगकर्ता परिदृश्यों की एक विशाल श्रृंखला के लिए प्रदर्शन, सुविधा-समृद्धि और समर्थन के बीच संतुलन बनाता है। Microsoft की नई JSON लाइब्रेरी को ऐसा करने की आवश्यकता नहीं है, क्योंकि JSON.NET मौजूद है। तो यह अधिकतम प्रदर्शन के साथ पूर्ण मूल बातें संभालने पर ध्यान केंद्रित कर सकता है।

System.Runtime.Serialization.Json में .NET का हमेशा अपना JSON क्रमांकन समाधान होता है, लेकिन .NET Core की उच्च-प्रदर्शन वाली दुनिया में यह बहुत अच्छा नहीं है। मैं निश्चित रूप से नहीं चाहता कि इसे प्रत्येक आने वाले अनुरोध पर प्रमाण-पत्र जांचने के लिए बुलाया जाए। आधुनिक UTF-8 डेटा हैंडलिंग और न्यूनतम आवंटन के साथ एक नई JSON लाइब्रेरी का बहुत स्वागत है।

आप अभी भी अपने आवेदन में Newtonsoft.Json को संदर्भित करने में सक्षम होंगे, और इसे पहले की तरह अनुरोध/प्रतिक्रिया डेटा के लिए अक्रमांकन/क्रमबद्धता पाइपलाइन के रूप में उपयोग करना जारी रखेंगे। और अब से, आप इस बात की चिंता किए बिना ऐसा करने में सक्षम होंगे कि कोर फ्रेमवर्क किस संस्करण पर निर्भर करता है। यह सभी की जीत है।

धन्यवाद @ फिलिप-हेडन और @TsengSR आपके विचारों के लिए। मैं पूछ रहा था कि क्या इन सुविधाओं का समर्थन किया जाएगा और आप कहते हैं कि नहीं हैं, जो समझते हैं और स्वीकार करते हैं। मैं उस मामले के लिए Json.NET का उपयोग करना जारी रखूंगा जहां मुझे ईएफ कोर कक्षाओं को क्रमबद्ध/deserializing की आवश्यकता है।

बीटीडब्ल्यू। मेरे पास डीडीडी-शैलियों ईएफ कोर इकाई वर्गों को क्रमबद्ध/deserializing के लिए एक वैध कारण है। मेरे पास एक पुस्तकालय है जिसमें एक सुविधा है जिसे मैं उत्पादन से बीज कहता हूं जो डेवलपर्स को उत्पादन डेटाबेस से डेटा का एक स्नैपशॉट लेने, किसी भी निजी डेटा को अज्ञात करने और फिर स्नैपशॉट के साथ एक नया डेटाबेस बीज करने की अनुमति देता है।

मुझे अपने ग्राहकों के लिए इस सुविधा की आवश्यकता थी और केवल उनके लिए लिखने के बजाय मैंने इसे अपनी ओपन-सोर्स लाइब्रेरी EfCore.TestSupport में बनाया ताकि अन्य लोग इसका उपयोग कर सकें (और मेरे क्लाइंट को इसके लिए मुझे भुगतान नहीं करना पड़ा)।

क्या [DataContract] , [DataMember] और दोस्तों को समर्थन देने की कोई योजना है?

आज यह परिभाषित करने का एक तरीका है कि कैसे प्रकारों को क्रमबद्ध/deserialize (उदाहरण के लिए फ़ील्ड नाम) इस तरह से करना चाहिए जो परियोजना के लिए किसी भी क्रमबद्ध पुस्तकालय पर निर्भरता नहीं लाता है।

वर्तमान JsonNamingPolicy केवल एक स्ट्रिंग लेता है इसलिए सदस्य की विशेषताओं का निरीक्षण करने का कोई तरीका नहीं है।

नमस्ते।
हमने अपनी माइक्रो सेवाओं को डॉटनेट कोर 3 पूर्वावलोकन 6 में बदलने की कोशिश की है और हम अपने अपरिवर्तनीय संदर्भ प्रकारों को डिसेरिएलाइज़ करने में असमर्थ हैं: अपरिवर्तनीय गुणों वाला वर्ग (कोई सेटर्स नहीं) और सभी गुणों को सेट करने के लिए केवल एक कंस्ट्रक्टर। Json.net इन कक्षाओं को सही ढंग से संभालता है।
क्या यह System.Text.Json API की आवश्यकता का मुद्दा है या यह इसका समर्थन करने की योजना है?
आपकी प्रतिक्रियाओं के लिए धन्यवाद

@agjini देखें https://github.com/dotnet/corefx/issues/38569

धन्यवाद @खेलंग।
समर्थन वास्तव में योजनाबद्ध है लेकिन 3.0 रिलीज के लिए नहीं।
ऐसा लगता है कि डॉटनेट कोर 3 के साथ Json.net का उपयोग जारी रखना संभव है, लेकिन मुझे नहीं पता कि इसे कैसे करना है (पैकेज संदर्भ जोड़ना पर्याप्त नहीं है)। क्या ऐसा करने के लिए कोई रास्ता है?

@agjini :

C# services.AddControllers() .AddNewtonsoftJson()

दोस्तों, आपके सहयोग के लिए धन्यवाद।
यह काम करता है !
मैं माइग्रेशन गाइड से चूक गया हूँ जहाँ सब कुछ समझाया गया है:

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

IMO json.net आधा बेक किया हुआ है और इसे डिफ़ॉल्ट (यानी सिग्नलर के लिए) बना रहा है जो मौजूदा कोड को तोड़ता है।

दूसरी ओर, .NET कोर 2.2 से 3.0 में माइग्रेट करना एक प्रमुख संस्करण अपग्रेड है और भले ही .NET कोर टीम सिमेंटिक वर्जनिंग का सख्ती से पालन नहीं कर रही हो, मैं स्पष्ट परिवर्तनों के बिना एक संस्करण से दूसरे संस्करण में अपग्रेड करते समय चीजों को तोड़ने की अपेक्षा करता हूं। (जैसे पाइपलाइन में न्यूटनसॉफ्ट की लाइब्रेरी को स्पष्ट रूप से जोड़ना)

इसे बंद करना एक घोषणा है न कि कोई मुद्दा

हालांकि समुदाय में सुधार के खिलाफ बहुत सारी आवाजें हैं, एक नए उच्च-प्रदर्शन ढांचे के रूप में, खराब गति अस्वीकार्य है।

मुझे पता है कि यह पहले भी कहा जा चुका है, लेकिन मैं अपनी इच्छा भी जोड़ना चाहूंगा।

यह वास्तव में बहुत बढ़िया होगा यदि हमारे पास अपरिवर्तनीय वस्तुएं हों। मुझे पता है कि एमवीसी-पाइपलाइन में Json.NET जोड़कर यह संभव है लेकिन मेरे मामले में मेरे परीक्षण विफल हो रहे हैं क्योंकि मैं ReadAsAsync<> का उपयोग कर रहा हूं जिसे अब Microsoft.AspNet.WebApi.Client की सहकर्मी-निर्भरता में कहीं लागू किया गया है System.Text.Json पर निर्भर करता है

हम ग्राहकों को .NET मानक कक्षा पुस्तकालय प्रदान करते हैं ताकि वे हमारे पुस्तकालय का उपयोग किसी भी मंच पर काम करने के लिए कर सकें जो .NET मानक का समर्थन करता है। हमें अपनी कक्षा पुस्तकालय में System.Text.Json का उपयोग करने की आवश्यकता है। .NET मानक में System.Text.Json को सपोर्ट करने की क्या योजना होगी?

@ अलसामी

यह वास्तव में बहुत बढ़िया होगा यदि हमारे पास अपरिवर्तनीय वस्तुएं हों।

क्या आपको केवल दूसरों को इसे बदलने से रोकने की क्षमता की आवश्यकता है या क्या आपको नए उदाहरणों को बनाने की क्षमता की भी आवश्यकता है, जिन्हें स्मार्ट तरीके से बदला जा रहा है (जैसे अपरिवर्तनीय संग्रह और रोसलिन)? यदि आपको पहले वाले की आवश्यकता है, तो हमने आपको आगामी JsonDocument DOM API के साथ कवर किया है।

@mwoo-o

.NET मानक में System.Text.Json को सपोर्ट करने की क्या योजना होगी?

यह .NET मानक 2.0: System.Text.Json के लिए NuGet पैकेज के रूप में उपलब्ध है।

@terrajobst

धन्यवाद। यह System.Text.Json .NET मानक SDK में कब शामिल किया जाएगा?
क्या .NET मानक 3.0 (या कुछ अन्य बाद के रिलीज़ संस्करण) में System.Text.Json पैकेज शामिल होगा? क्या यह .NET Core 3.0 SDK प्रोडक्शन रिलीज़ में होगा?

@terrajobst

क्या Deserialize विधि को PipeReader के साथ काम करने की कोई योजना है? या पैच विधि जोड़ें जिसका उपयोग स्ट्रीमिंग परिदृश्यों में किया जा सकता है जहां हमारे पास डिसेरिएलाइज़ेशन शुरू करने पर सभी डेटा नहीं होते हैं।

यहाँ प्रस्तावित एपीआई का एक सरलीकृत संस्करण है:

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

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

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

    return model;
}

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

@terrajobst

दूसरों को इसे बदलने से रोकने की क्षमता

अभी यही है। वास्तव में सिर्फ 'डेटा-ट्रांसफर-ऑब्जेक्ट्स' के लिए है। बढ़िया खबर!

@mwoo-o

धन्यवाद। यह System.Text.Json .NET मानक SDK में कब शामिल किया जाएगा?
क्या .NET मानक 3.0 (या कुछ अन्य बाद के रिलीज़ संस्करण) में System.Text.Json पैकेज शामिल होगा? क्या यह .NET Core 3.0 SDK प्रोडक्शन रिलीज़ में होगा?

कोई .NET मानक SDK नहीं है। .NET मानक एक एपीआई सतह है, जो सभी समर्थित प्लेटफॉर्म पर उपलब्ध है। आप किसी भी एप्लिकेशन में System.Text.Json शिप कर सकते हैं जो .NET मानक द्वारा समर्थित समर्थित प्लेटफॉर्म को लक्षित करता है, .NET कार्यान्वयन समर्थन देखें ।

@त्सेंगएसआर

कोई .NET मानक SDK नहीं है। .NET मानक एक एपीआई सतह है, जो सभी समर्थित प्लेटफॉर्म पर उपलब्ध है।

खैर, एक प्रोजेक्ट प्रकार है जो आपको एपीआई का उपयोग करने की अनुमति देता है। मुझे लगता है कि @mwoo-o पूछ रहा है कि क्या हमारे पास System.Text.Json को .NET मानक में जोड़ने की योजना है। जवाब न है। ठीक है, अब हम इसे एक NuGet पैकेज के रूप में छोड़ने की योजना बना रहे हैं।

यह भयानक है।परियोजना में लागू करने के लिए बहुत कम कार्य।