Runtime: مستقبل JSON في .NET Core 3.0

تم إنشاؤها على ٢٩ أكتوبر ٢٠١٨  ·  193تعليقات  ·  مصدر: dotnet/runtime

أصبح JSON جزءًا أساسيًا من جميع تطبيقات .NET الحديثة تقريبًا وفي كثير من الحالات تجاوز استخدام XML. ومع ذلك ، لم يكن لدى .NET طريقة مضمنة (رائعة) للتعامل مع JSON. بدلاً من ذلك ، اعتمدنا على [Json.NET] الذي يستمر في خدمة النظام البيئي .NET بشكل جيد.

من الآن فصاعدًا ، نخطط لإجراء بعض التغييرات على دعم JSON:

  • نحن بحاجة إلى واجهات برمجة تطبيقات JSON عالية الأداء . نحتاج إلى مجموعة جديدة من واجهات برمجة تطبيقات JSON التي تم ضبطها بشكل كبير للأداء باستخدام Span<T> وتسمح بمعالجة UTF-8 مباشرةً دون الحاجة إلى التحويل إلى مثيلات UTF-16 string . كلا الجانبين مهمان لخادم الويب الخاص بنا Kestrel ، حيث يعد معدل النقل مطلبًا أساسيًا.

  • قم بإزالة التبعية من ASP.NET Core إلى Json.NET . اليوم ، تعتمد ASP.NET Core على Json.NET. بينما يوفر هذا تكاملًا وثيقًا بين ASP.NET Core و Json.NET ، إلا أنه يعني أيضًا أن مطوري التطبيقات لا يمكنهم اختيار مكتبة JSON التي يستخدمونها بحرية. يعد هذا أيضًا مشكلة لعملاء Json.NET حيث تم تحديد الإصدار بواسطة النظام الأساسي الأساسي. ومع ذلك ، يتم تحديث Json.NET بشكل متكرر وغالبًا ما يرغب مطورو التطبيقات - أو حتى يضطرون - إلى استخدام إصدار معين. وبالتالي ، نريد إزالة التبعية من ASP.NET Core 3.0 إلى Json.NET بحيث يمكن للعملاء اختيار الإصدار الذي يريدون استخدامه ، دون الخوف من احتمال تعطل النظام الأساسي الأساسي عن طريق الخطأ. بالإضافة إلى ذلك ، هذا يجعل من الممكن أيضًا توصيل مكتبة JSON مختلفة تمامًا.

  • توفير حزمة تكامل ASP.NET Core لـ Json.NET . أصبحت Json.NET أساسًا سكين الجيش السويسري لمعالجة JSON في .NET. يوفر العديد من الخيارات والتسهيلات التي تتيح للعملاء التعامل مع احتياجاتهم من JSON بسهولة. لا نريد المساومة على دعم Json.NET الذي يحصل عليه عملاء اليوم ، على سبيل المثال ، القدرة على تكوين تسلسل JSON عبر طريقة الامتداد AddJsonOptions . وبالتالي ، نريد توفير تكامل Json.NET كحزمة NuGet يمكن للمطورين تثبيتها اختياريًا حتى يحصلوا على جميع الأجراس والصفارات التي يحصلون عليها من Json.NET اليوم. يتمثل الجزء الآخر من عنصر العمل هذا في ضمان حصولنا على نقاط الامتداد الصحيحة بحيث يمكن للأطراف الأخرى توفير حزم تكامل مماثلة لمكتبة JSON التي يختارونها.

فيما يلي مزيد من التفاصيل حول هذه الخطة.

الحاجة إلى واجهات برمجة تطبيقات JSON عالية الأداء

تغيرت متطلبات حزمة .NET قليلاً منذ وصول .NET Core. من الناحية التاريخية ، تقدر .NET سهولة الاستخدام والراحة. باستخدام .NET Core ، أضفنا تركيزًا على الأداء وقمنا باستثمارات كبيرة لتلبية احتياجات الأداء العالي. وتعد التحسينات التي أجريناها في معيار TechEmpower الشهير دليلًا على ذلك.

باستخدام .NET Core 2.1 ، أضفنا عنصرًا أساسيًا جديدًا يسمى Span \ يسمح لنا بتمثيل الذاكرة والمصفوفات الأصلية بطريقة موحدة. مع هذا النوع ، أضفنا أيضًا مجموعة من واجهات برمجة التطبيقات للتحليل والتشفير التي تتميز بكفاءة أكبر في الذاكرة دون الحاجة إلى اللجوء إلى تعليمات برمجية غير آمنة.

جزء من عمل تقليل التخصيصات هو تجنب الاضطرار إلى تحويل ترميز حمولات UTF-8 إلى سلاسل UTF-16 ، لأسباب تتعلق بالتحليل فقط. حاليًا ، يتم تنفيذ Json.NET من خلال قراءة UTF-16. نحتاج إلى القدرة على قراءة (وكتابة) مستندات JSON مباشرة في UTF-8 لأن معظم بروتوكولات الشبكة (بما في ذلك HTTP) تستخدم UTF-8.

خلال .NET Core 2.1 ، تعلمنا أن تحديث واجهات برمجة التطبيقات الحالية لدينا لزيادة مستوى Span<T> له حدود. بينما قمنا بإضافة مجموعة من الأحمال الزائدة التي تقبل الامتدادات ، كان علينا أيضًا إنتاج واجهات برمجة تطبيقات جديدة تمامًا مصممة لتقليل التخصيصات والتعامل مع المخازن المؤقتة ، والتي كشفنا عنها في مساحات الأسماء System.Buffers . وباستخدام System.IO.Pipelines أضفنا أيضًا نموذج برمجة يتيح للمطورين مشاركة المخازن المؤقتة دون الحاجة إلى التعامل مع مشكلات العمر.

بناءً على هذه التجارب التي نؤمن بها لدعم تحليل JSON ، سنحتاج إلى الكشف عن مجموعة جديدة من JSON APIs المصممة خصيصًا لسيناريوهات الأداء العالي.

قد تتساءل لماذا لا يمكننا فقط تحديث Json.NET لتضمين دعم تحليل JSON باستخدام Span<T> ؟ حسنًا ، جيمس نيوتن كينج - مؤلف Json.NET - لديه ما يلي ليقوله عن ذلك:

تم إنشاء Json.NET منذ أكثر من 10 سنوات ، ومنذ ذلك الحين أضافت مجموعة واسعة من الميزات التي تهدف إلى مساعدة المطورين على العمل مع JSON في .NET. في ذلك الوقت ، أصبحت Json.NET أيضًا أكثر حزم NuGet اعتمادًا على وتنزيلها ، وهي مكتبة go-to لدعم JSON في .NET. لسوء الحظ ، فإن ثروة Json.NET من الميزات والشعبية تعمل ضد إجراء تغييرات كبيرة عليها. سيتطلب دعم التقنيات الجديدة مثل Span<T> تغييرات جذرية في المكتبة وسيؤدي إلى تعطيل التطبيقات والمكتبات الحالية التي تعتمد عليها.

من الآن فصاعدًا ، سيستمر العمل على Json.NET والاستثمار فيه ، سواء في معالجة المشكلات المعروفة اليوم أو دعم الأنظمة الأساسية الجديدة في المستقبل. كانت Json.NET موجودة دائمًا جنبًا إلى جنب مع مكتبات JSON الأخرى لـ .NET ، ولن يكون هناك ما يمنعك من استخدام واحدة أو أكثر معًا ، اعتمادًا على ما إذا كنت بحاجة إلى أداء JSON APIs الجديدة أو مجموعة الميزات الكبيرة من Json.NET.

انقل تكامل Json.NET إلى حزمة NuGet منفصلة

اليوم ، لا يمكنك استخدام ASP.NET Core بدون Json.NET لأنها تبعية لـ ASP.NET Core نفسها. على مر السنين ، تلقينا ملاحظات مفادها أن التبعية يمكن أن تتعارض مع المكتبات الأخرى التي لها اعتمادها الخاص على إصدار مختلف من Json.NET. في الماضي ، فكرنا في معالجة هذه المشكلة باستخدام نسخة خاصة من Json.NET في ASP.NET. ومع ذلك ، قد يؤدي ذلك إلى حدوث مشكلات عندما يرغب المطورون في تكوين Json.NET (على سبيل المثال ، للتحكم في كيفية تصرف المُسلسل عند تنسيق كائنات JSON).

من الآن فصاعدًا ، نود:

  1. استبدل الاستخدام الداخلي لـ Json.NET في ASP.NET Core بواجهات برمجة تطبيقات JSON الجديدة التي يوفرها النظام الأساسي.

  2. قم بتحويل الاستخدام العام لـ Json.NET إلى حزمة تكامل اختيارية يمكن الحصول عليها من NuGet.

لذلك سيستمر دعم التكامل الحالي بين ASP.NET Core و Json.NET ، لكنه سينتقل من النظام الأساسي إلى حزمة منفصلة. ومع ذلك ، نظرًا لأنه تم تصميم التكامل بعد ذلك ليكون أعلى النظام الأساسي ، فإنه سيسمح أيضًا للعملاء بتحديث Json.NET إلى الإصدارات الأحدث.

علاوة على ذلك ، يمكن للعملاء الذين يحتاجون إلى مزيد من الأداء أيضًا اختيار استخدام واجهات برمجة تطبيقات JSON الجديدة ، على حساب مجموعة الميزات الغنية التي توفرها Json.NET.

area-Meta

التعليق الأكثر فائدة

بافتراض أنه سيتم استخدام هذا المحلل اللغوي الجديد لجميع عناصر JSON المضمنة مثل appSettings.json ، هل يمكنني تقديم طلب مبكر لدعم التعليقات؟

شكرا.

ال 193 كومينتر

هذا عظيم. أنا جميعًا من أجل تحليل json بشكل أسرع وأقل تخصيصًا.

هل سيكون هناك نقاش حول الميزات من json.net التي ستدعمها json apis الجديدة؟ إذا كان هناك ، أعتقد أن السمتين الرئيسيتين اللتين تتبادران إلى الذهن هما إعادة تسمية / غلاف الخصائص وتجاهل الخصائص الفارغة.

هل سيكون هناك نقاش حول الميزات من json.net التي ستدعمها json apis الجديدة؟

نعم فعلا. لقد قمنا ببعض التفكير المبكر بأننا سنهاجر إلى CoreFx. ستكون ميزة تم تصميمها وبناؤها في العراء كالمعتاد. بالإضافة إلى ذلك ، وصلت إلى مؤلفي العديد من مكتبات JSON الشهيرة ودعوتهم لمراجعة المسودات المبكرة لهذا الإعلان. آمل أن نتمكن من العمل معًا لإنشاء مكون JSON قوي للنظام الأساسي مع الحفاظ على النظام البيئي فوقه (مثل ASP.NET Core) قابلاً للتوصيل للسماح للآخرين. في نهاية المطاف، فإن مختلف المستهلكين لديهم أهداف مختلفة، وتكون قادرة على سد العجز في وسيلة المكتبة المختلفة التي يمكن الحصول على أقصى قدر من المرونة في اختيار المكون الذي لديه أفضل من حيث التكلفة / العائد للتطبيق.

ياterrajobst. هل سيظهر JSON الجديد كسطح لواجهة برمجة تطبيقات قياسية أم أنه مدمج في Core في الوقت الحالي؟

ياterrajobst. هل سيظهر JSON الجديد كسطح لواجهة برمجة تطبيقات قياسية أم أنه مدمج في Core في الوقت الحالي؟

نعم ، السؤال هو فقط أي قطار الإطلاق يمكنه اللحاق به. 2.1 قد يكون مبكرًا جدًا.

لذلك من المخطط أن تكون بتات تحليل JSON المخبوزة في إطار العمل متاحة عندما ينتقل الإصدار 3.0 إلى RTM أو يكتمل فقط تكامل Apis في ASP.NET Core (بتطبيق واحد فقط - JSON.NET) والذي سيكون قابلاً للتبديل في تاريخ لاحق؟

خطة 3.0 هي كما يلي:

  1. واجهات برمجة تطبيقات JSON مدمجة عالية الأداء. قارئ / كاتب ذو مستوى منخفض ، قارئ / كاتب على أساس Stream ، ومسلسل.
  2. ASP.NET Core قابل للتوصيل إلى مكون JSON.

هناك سؤال مفتوح حول ما ستستخدمه قوالب ASP.NET في 3.0. اعتمادًا على الدقة التي يمكننا توفيرها بحلول 3.0 ، قد نجعلهم يسحبون في حزمة تكامل Json.NET. ومع ذلك ، فإن الهدف هو تقديم قدر كافٍ من الدقة والتكافؤ للاعتماد فقط على العناصر المضمنة بشكل افتراضي.

شكرًا - هذا يساعد على توضيح الأمور. 👍

وبعض الأسئلة الإضافية!

إذا تم استخدام حزمة تكامل ، فهل سيتم استخدامها في جميع أنحاء خط أنابيب ASP.NET Core بأكمله أم في بعض الأماكن فقط؟
أفترض أن Kestrel سيستخدم دائمًا القراء / الكتاب الداخليين.

هل ستكون بيئة عمل Api:

  • قم بتوفير تكامل فقط عندما تريد تحسين مجموعة الميزات المضمنة.
  • قم بتوفير حزمة تكامل دائمًا ولكن سيتم دمج حزمة واحدة ، مما يؤدي إلى دمج القارئ / الكتاب منخفض المستوى في وظائف ذات مستوى أعلى.

بافتراض أنه سيتم استخدام هذا المحلل اللغوي الجديد لجميع عناصر JSON المضمنة مثل appSettings.json ، هل يمكنني تقديم طلب مبكر لدعم التعليقات؟

شكرا.

هذه أخبار رائعة! سؤال سريع: ما هي الحزم التي ستعتمد عليها هذه المكتبة؟

لماذا نعيد ابتكار عجلة تم اختبارها من قبل عملاء الإنتاج؟ إذا كانت هناك مشكلة في Json.Net ، فما عليك سوى إرسال PR لأنه مفتوح المصدر.

أفترض أن مشكلة Json.NET هي أنها ليست مملوكة لشركة Microsoft ، لذلك يجب استبدالها. أوه ولكن هناك بالفعل واحد في System.Runtime.Serialization يسمى DataContractJsonSerializer. هل يمكنك استخدام ذلك ، أم أنه من الممتع جدًا ترميز واجهات برمجة التطبيقات الجديدة ، DIY ، بحيث لا يمكن تجنبها؟

السبب في أنني لست سعيدًا جدًا بهذا هو أن Json.Net يدعم بالفعل حالات الحافة مثل F # Discriminated Unions. ليس جيدًا بشكل خاص ، ولكن على مستوى يمكن للمطورين التعايش معه. بدلاً من ذلك ، عادةً ما تنسى أي واجهة برمجة تطبيقات جديدة أي شيء آخر غير حالة استخدام موقع ويب ASP.NET.

markrendle هناك إعداد تمكين في JsonReader (العمل قيد التقدم) للسماح بالتعليقات. من المحتمل أن يقوم نظام التكوين بتمكين هذا الإعداد افتراضيًا.

Thorium هل قرأت بالفعل OP؟ إنه يشرح سبب عدم استخدام JSON.NET ، وأن JSON.NET سيستمر في الدعم رسميًا بحزمة الوظيفة الإضافية.

تضمين التغريدة

Thorium Json.NET لن تختفي. أنت لا تخسر أي شيء. هذا خيار آخر لسيناريوهات بسيطة وعالية الأداء.

Thorium Json.NET لن تختفي. أنت لا تخسر أي شيء. هذا خيار آخر لسيناريوهات بسيطة وعالية الأداء.

كيف سيتم إنشاء Json ليكون متوافقًا مع الإصدارات السابقة؟

على سبيل المثال ، أنا أستخدم SignalR الذي يستخدم Json.NET في الخلفية. الآن ، هل ستتسلسل نقابات F # التي تم تمييزها إلى هياكل مماثلة حتى لا أواجه مشكلات مع خدمة Azure Signalr Service الجديدة (لوحة معززة) التي تطرح استثناءات وقت التشغيل بسبب تسلسل الهياكل بشكل مختلف عن مكتبة SignalR الحالية لخادمي؟

آمل أن يلتقط الآخرون واجهات برمجة التطبيقات الجديدة بسرعة. بالنظر إليك ، AzureCosmosDB ؛-)

هل تخطط لتضمين فصل دراسي مثل JObject ودعم ديناميكي أم أن هذا خارج نطاق هذه الميزة؟

أوصي بإلقاء نظرة في أحد هذه libs:

قد تكون هذه طريقة جيدة للحصول على الإلهام.

هل سيتم استخدام هذا القارئ / الكاتب الجديد في DataContractJsonSerializer داخليًا؟

لقد وصلت إلى مؤلفي العديد من مكتبات JSON الشهيرة ودعوتهم لمراجعة المسودات المبكرة لهذا الإعلان. آمل أن نتمكن من العمل معًا لإنشاء مكون JSON قوي للنظام الأساسي مع الحفاظ على النظام البيئي فوقه (مثل ASP.NET Core) قابلاً للتوصيل للسماح للآخرين.

هل هناك سبب وراء ثاني أشهر مكتبة JSON بعد JSON.NET - ServiceStack ، وهو النص الذي تمت إعادة بنائه بالفعل واجهات برمجة التطبيقات تم استبعاده؟ ServiceStack.Text المتسلسلات هي ما يتم استخدامه لتشغيل ServiceStack الذي يعد أحد أشهر "إطار عمل ويب متوافق مع البديل .NET Core" والذي يدعم التشغيل على المزيد من الأنظمة الأساسية في .NET . لدي فضول بشأن أي "نظام بيئي" تشير إليه وآمل في "العمل معًا" هنا؟ من الواضح أنني سأكون مهتمًا بمدى توافق واجهات برمجة التطبيقات "القابلة للتوصيل" هذه أو ما إذا كان هذا ينتهي به الأمر إلى أن يكون مجالًا آخر حيث يؤدي اعتماد مكتبات MS الجديدة وتكاملها إلى قتل النظام البيئي الذي يحل محله.

قد يكون من المفيد مراجعة الأداء العالي المرخص من معهد ماساتشوستس للتكنولوجيا https://github.com/neuecc/Utf8Json

هذا بالتأكيد ما نحتاجه ... اقتراحي لاسم الفصل الرئيسي ، فقط استخدم " Json ".

terrajobst كنت أتساءل متى سيحدث هذا ...

كنت أتساءل دائمًا عن سبب إضافة JSON.Net باعتباره تبعية مباشرة بدلاً من كونه تجريدًا (حتى مع اعتباره حزمة JSON بحكم الأمر الواقع لنظام .Net البيئي).

ومع ذلك ، أعتقد أن إضافة فكرة مجردة لـ JSON-only هي بطريقة ما إطلاق نار على قدميك. أعتقد أن تجريد _serializer_ مثل ما لدينا في Orleans IExternalSerializer في شكل Microsoft.Extensions.Serialization أو شيء ما سيكون أكثر فاعلية ...

هل هناك أي سبب محدد لكون جعل Make هو JSON فقط؟ أرى حالات أخرى حيث يمكن للأشخاص توصيل أنواع أخرى من المسلسلات ...

galvesribeiro شيء مثل IOutputFormatter / IInputFormatter ؟

@ yaakov-h لم يكن على علم بهؤلاء ... أين هم؟

حسناً ... من المنطقي الآن. إذن ، أين تأتي هذه الأفكار التجريدية الجديدة فقط في JSON؟

قرار بدء هذا التعهد هو أيضًا شهادة على عدم كفاءة System.String (UTF-16 String).
أعتقد أن خطافات JSON الجديدة التي ستجرد كل معالجة json بين asp.net ومكتبة json ستبدو أفضل بشكل ملحوظ إذا تعاملت مع مهمة إنشاء BaseType سلسلة utf-8 أولاً.
-> ربما تقوم بإنشاء System.Utf8String

نعم ... أتذكر migueldeicaza عندما قال منذ فترة إنه utf8 سلاسل 😄

@ jges42galvesribeiro اقتراح لإضافة Utf8String هو https://github.com/dotnet/corefx/issues/30503. يبدو أنه مخطط أيضًا لـ .Net Core 3.0.

هل ستحتوي واجهات برمجة تطبيقات JSON الجديدة على مسارات رمز مخصصة لكل من Utf8String و char / string ، أم أن التحسين سيتضمن قلب الوضع الراهن ، بحيث يكون كل شيء غير UTF-8 بدلا من ذلك؟ (وهذا لا يشمل بالضرورة تكلفة ضخمة منذ ما يقرب من شيء هو string الصورة UCS-2 الأم UTF-16 و ما زال لتكييفها / استأثرت، أنا مجرد محاولة للحصول على فكرة عن سطح واجهة برمجة التطبيقات. يعد القيام بذلك لجعل Kestrel أكثر كفاءة أمرًا منطقيًا ؛ وآمل فقط أن يأخذ التصميم في الاعتبار عملاء أكثر من Kestrel.)

تضمين التغريدة
في الواقع أعتقد أنك تثير نقطة جيدة. أعتقد أن إنشاء إطار عمل تسلسلي فعال و Json Decoder / Encoder فعال هما نوعان من المشاكل. أعلم أن هناك بعض الطرق لوضع علامة على بنية كـ Serializable ولكني لم أرها تستخدم في أي Json Serialization.

مشروع Serde من Rust لديه في الواقع مفهوم جيد عن طريق تقسيم المشكلة إلى مشكلتين:

  1. التسلسل / إلغاء التسلسل (السمات المشابهة للواجهات في C #) مما يعني أن أي نوع يرث من هذه الواجهة يمكن تسلسله / إلغاء تسلسله
  2. Serializer / Deserializer هو تطبيق خاص بالتنسيق.

يمكن أن يقوم النوع إما بتنفيذ Serialize / Deserialize يدويًا أو بواسطة ماكرو (والذي يمكن اعتباره شكلاً من أشكال المكون الإضافي للمترجم) والذي يولد الكود المطلوب لتنفيذ هذه السمات. إذا كان النوع يحتوي على نوع فرعي لا يطبق تلك السمات ، فإنه سيحذر حتى في وقت الترجمة. إنه مفهوم جميل بشكل عام لأنه يعني أنه يمكنك فقط كتابة بعض كائنات البيانات وتسلسلها لأي تنسيق مدعوم. كتابة تنسيق أسهل بكثير بهذه الطريقة.

لا أعتقد أن جميع طرق Serde ستعمل مع C # لأنها لا تقدم بالفعل أي سمات محددة من النوع والتي قد تكون مهمة لبعض هياكل البيانات. لذلك يجب أن يكون هناك بعض العمل المنجز لهذا الغرض. يعتبر أيضًا اعتبار تجميع AoT مهمًا جدًا لبعض المشاريع (WASM) كما يجب أن يعمل بشكل جيد معه.

هنا رابط إلى مستندات Serde لتوضيح الأمر أكثر (انقر فوق السمات الأربع السفلية لرؤية المفهوم):
https://docs.serde.rs

mythz ترخيص ServiceStack.Text هو AGPL مع بعض استثناءات البرمجيات الحرة والمفتوحة المصدر - ربما يمنع الأشخاص من استخدامه في البرامج الاحتكارية. أعتقد أيضًا أن الأمر يتطلب تصريحًا قانونيًا لموظفي Microsoft حتى لمسها ، وقد يُمنع أي موظف نظر إلى المصدر من العمل في أي مكتبة JSON أخرى أو تقنية ذات صلة.

@ poizan42 ServiceStack.Text مرخص مزدوج مع كل من OSS / تراخيص تجارية مجانية للاستخدام في كل من OSS والمشاريع التجارية المغلقة المصدر. لكن تراخيص الكود المصدري ليست ذات صلة حيث تعمل MS على تطوير التنفيذ الخاص بها.

كان التأكيد على أن MS كانت تتعاون مع "النظام البيئي" لتطوير واجهات برمجة تطبيقات JSON المتسلسلة "القابلة للتوصيل" - إذا كان ServiceStack الذي كان قيد التطوير النشط منذ ما يقرب من عقد من الزمان والذي يعد أحد مجموعات برامج .NET المستقلة القليلة التي تمكنت من الحفاظ عليها يمتلك مجتمعًا صحيًا مستقلًا خارج MS خلال حياته ، والذي يحافظ على ثاني أشهر برنامج تسلسلي JSON بعد JSON.NET وما يبدو أنه ثاني أكثر إطار عمل ويب تم تطويره بشكل نشط (خارج MS) ، والذي يعمل على منصات أكثر من أي MS لا يعتبر إطار عمل الويب جزءًا من "النظام البيئي" الذي يتأثر بشكل أساسي بهذه التغييرات ، فأنا أشعر بالفضول بشأن "النظام البيئي" الذي يشيرون إليه ولماذا يتم استبعادنا وعدد الأشخاص الآخرين الذين يتم استبعادهم لأنهم لا تعتبر جزءًا من "النظام البيئي".

أنا لا أفهم كل هذا الاستياء. أجبرك Asp.net على استخدام إصدار محدد من json.net. إنهم يغيرونها حتى تتمكن من اختيار محلل JSON الذي تريده (أو مزجها) ، وهناك واحد افتراضي OOB. يجب أن يكون ServiceStack سعيدًا بشأن هذا التغيير وأن يراقب هذا التطور ويقدم تعليقات عليه ، بدلاً من مجرد التذمر حول كيفية التغاضي عنه ، والذي نادرًا ما يكون وسيلة فعالة لتعزيز روح المجتمع الجيدة. أنا شخصياً أعرف العديد من أعضاء فريق .net وأنا واثق من أنهم لم يقصدوا أي حقد. إنهم جميعًا من كبار المؤيدين لبرمجيات المصدر المفتوح والعمل المجتمعي.
شخصيًا ، أي ترخيص مشتق من GPL سيكون بمثابة رفض تلقائي كبير بالنسبة لي. Apache أو MIT لي ولعملائي أو سنمضي قدمًا. لا تراخيص مزدوجة غامضة.

أجبرك Asp.net على استخدام إصدار معين من json.net

لا. كيف ذلك؟

أنا لا أفهم كل هذا الاستياء.

معار!

أنا شخصياً سعيد لأننا سنكون قادرين أخيرًا على استخدام المسلسل الذي نختاره دون الحاجة إلى تنزيل JSON.Net فقط لعدم استخدامه ، ولكن ما زلت بحاجة لشحنه لأن ASP.Net لديه مرجع صارم للمكتبة.

(المكونات الوقحة: https://github.com/gregsdennis/Manatee.Json)

تضمين التغريدة

أنا لا أفهم كل هذا الاستياء.

لأنك إما لم تقرأ أو تفهم تعليقاتي. حاول الرد مباشرة على تعليقاتي (على سبيل المثال ، استخدم ميزة الاقتباس) بدلاً من تكوين السرد الخاص بك.

إنهم يغيرونها حتى تتمكن من اختيار محلل JSON الذي تريده (أو مزجها)

لذا ، مثل "المزيج" السحري ، سيختارون تلقائيًا أفضل واجهة برمجة تطبيقات وخيارات قابلية للتوصيل والتي سيكون بمقدور متسلسل .NET الحاليين توصيلها مباشرة وإخراجها ودمجها في خيارات التخصيص الداخلية الخاصة بهم مع كون تنسيق الأسلاك هو بالضبط نفس الشيء وكل شيء سيعمل فقط عبر جميع المسلسلات؟ في هذه الحالة ، أنت على حق ، لا يلزم إجراء اختبار تعاون أو تكامل قبل أن يتم ترسيخ واجهات برمجة التطبيقات. أو ربما تكون تطبيقات Serializer أكثر دقة مع اختلافات وآراء مختلفة وكل شيء لن يعمل فقط ، ولن يتم تنفيذ جميع خيارات التخصيص تمامًا ، ولن يكون تنسيق الأسلاك هو نفسه ولن يكون من الممكن تحقيقه توافق مثالي بين التطبيقات المختلفة. تُحدث "القابلية للتوصيل" التي تتجاهلها فرقًا كبيرًا يمكن أن تحدد مقدار إعادة الكتابة التي سيتعين علينا القيام بها وما إذا كان من الممكن دعم التنفيذ الحالي والجديد أم لا.

يجب أن يكون ServiceStack سعيدًا بهذا التغيير وأن يراقب هذا التطور ويقدم ملاحظات عليه ،

وهو الأمر الذي لم نحصل على أي فرصة للقيام به (أو ما زلنا نعرف كيف نفعل) ، ولكن شكرًا لإخباري بما يجب أن أشعر به. أفضل تقييم وظائف المكتبة وقابليتها للتشغيل البيني وتوافقها قبل التمكن من تقييم قوة كل مكتبة. ربما سيكون الأمر رائعًا وسيكون من السهل دعم كلا التطبيقين ، ولكن من تجربة التشغيل البيني مع تطبيقات المسلسل المختلفة محفوف بعدم التوافق وحالات الزاوية والاعتماد على تطبيقات وميزات مختلفة خاصة بالتسلسل. توقعي هو أن التشغيل المتداخل بين JSON.NET والضمانة الافتراضية سيكون رائعًا نظرًا لأن هذا هو هدف التصميم الخاص بهم وما يتم اختباره ضده ولكن المتسلسلات الأخرى لن تكون محظوظة.

بدلاً من مجرد التذمر حول كيفية التغاضي عنه ، والذي نادرًا ما يكون وسيلة فعالة لتعزيز روح المجتمع الجيدة.

أتحدى تأكيداتهم بأنهم قد طوروا هذا بالتعاون مع "النظام البيئي" ، فإن .NET لها تاريخ في قتل النظام البيئي الحالي في كل مرة يقومون فيها بتجميع مكتبة "افتراضية" ، والتي أتوقع أيضًا حدوثها هنا (أنا أكافح من أجل تذكر وقت ساعد فيه تجميع الافتراضي النظام البيئي على الإطلاق). ولكن بغض النظر ، نحن بحاجة إلى تطوير تكامل سلس مع كل ما يتم إصداره والذي أود أن أكون قادرًا على الوصول إليه وإدخاله قبل تجميد واجهات برمجة التطبيقات. ولكن لا بأس بذلك ، لا أتوقع منك أن تهتم بكيفية تأثيره على الأطر / المكتبات الحالية التي تحتاج إلى دعم عمليات التنفيذ الحالية والمستقبلية ، فمن المحتمل أنك قلق فقط إذا ظل JSON.NET مدعومًا أم لا لأن هذا كل ما يؤثر عليك ، ولكن حاول التمسك بافتراضاتك وإخبارنا بما يجب أن نشعر به حيال استيعاب التغييرات التخريبية مثل هذا.

أنا أجد صعوبة في تذكر الوقت الذي ساعدت فيه تجميع التعثر على النظام البيئي

اووه تعال!

(في البقية أنا أتفق في الغالب مع مشاعرك)

mythz أنا مندهش من أن هذا يسبب أي مشاكل لأننا اليوم نجمع مكتبة JSON لجهة خارجية أخرى في إطار العمل. لا يوجد سوى عدد قليل من الأماكن التي نخبز فيها JSON ومعظمها يحتوي على نموذج مزود يمكن للمستخدمين استبداله بشكل معقول (مثل مُنسِّقات MVC).

توقعي هو أن التشغيل المتداخل بين JSON.NET والضمانة الافتراضية سيكون رائعًا نظرًا لأن هذا هو هدف التصميم الخاص بهم وما يتم اختباره ضده ولكن المتسلسلات الأخرى لن تكون محظوظة.

يمكنني أن أخبرك بالفعل أن ما سنقوم بشحنه لن يدعم سلسلة الميزات التي يدعمها JSON.NET. لذلك هذا غير صحيح بالفعل وفي الواقع ، نتوقع أن يكون أقل قدرة في بعض الحالات (بسبب أسباب الأداء والنطاق).

القابلية للتوصيل موجودة بالفعل اليوم ولدينا تطبيقات JSON.NET الافتراضية في كل مكان. هذا مجرد تغيير هذا الإعداد الافتراضي ليكون برنامج JSON التسلسلي الجديد بدلاً من ذلك ...

تضمين التغريدة

لا يمكنني حقاً تذكر أي شيء ، متى استفاد تضمين أو اعتماد تطبيق افتراضي في إطار العمل الأساسي (أو المشاريع) على النظام البيئي المحيط الحالي؟ في كل مرة رأيتها مجمعة مثل NuGet و MVC و ORMs واختبار الوحدة وواجهة برمجة تطبيقات الويب وما إلى ذلك ، كان لها تأثير ضار فقط ، حيث تأخذ الأكسجين والتحفيز بشكل فعال للمنافسة داخل تلك المساحة.

هناك أوقات مثل فيها فشل المكتبات المتنافسة مثل ASP.NET Ajax في التنافس حيث انتهى بهم الأمر بالتخلي عنها وتبني jQuery ، لكنني لا أتذكر الوقت الذي ساعدت فيه على الإطلاق؟ ملاحظة: هذه مجرد ملاحظتي من متابعة NET عن كثب بعد عدة سنوات ، ربما هناك أمثلة وسأكون فضوليًا لمعرفة بعضها؟ ولكن من وجهة نظري ، فإن تأثيرات الإعدادات الافتراضية لـ MS لها تأثير ضار على النظام البيئي الحالي للوظائف التي تحل محلها.

لا تعد فوائد

لكن دعونا لا نغرق ونلتزم بالموضوع. هتافات!

davidfowl هذا مجرد تغيير هذا

أود أن أقترح عدم وجود برنامج تسلسلي افتراضي وأطلب تنزيل أحد التطبيقات. إذا كان يجب أن يكون هناك افتراضي ، فهل سيتم وضعه في إطار العمل أو في مكتبة منفصلة (كما هو الحال حاليًا)؟

أود أن أقترح عدم وجود برنامج تسلسلي افتراضي وأطلب تنزيل أحد التطبيقات. إذا كان يجب أن يكون هناك افتراضي ، فهل سيتم وضعه في إطار العمل أو في مكتبة منفصلة (كما هو الحال حاليًا)؟

هذا غير معقول لأن التجربة ستكون دون المستوى. كل منصة حديثة بها JSON مدمجة.

davidfowl لا يسبب مشاكل الآن لأنه لم يتم إصداره ، لكننا ما زلنا بحاجة إلى تقييم الاضطراب ونطاق العمل الذي سيتسبب فيه. ما مقدار الجهد الذي سيتطلبه لدعمه بسلاسة ، وهل سنتمكن من تطبيق التخصيصات على الضمانات الجديدة لدعم سلوكنا الحالي ، وهل سنتمكن من دعم نموذج التخصيص الجديد وواجهات برمجة التطبيقات ، وهل يمكننا تخصيص المسلسل الخاص بنا لدعم التكوين الافتراضي / التنسيق السلكي سيكون بإمكان واجهات برمجة التطبيقات الجديدة دعم كلاً من .NET Core و .NET Framework - في حين أنه من الواضح أن ASP.NET Core 3 سيتخلى عن .NET Framework ، ليس من الواضح ما إذا كانت واجهات برمجة التطبيقات الجديدة ستستخدم. NET Core فقط هي الأنواع التي تمنعنا من الاستمرار في دعم كلاً من .NET Core و .NET Framework.

يمكنني أن أخبرك بالفعل أن ما سنقوم بشحنه لن يدعم سلسلة الميزات التي يدعمها JSON.NET. لذلك هذا غير صحيح بالفعل وفي الواقع ، نتوقع أن يكون أقل قدرة في بعض الحالات (بسبب أسباب الأداء والنطاق).

أنا أتوقع فقط أنه يدعم مجموعة فرعية من ميزات JSON.NET ، على سبيل المثال ، هل يدعم JSON.NET تنسيق الأسلاك الافتراضي؟ (أفترض نعم). هل ستتبنى الضمنية الجديدة تنسيقات التسلسل JSON.NET حيثما أمكن ذلك (بافتراض نعم أيضًا).

ما مقدار الجهد الذي سيتطلبه لدعمه بسلاسة ، وهل سنتمكن من تطبيق التخصيصات على الضمانات الجديدة لدعم سلوكنا الحالي ، وسنكون قادرين على دعم نموذج التخصيص الجديد وواجهات برمجة التطبيقات ، هل يمكننا تخصيص المسلسل الخاص بنا لدعم التكوين الافتراضي / التنسيق السلكي سيكون بإمكان واجهات برمجة التطبيقات الجديدة دعم كل من .NET Core و .NET Framework.

mythz أنا لا

mythz ، فإن القلق الحقيقي الوحيد الذي أراه لـ servicestack سيكون إذا لم يتم دعم واجهة برمجة التطبيقات الجديدة هذه على. اعتمادًا على تلك المكتبات لن تكون متاحة في إطار .net الكامل. هل هذا قلقك؟ أنا أسأل لأن قلقك كمثال ملموس غير واضح.

هذا أيضًا اقتراح في مرحلته الأولية والهدف الذي يريد تحقيقه يبدو واعدًا جدًا. النقد البناء دائمًا ما يكون جيدًا لأي مشروع من مشاريع أنظمة التشغيل.

لا تعد فوائد

من خلال النظام الإيكولوجي ، أشير إلى النظام البيئي / المجتمعات المحيطة بمكتبة .NET (والتي يُفترض أنها أيضًا "النظام البيئي" في OP الذي يشير إليه) والتي تحل محل ما كنت أزعم أن مستخدمي .NET يستفيدون أيضًا من نظام بيئي سليم مع مجموعة متنوعة من الخيارات والمزيد من المنافسة (كما هي سمة النظم البيئية الأكثر صحة مثل Python و Java و Node و Ruby و PHP وما إلى ذلك).

EF هي أفضل ORM في عالم .NET

بعد فترة وجيزة من إطلاق EF ، سرعان ما استحوذت على غالبية حصة السوق في ORM بينما كانت أبطأ بأكثر من 6 مرات من NHibernate بينما يمكن القول إنها تدعم ميزات أقل ، مقتطفات من مقابلة InfoQ لعام 2012 :

أحدثت محاولتهم الأخيرة في طبقة الوصول إلى بيانات ORM في Entity Framework تأثيرًا سلبيًا على مجتمع ORM NHibernate السابق البارز أيضًا. على الرغم من كونها أبطأ عدة مرات من أي ORM مفتوح المصدر .

ضع في اعتبارك أن هذا كان سابقًا لـ NET Core حيث أصبح الأداء الآن أولوية قصوى ، ولكنه مثال تاريخي للتأثير الضار الذي تحدثه الإعدادات الافتراضية لـ MS على النظم البيئية / المجتمعات الحالية. IMO من المقبول إلى حد كبير ما يحدث للمجتمعات الحالية عندما تقدم MS الإعدادات الافتراضية وهذا هو السبب في وجود رد مؤخرًا للعودة من عمليات الشحن الافتراضية التي تتنافس مع IdentityServer و AutoMapper.

و MSTest كان أفضل من NUnit في اليوم.

IMO لم يكن أبدًا (وكان دعم R # لـ NUnit دائمًا AFAICR ممتازًا) وحقيقة أننا لم نتمكن من تشغيله عبر النظام الأساسي على Mono تعني أن المكتبات التي تدعم الأنظمة الأساسية المشتركة على Mono (قبل .NET Core) لا يمكن استخدامها هو - هي.

لكن دعونا لا نغرق ونلتزم بالموضوع. هتافات!

كما أنني لا أرغب في اختطاف هذا الموضوع أيضًا ، لكنني بحاجة إلى توضيح سبب اختلافي مع نقاطك.

فيما يتعلق بهذا ، فإن السبب الرئيسي الآن لاستخدام مُسلسل مختلف عن JSON.NET هو الأداء ونظرًا لسبب هذا المسلسل الافتراضي الجديد هو الأداء. نظرًا لأن معظم الأشخاص يستخدمون الإعدادات الافتراضية فقط ، فأنا أتوقع أن يكون لهذا التأثير الأكثر وضوحًا على مشاركة JSON.NET بينما السبب الأساسي لاستخدام مُسلسل بديل لم يعد موجودًا مع هذا الضمني الأسرع. لذلك أرى أيضًا أن هذا له تأثير ضار على النظام البيئي (المكتبة) الحالي. IMO هو نظام بيئي أضعف من JSON libs هو صافي سلبي لـ .NET (ليس شيئًا سيرى معظم المستهلكين أنهم سيستخدمون الإعدادات الافتراضية فقط وينسون الخيارات الأخرى) ، لكن هذا ليس شاغلي الرئيسي.

تضمين التغريدة

على الرغم من ذلك ، كنت أفضل أن يكون هذا موجودًا منذ 8 سنوات كسبب رئيسي لتطوير ServiceStack. كان النص لأن برامج .NET Framework JSON المتسلسلة كانت بطيئة للغاية. ولكن بعد كل هذا الوقت ، تم تمديد SS.Text بعدد من الميزات عبر جميع مكتباتنا ، على سبيل المثال التخصيصات لدعم لغات مختلفة يدعم ServiceStack ، وخيارات تخصيص JSON المختلفة قوالب ServiceStack ، ودعم blob من النوع المركب JSON في ServiceStack .Redis إلخ.

لذا فأنا الآن أركز على تقييم التأثير الذي سيحدث ، وكيف ستبدو واجهة برمجة التطبيقات الجديدة وخيارات التوصيل ، هل يمكننا تعديل الميزات الحالية عليها ، وهل سنتمكن من اعتمادها كمسلسل JSON في تطبيقات SS .NET الأساسية (ما الذي سينكسر) ، هل سيتمكن ServiceStack. النص من دعم واجهة برمجة التطبيقات الجديدة ، هل سنتمكن من دعم .NET v4.5 ، هل سيكون قادرًا على تخصيصه لدعم التنسيقات السلكية لعمليات النشر الحالية ، إلخ. ليس لدي أي فكرة عن أي تأثير على أي من هذا أو ما هي الإستراتيجية التي ستمضي قدمًا حيث لم تتح لي الفرصة لاستخدام أو رؤية أي شيء حتى الآن. سأعرف المزيد من الإجابات عندما تسنح لي الفرصة لاستخدامها ، ومن الواضح أنني أرغب في الحصول على فرصة لاختبار التكامل وتقديم الملاحظات واقتراح التغييرات قبل تجميد واجهات برمجة التطبيقات.

تضمين التغريدة

هل هناك سبب لاستبعاد ثاني مكتبة JSON الأكثر شيوعًا بعد JSON.NET - ServiceStack ، النص الذي تم إعادة بنائه بالفعل

لم يكن الإغفال مقصودًا. لقد بحثنا بنشاط وعملنا مع مؤلفي مكتبة JSON كجزء من مستودع CoreFxLab وبدأ أحد مصطلحات البحث الأساسية مثل "json" على NuGet . يبدو أن مكتبتك ببساطة لم تظهر. أتفهم أن هذا قد يكون محبطًا أو مقلقًا لك ولكن حاول فهم الموقف من نهايتنا: لا يمكن توقع أن يعرف فريقنا كل مكتبة تحت الشمس. هذا الإعلان هو جزء من نموذج التطوير المفتوح لدينا لإشراك المجتمع بأكمله. السبب الوحيد الذي يجعلنا نميل إلى الوصول إلى مجموعات أصغر أولاً هو التأكد من أن خططنا ورسائلنا تتمتع بمستوى معقول من التفكير والجودة قبل مشاركتها مع العالم. لا شيء نهائي بعد. نحن نبحث بنشاط عن ملاحظات إضافية.

لدي فضول بشأن أي "نظام بيئي" تشير إليه وآمل في "العمل معًا" هنا؟

النظام البيئي .NET وخاصة الأطراف المهتمة بمعالجة JSON.

من الواضح أنني سأكون مهتمًا بمدى توافق واجهات برمجة التطبيقات "القابلة للتوصيل" هذه أو ما إذا كان هذا ينتهي به الأمر إلى أن يكون مجالًا آخر حيث يؤدي اعتماد مكتبات MS الجديدة وتكاملها إلى قتل النظام البيئي الذي يحل محله.

الغرض من نقاط امتداد ASP.NET Core المخطط لها هو تمكين العملاء من استبدال مكون JSON المدمج بأي مكتبة JSON يريدونها. بالطبع ، يتم شحن ASP.NET دائمًا مع "البطاريات المضمنة" ، أي تجربة افتراضية معقولة. في الماضي كان هذا هو Json.NET والمضي قدمًا هو أحد مكونات النظام الأساسي المتوفرة. بالنظر إلى أن Json.NET كانت متشددة إلى حد ما في ASP.NET ، فإن الخطة الجديدة تبدو أفضل من الناحية الصافية للأشخاص مثلك ؛ لذلك لست متأكدًا تمامًا من أي جزء من خطتنا تعتقد أنه يمثل تهديدًا.

هناك سؤال مفتوح حول ما ستستخدمه قوالب ASP.NET في 3.0.

ألم يحن الوقت لأن تكون القوالب معيارية؟ مثل خذ vue.js على سبيل المثال.

image

يتيح لك إنشاء تطبيق vue جديد اختيار الأشياء التي تريدها. لماذا لا يمكن القيام بشيء مماثل لـ asp.net بدلاً من إنشاء 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 غير المعروفة في هذا القاموس ويتم تحويل محتوى هذا القاموس إلى بنية JSON العادية.

يحتاج أي مُنسق إدخال / إخراج JSON بديل الآن إلى معالجة هذه السمات المحددة لـ JSON.NET لتتمكن من إجراء تسلسل / إلغاء تسلسل هذا النوع بشكل صحيح أو إيجاد طريقة مختلفة ، أي الرجوع إلى JSON.NET لهذه الأنواع.

الآن ، إذا كان لدينا مواصفات محددة جيدًا للميزات التي يحتاجها Input / OutputFormatter لـ JSON إلى دعم الإصدار 3.0 ، فلن تكون المشكلة المذكورة أعلاه موجودة ، على سبيل المثال ، يمكن أن تعيش هذه السمات في حزمة Microsoft.Extension ... وكل مُنسق JSON مخصص يمكن استخدامها لتنفيذ هذه الوظيفة لتكون متوافقة.

بالنسبة إلى معلوماتي ، لا يوجد سوى عدد قليل من الأمثلة على الكود المصدري "الرسمي" في ASP.NET Core والتي تم شرحها بواسطة سمات JSON.NET ، لكنني رأيت أيضًا مكتبات تابعة لجهات خارجية تستخدم سمات خاصة بـ JSON.NET (عادةً ما يتم تحديدها) اسم السمة عبر [JsonProperty("name")]

FWIW ، هذا ما يدور حوله https://github.com/Tornhoof/SpanJson/issues/63 .

terrajobst أعتقد أنك أجبت قبل أن تقرأ تعليقي السابق الذي يوضح IMO المزيد من

نحن نبحث بنشاط عن ملاحظات إضافية.

أين؟ هل يوجد مقترح / مستند API ، هل تم إنشاء API ، وما هو الريبو الذي يتم تطويره بموجبه؟

أعتقد أنك أجبت قبل أن تقرأ تعليقي السابق الذي توضحه المنظمة البحرية الدولية أكثر من مخاوفي.

لقد قرأته ولكن يبدو أنك تعارض أي تقصير ، وهو ، كما أوضح davidfowl ، ليس عمليًا بالنسبة لنا. كانت وجهة نظري أن خطتنا هي تحسين ما لدينا حاليًا ، أي شبكة ربط بحكم الأمر الواقع لـ Json.NET. ومن هنا سؤالي.

أين؟ هل يوجد مقترح / مستند API ، هل تم إنشاء API ، وما هو الريبو الذي يتم تطويره بموجبه؟

لم نقم عمدًا بأي تصميم ترميز / API في .NET Core حتى الآن لأننا أردنا نشر هذا الإعلان أولاً. لم نكن نريد أن يقرأ الناس أوراق الشاي دون تقديم السياق الذي قدمه هذا الإعلان. بمعنى آخر ، ترقبوا ، سننشر واجهات برمجة التطبيقات والرمز قريبًا.

terrajobst الانطباع الكامل عن آخر

  1. تم اتخاذ القرار لإجراء التغييرات.

من الآن فصاعدًا ، نخطط لإجراء بعض التغييرات على دعم JSON:

  1. تم الانتهاء من بعض التصميم الأولي
    نحن بحاجة إلى واجهات برمجة تطبيقات JSON عالية الأداء.
    قم بإزالة التبعية من ASP.NET Core إلى Json.NET.
    توفير حزمة تكامل ASP.NET Core لـ Json.NET.

كل هذا يعني أن هذا الاتجاه قد تم اتخاذه. كل ما يُطلب من "النظام البيئي" هو العثور على نقاط الألم الواضحة التي لا يمكن لمرض التصلب العصبي المتعدد تفسيرها بشكل واقعي.

إن إغفال ServiceStack ومناقشتها على أنها بعض مكتبات .NET من الدرجة الثانوية أمر مثير للضحك. حتى أنا فقط على المكتبات المشحونة من MS ، هذا لا يعني أنني لا أعرف عن البدائل.

ليس لدي أي مشكلة في اتخاذ MS للقرارات ، ولكن إذا تم ذكرها بشكل مباشر ، ولم تتم تغطيتها من خلال "تعليقات المجتمع" على القرارات التي تم اتخاذها بالفعل.

هذا هو انطباعي

تضمين التغريدة

لقد قرأته ولكن يبدو أنك تعارض أي تقصير

لم يقترح أبدًا أن JSON.NET كان بالفعل الافتراضي قبل ذلك. لقد أوضحت بمزيد من التفصيل أعلاه ، ولكن لتكرار هذا ، تم وضع هذا لتولي الإعداد الافتراضي وأصبح المعيار الجديد الفعلي حيث لن يكون لـ NET Core سوى 2 مُسلسل JSON في المستقبل: هذا الافتراضي الجديد عالي الأداء و JSON. NET للميزات المخصصة. سوف تصبح برامج المسلسل JSON الأخرى مكانًا مناسبًا ، مثل الميزات الفريدة المضافة لدعم السيناريوهات المختلفة.

لم نقم عمدًا بأي تصميم ترميز / تصميم واجهة برمجة تطبيقات .NET Core لأننا أردنا الحصول على هذا الإعلان أولاً.

حسنًا ، لذلك لا يمكن لأي "خارجي" معرفة مدى جودة القابلية للتوصيل أو القابلية للتوسعة أو إمكانية التشغيل البيني
سيكون بعد.

لم نكن نريد أن يقرأ الناس أوراق الشاي دون تقديم السياق الذي قدمه هذا الإعلان. بمعنى آخر ، ترقبوا ، سننشر واجهات برمجة التطبيقات والرمز قريبًا.

إذن تم تطويره داخليا إذن؟ ما المدة التي يستغرقها الأشخاص الخارجيون بعد إصدارها لاختبار واقتراح تغييرات على تصميم واجهة برمجة التطبيقات؟ اهتمامي الأساسي بالشكل الذي ستبدو عليه واجهات برمجة التطبيقات "القابلة للتوصيل" و "القابلة للتوسيع" ، هل سنكون قادرين على "تولي المسؤولية" والتحكم الكامل في تنسيق الأسلاك لأنواع المرجع / القيمة؟ ماذا عن الأنواع المضمنة ، Enums ، bools ، عناصر جوهرية أخرى ، إلخ؟ على سبيل المثال ، سيكون قادرًا على تكوين bool لقبول قيم JSON الشائعة الأخرى مثل "نعم" ، "على" ، "1".

اسئلة اخرى:

  • هل يمكن استخدام هذا التطبيق منفردًا (في حزمة NuGet منفصلة)؟
  • هل الجزء "القابل للتوصيل" من واجهة برمجة التطبيقات مرتبط بإطار عمل الويب أو يمكن استخدامه في مكان آخر (مثل Xamarin / UWP)
  • هل ستدعم NET Standard 2.0 أو .NET v4.5؟
  • إذا لم يكن الأمر كذلك ، فهل ستتمكن واجهات برمجة التطبيقات من دعم .NET Standard 2.0 أو .NET v4.5؟

تضمين التغريدة
لم يتم تطويره داخليًا (على حد علمي) ، تم إجراء جزء القارئ / الكاتب في corefxlab (https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json) وعلى وجه التحديد لا توجد واجهة برمجة تطبيقات عالية المستوى لها حتى الآن في corefxlab.

أنا شخصياً سأستثني أجزاء API القابلة للتوسيع / ​​القابلة للتوصيل لتكون .NET Standard (أي السمات وما إلى ذلك). المكتبة في corefxlab هي .NET Standard 1.1 في الوقت الحالي ، لكنني أتصور أن هذا سيتغير اعتمادًا على أهداف أداء المكتبة وما إلى ذلك.

تضمين التغريدة

يبدو أنك متشوق لأخذ تصريحاتي ووضعها في سياق "الزجاج نصف فارغ". فهمت ، أنت متشكك. أقترح أن نوفر على أنفسنا مجموعة من ضغطات المفاتيح ونناقش مقترحات محددة لواجهة برمجة التطبيقات بدلاً من مناقشتها في الملخص. أنا مقتنع تمامًا أن خطتنا ستوفر نقاط الامتداد التي تحتاجها.

terrajobst لا أحاول أن أكون متشككًا ، أحاول معرفة ما هي القدرات المقترحة عالية المستوى التي أفترض أنها قد تم تحديدها بالفعل (أم أنها جميعًا لا تزال محددة لاحقًا؟). هذا الإعلان هو الأول الذي سمع به معظمنا ، لذلك كنت بعد بعض الإيضاحات حول كيفية توصيله وقابليته لإعادة الاستخدام. هل System.Text.JsonLab هو

قد تكون هذه ميزة رائعة لمنشئي المكتبات ، ولكن عليك أيضًا التفكير في مطوري المؤسسات الذين يستخدمون 50 مكتبة مع أشجار التبعية ومحاولة إيجاد التوافق بينهم. هل سيكون هناك تكوينات تعيين نمط ملزم لإعادة التوجيه لمحاولة إدارة حالات عدم التطابق؟

تبدو هذه المحادثة على حافة الهاوية ، سواء بسبب تعرض الأشخاص للإهانة بطريقة ما أو لأنهم يحاولون الدفاع عن إجراء تم اتخاذه أو لم يتم اتخاذه. من الصعب القراءة. اعتذارات حول! من فضلك فقط دع الوضع الحالي يكون والمضي قدما.

يبدو أن هناك سببين لهذا التغيير. الأول هو الرغبة في تحسين الأداء باستخدام أنواع جديدة داخل .Net Core.

بالإضافة إلى ذلك ، تم التعرف على أنه في وقت ما تم ارتكاب خطأ هندسي بتضمين مراجع صلبة إلى JSON.Net ، وهي مكتبة موجودة خارجيًا في .Net. لإصلاح ذلك ، يجب تقديم تطبيق JSON جديد ومضمّن جنبًا إلى جنب مع الواجهات التي تسمح للأطراف الثالثة باستخدام تطبيقاتهم الخاصة.

هل سيؤدي هذا إلى كسر الأشياء؟ نعم! لهذا السبب يحمل الإعلان علامة "تغييرات عاجلة" عليه. (ربما يجب تكرار هذه التسمية هنا.) وبما أن هذا معروف بأنه تغيير فاصل ، فقد بدأت مناقشة لاستكشاف التأثير. بالإضافة إلى ذلك ، لتقليل التأثير ، سيتم توفير مكتبة إضافية تسمح للأشخاص بمواصلة استخدام JSON.Net.

بصفتي مؤلف مكتبة ، فأنا مهتم حقًا بهذا ، وأفضل أن تمضي المحادثة إلى الأمام.


Tornhoof ردًا على الأمثلة الخاصة بك ، إذا كنت أرغب في الاستمرار في استخدام JSON.Net ، فسأحتاج أيضًا إلى الرجوع إلى مكتبة التوافق التي ذكرتها سابقًا. يجب أن يكون في الغالب يعمل بنظام التوصيل والتشغيل ، ولكن قد تكون هناك تغييرات. أنا بالتأكيد لا أريد أن يفرض إطار العمل (.Net Core) أن المسلسل الذي أختاره يجب أن يستخدم هذه السمات للتسلسل ، خاصةً عندما يستخدم جهاز التسلسل الخاص بي آلية مختلفة لمفاهيم متشابهة.

يجب أن يكون الحل المقدم من .Net أكثر عمومية من ذلك. يجب أن يتم تسليم تسلسل نموذج محدد من خلال تنفيذ JSON المختار.

mythz من كل ما أعرفه

تضمين التغريدة
لست متأكدًا مما تقصده بمزيد من العمومية؟
بافتراض أن جهاز التسلسل الخاص بك لديه مفهوم تجاوز أسماء خصائص json ، وتغيير سلوكها الفارغ و / أو عمليات التنفيذ الاحتياطية / التقاط الكل ، وافتراض أن جميع الميزات الثلاثة هي جزء من المواصفات المشتركة لمتسلسلات JSON لـ .net core 3.0 ، ثم حزمة التنفيذ تعيين هذه السمات لتفاصيل التنفيذ الداخلية الخاصة بك.
على سبيل المثال ، إذا كانت مكتبتك تفضل استخدام [DataMember] لتحديد اسم الخصائص (مثلما يفعل SpanJson) ، فيجب تعيين حزمة التكامل الخاصة بك بهذه السهولة.
أنا لا أقول أن السمات هي الطريقة الصحيحة ، إنها مجرد جزء مرئي من مثال الكود.

من الواضح أن العالم المثالي هو أنه لا توجد مكتبة إطار عمل لـ ASP.NET Core ستستخدم أي تعليقات توضيحية محددة للتحكم في سلوك التسلسل ، ولكن بالنسبة لهذه الميزة أعلاه ، فإن ذلك معقد للغاية إلى المستحيل ، لأن RFC يتطلب قواعد تسمية معينة يجب اتباعها .

في كلتا الحالتين ، أعتقد أنه سيكون هناك العديد من المناقشات حول هذه الميزات المشتركة ، وكيفية استخدامها ووصفها في المستقبل.

أي خطط لاستخدام تعليمات SIMD في محلل JSON الجديد ، كما هو الحال في RapidJSON؟

المرجع: http://rapidjson.org/

يبدو الاقتراح المقترح جيدًا ، ولكن يُرجى فقط محاولة تسهيل " التغييرات العاجلة " ، فأنا مجرد مستخدم عام لملفات الطرف الثالث ، وقد خضعت مؤخرًا لإحدى هذه التجارب حيث تم استبعاد الانعكاس فجأة من عملية إنشاء الإصدار الأصلي لـ UWP .net (مترجم ).

لذلك لا يمكن إنشاء أي من تطبيقات UWP الخاصة بي في وضع الإصدار لأشهر حيث كان علي إعادة كتابة كل التعليمات البرمجية التي استخدمت الانعكاس في libs الطرف الثالث. أعلم أن العديد من مؤلفي المكتبات اضطروا إلى تقسيم تطبيقاتهم مرة أخرى لاستبعاد الانعكاس في أجزاء UWP. لم يحضر معظم مؤلفي المكتبات إلى الحفلة واضطررت للقفز من السفينة. على الرغم من أن MS جاء في المقدمة والتزم بتنفيذ بديل في .net القياسي 2.1. نحن نعلم أن الواقع على أرض الواقع هو. net standard 2.1 سيستغرق شهورًا للتسليم من التغيير الأول.

النقطة هي ببساطة ، كانت هذه عملية معطلة للغاية بالنسبة لي وكان لها عواقب وخيمة على المستخدمين النهائيين ولم تكن سوى "سلسة" وخالية من الاحتكاك.

هذه بالتأكيد هي الخطوة الصحيحة التي يجب القيام بها.
إنني أتساءل لبعض الوقت عن رؤية مرجع Json.Net هذا.

Tornhoof أعتقد أنه يجب أن يكون هناك فصل محدد: الواجهات التي سيحتاج كل مزود إلى تنفيذها من أجل استخدامها مع .Net Core 3.0 ، والتطبيق الافتراضي المدمج فيه.

يجب أن تكون الواجهات عامة الاستخدام قدر الإمكان. ربما يكون الأمر بسيطًا مثل تحديد طرق Serialize() و Deserialize() .

يجب ترك التفاصيل الأخرى للتنفيذ. إذا استخدم التطبيق الافتراضي سمة لتعريف آلية مفتاح خاصية مخصصة ، فأنا على ما يرام في ذلك. أعتقد أن هذه تفاصيل خاصة بالتنفيذ ولا ينبغي أن تكون جزءًا من الواجهة.

ومع ذلك ، قد تكون القدرة على تخصيص خصائص المفتاح مطلبًا ، على الرغم من أنني لست متأكدًا من كيفية تدوين ذلك.

gregsdennis نعم ، أنت على حق ، كنت أتطلع بشكل أساسي إلى IInput / OutputFormatter ، الموجود بالفعل حاليًا في ASP.NET Core وعلى وجه التحديد المشكلات المتعلقة باستبدالها بإصدارات غير JSON.NET.
على أي حال ، كما تظهر تعليقاتك و mythz ، أعتقد أن تعريف النطاق سيصبح مثيرًا للاهتمام وربما ليس بهذه البساطة (أتذكر المشكلات المتعلقة بمواصفات واجهة DI). لذلك من الأفضل إشراك العديد من وجهات النظر المختلفة في وقت مبكر من العملية.

Tornhoof وافق. تعتمد واجهات التنسيق الحالية بشكل واضح على JSON.Net ، ولكنها لا تعتمد كثيرًا على جهاز التسلسل نفسه ، بل على كائن الخيارات. يبدو أننا سنحتاج إلى طريقة عامة لتوصيل الخيارات أيضًا (كائن خيارات مشترك).

هل هذا يعني أن كائن الخيارات يفرض حدًا أدنى من الميزات المحددة للتنفيذ؟ لا أعتقد ذلك. لقد قمت مؤخرًا بتطبيق مُنسق لجهاز التسلسل الخاص بي والذي يتجاهل تمامًا كائن الخيارات ، ولكنه كان لاستخدامي الخاص. إذا كنت أرغب في جعل واحدة للاستخدام العام ، فسأحاول تفسير أكبر عدد ممكن من هذه الخيارات من أجل دعمها.

ليس هذا الآن كيف نفعل الأشياء. الخيارات خاصة بالمسلسل ولا توجد واجهة مشتركة لها. تم بالفعل أخذ المُنسِّقات الموجودة في MVC في الاعتبار بشكل صحيح وعدم اقترانها بأي شيء. سيكون لـ JsonResult تغييرات عاجلة لأنه يأخذ JsonSerializationOptions مباشرة (نوع JSON.NET).

كنت على وشك أن أقول نفس الشيء. لا نخطط لبناء تجريد لقارئ / كاتب / مُسلسل JSON. ليس هناك حاجة. تتعامل أطر العمل إما في أساسيات الإدخال والإخراج (مثل Stream ، TextReader ) أو يتم توصيلها بمعالجة إطار العمل ذي المستوى الأعلى (مثل مُنسِّقات ASP.NET Core).

الحديث عن نقاط الألم: أنا شخصياً (وأنا من المحتمل أن أنتمي إلى أقلية صغيرة) أشعر بالقلق إزاء الطبيعة المتراخية للعديد من موزعي JSON. هناك معيار (tm) ولكن معظم المحللين اختاروا أن يكونوا متساهلين ويقبلوا المستندات غير المطابقة. الأمر السيئ في ذلك على المدى الطويل هو أن المطورين لا يطبقون معيارًا يطبقونه تجاه المكتبة. إذا كانت المكتبة تسمح بالمستند غير المطابق ، فسيكون المطورون سعداء طالما أن جميع وحدات البت تستخدم نفس المكتبة. ينشأ الألم عند محاولة التواصل بين المجالات التي تستخدم مكتبات مختلفة. فجأة حدثت مشكلة لأن المكتبات المختلفة تدعم نكهات مختلفة من JSON.

هل يجب أن نزيل نقاط الألم عن طريق جعل مكتبة JSON متساهلة قدر الإمكان (ولكن ربما ينتهي الأمر بالتعقيد والغموض) أو مهاجمة السبب الجذري ؛ مكتبات JSON غير المؤكدة.

نظرًا لأن MS المؤثر ربما يكون هناك الكثير الذي يجب أن نطلبه من MS لتتوافق بنجاح مع موزعي JSON من أجل تحسين قابلية التشغيل البيني على المدى الطويل ولكني كنت أتمنى أن يكون الأمر مختلفًا. ربما تكون متساهلا في القراءة ولكن صارمة في الكتابة؟

(الأشياء ليست في المعيار ؛ التعليقات ، والفواصل اللاحقة ، وسلاسل الاقتباس المنفردة ، ولا توجد سلاسل اقتباس وما إلى ذلك)

IMHO ، نظرًا لأن JSON ينبع من عالم webbrowser ، يبدو أنه من أجل قابلية التشغيل البيني ، يجب أن نختار ضعف التمثيل الأساسي للأرقام في JSON على الرغم من أن معيار JSON لا يقول شيئًا عن المندوب.

بالحديث عن واجهة برمجة التطبيقات ، أفترض ضمنيًا أن واجهة برمجة التطبيقات الأكثر استخدامًا ستكون DOM مثل واجهة برمجة التطبيقات ، لكنني سأجدها مفيدة جدًا أيضًا إذا كان هناك واجهة برمجة تطبيقات ذات مستوى منخفض تسمح لي باستهلاك دفق الرمز المميز أو الحصول على إشارة على واجهة زائر من أجل تلك المستندات الكبيرة التي أريد فقط استخراج جزء صغير من البيانات منها.

mrange - بقدر ما أحب جعل الأشياء صارمة قدر الإمكان .... يعتمد القيام بذلك على القدرة على إجراء تغييرات في التعليمات البرمجية غير المطابقة.

إذا كنت تتفاعل مع خدمة قديمة تحت سيطرة شركة أخرى ، فإن القدرة على تغيير الرمز المسيء تقترب من الصفر. حتى التقييد عند الكتابة ، رغم أنه أكثر قابلية للتنفيذ ، لا يخلو من مشاكله الخاصة هنا: ماذا لو توقع الكود المخالف إرسال كائن غير مطابق إليه؟

terrajobst شكرا لك! كل ما هو مطلوب هنا هو Func<Stream, CancellationToken, Task<T>> و Func<T, CancellationToken, Stream, Task> . ربما مع بعض الأحمال الزائدة لـ TextReader / Writer و Span و string.

ومع ذلك ، فإن الجانب السلبي هو عندما تريد إجراء تسلسل / إلغاء تسلسل نوع مكتبة أخرى ، ويكون هذا النوع مزينًا بسمات من مُسلسل json الذي لا تستخدمه.

thefringeninja إذا كنت تستخدم بالفعل مكتبة الطرف الثالث للكائنات ،

أنا لست واحدًا من الترويج للخوف ، لكنني أعتقد أن mythz لديه بعض النقاط الصحيحة.

terrajobst فيما يتعلق بالنظام البيئي ، على الرغم من أنه من المستحيل حساب كل مكتبة هناك ، لا أعتقد أن البحث السريع عن "json" على NuGet سيخبر أي شخص كثيرًا. ربما لا يكون اسم ServiceStack.Text هو الطريقة الأكثر وضوحًا لقول "مرحبًا! أنا حزمة يمكنها (إلغاء) تسلسل JSON!" ، ولكن كانت هناك معايير على مر السنين تقارنها. ربما يتعلق الأمر بتجربة إعدادات MS الافتراضية وإما عدم معرفة اتساع وشعبية البدائل أو استخدامها بشكل متكرر بما يكفي داخليًا للتعرف عليها.

أوافق على أنه يجب أن يكون هناك بعض التقصير لتوفير تجربة _ تعمل فقط _ خارج الصندوق. إذا قام مؤلفو المكتبات الآخرون في النظام البيئي بنشر حزمة تكامل ، فسيكون من الرائع أن يحصلوا على مكون في المستندات ، وملاحظات الإصدار ، وما إلى ذلك للتأكيد على وجود بدائل تتجاوز الإعدادات الافتراضية. يصعب اكتشافه سيكون مشكلة للنظام البيئي.

آمل أنه إذا كان الهدف من إزالة التبعية صادقًا ، فيجب أن تمثل واجهات برمجة التطبيقات احتياجات المجتمع على أفضل وجه وألا تكون على غرار Json.NET مباشرة. خلاصة القول هي أنها ستتطلب عملاً من جميع مؤلفي المكتبة ، وليس فقط ServiceStack ، ولكن لا ينبغي أن تشبه واجهات برمجة التطبيقات API الخاصة بـ Json.NET مباشرةً ، وإلا ستعود إلى ما يشبه التبعية ولكن بدون dll.

يجب ألا تشبه واجهات برمجة التطبيقات API الخاصة بـ Json.NET مباشرةً

... أو تنفيذ أي مزود آخر محدد.

تضمن جزء من المناقشة التي دارت قبل الإعلان فكرة أن فريق .Net سيعمل على الرسم من مكتبات مختلفة للتعرف على كيفية حل المشكلات المختلفة ، ومن ثم استخدام ما اعتبروه أنه الأفضل من تلك. جنبا إلى جنب مع الأفكار الخاصة بهم. من نواحٍ عديدة ، لا يختلف الأمر عن كيفية تطوير أي مكتبة JSON جديدة ؛ يحدث فقط أن يتم تضمين هذا في إطار العمل.

نحن جميعًا في الحصول على مكتبة JSON عالية الأداء لسنا بحاجة إلى بناء أنفسنا. :)

قبل مناقشة أي شيء ، ضع في اعتبارك الاستفادة من نتائج Microsoft Research في هذا المجال (بشكل أكثر تحديدًا ، التحليل غير المتفرّع ولا تحليل FSM) https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -تحليلات البيانات/

نحن نسير في هذا الاتجاه لتحليل JSON عالي الأداء --- إلى جانب Span<T> بالطبع ---
تضمين التغريدة

:( كل هذا النقاش حول JSON يجعلني أشعر بأن سؤالي حول القوالب قد انتهى.

أتمنى أن يكون لدي المزيد من الوقت لهذه المناقشة لأنه كان جحيمًا ولكني أرى سبب تحولها إلى ما هي عليه. 4.6.1 يجب أن تظل متسقة مع الترقيات والترقيات وستكون التغييرات العاجلة للباقي.

لقد رأيت الكثير من الحزم التي تم استرجاعها لـ core و 461 وآمل أن يعمل هذا النوع أو التغيير على إصلاحها.

أنا قلق من أن المشكلة المتتالية ستطاردنا ، يرجى إثبات خطأنا.

// dot net devs في كل مكان

@ c0shea

[...] سيكون من الرائع أن يحصلوا على قابس في المستندات ، وملاحظات الإصدار ، وما إلى ذلك للتأكيد على أن هناك بدائل تتجاوز الإعدادات الافتراضية.

أنا متأكد من أن هذا سيكون هو الحال. تسرد المستندات بالفعل تطبيقات بديلة لموضوعات متعددة ، مثل حاويات DI أو موفري التسجيل أو تكامل Swagger أو موفري قاعدة بيانات EF Core .

@ فيليب هايدون
يدعم نظام القوالب بالفعل القوالب القابلة للتخصيص ، وتحتوي القوالب الموجودة بالفعل بالفعل على عدد من الخيارات. ما عليك سوى التحقق من مثال dotnet new mvc --help لمعرفة ما هو ممكن حاليًا. أنا متأكد من أنه يمكنك بسهولة توسيع ذلك من خلال تكامل JSON المتسلسل البديل ، ومن المحتمل أن يتم قبول طلبات الميزات أو طلبات السحب الخاصة بذلك في aspnet / القوالب .

mrange - بقدر ما أحب جعل الأشياء صارمة قدر الإمكان .... يعتمد القيام بذلك على القدرة على إجراء تغييرات في التعليمات البرمجية غير المطابقة.

إذا كنت تتفاعل مع خدمة قديمة تحت سيطرة شركة أخرى ، فإن القدرة على تغيير الرمز المسيء تقترب من الصفر. حتى التقييد عند الكتابة ، رغم أنه أكثر قابلية للتنفيذ ، لا يخلو من مشاكله الخاصة هنا: ماذا لو توقع الكود المخالف إرسال كائن غير مطابق إليه؟

ربما يكون لديك وضع صارم افتراضيًا وقادرًا على تبديله بشكل صريح إلى وضع أكثر تساهلاً

poke أعتقد أنك بحاجة فعلاً للذهاب إلى تجربة vue cli ثم إعادة محاولة dotnew جديد. شبكة الإنترنت الحالية الجديدة ... هي ... إنها ...

هل يمكنني أن أطلب منك أن تتذكر أن تحليل المتصفحات المختلفة لـ JSON لا يدعم قيم int64 بشكل صحيح ، ويمنحنا القدرة على تسلسل / إلغاء تسلسل السلاسل الطويلة؟ إنها واحدة من تلك الأشياء التي لا تلاحظها حتى تعضك بشدة. أحد الاختلافات في هذا هو القدرة على تحديد ما إذا كان سيتم إلغاء تسلسل الأرقام إلى ints أو longs بشكل افتراضي.

هل يمكنني أن أطلب منك أن تتذكر أن تحليل المتصفحات المختلفة لـ JSON لا يدعم قيم int64 بشكل صحيح ، ويمنحنا القدرة على تسلسل / إلغاء تسلسل السلاسل الطويلة؟ إنها واحدة من تلك الأشياء التي لا تلاحظها حتى تعضك بشدة. أحد الاختلافات في هذا هو القدرة على تحديد ما إذا كان سيتم إلغاء تسلسل الأرقام إلى ints أو longs بشكل افتراضي.

.... آه ، EcmaScript ، شكرًا لجعل كل شيء يتضاعف. أنا متأكد من أن ذلك لم يسبب مشاكل في جزء آخر من الكود ...

بصفتي أصوليًا ، فأنا لا أحب أشياء مثل هذه.
بصفتي واقعيًا ، أعتقد أنني سأوافق على هذا.

هل سيكون أي جزء من تنفيذ JSON الجديد في .Net Standard 2.1 ؟

لقد كنت أتابع هذا قليلاً ، ولست متأكدًا مما إذا فاتني ذلك. هل هناك واجهة أو واجهة API مقترحة يمكنني مراجعتها؟ أنا مهتم برؤية مساحة سطح API لهذا الاقتراح.

هل هناك واجهة أو واجهة API مقترحة يمكنني مراجعتها؟

لا يزال هناك الكثير للقيام به ، ولكن https://github.com/dotnet/corefx/pull/33216 هي البداية. فيما يلي ملاحظات مراجعة API .

تحديث: خارطة الطريق متاحة أيضا هنا .

فكيف ستكتمل الميزة التي ستتم مقارنة واجهة aspnet 3.0 api بواجهة برمجة تطبيقات json.net؟ أيضًا ، هل سيتم التخلص التدريجي من json.net لجميع المقاصد والأغراض من خلال تطوير تطبيقات جديدة مع واجهات برمجة التطبيقات الأصلية؟

فقط تحسين الأداء أو يعني استبدال جميع وظائف json.net؟

هذه أخبار رائعة.

أوصي بشدة بمحاولة التعاون مع neuecc ، فقد كان عمله مع MessagePack و Utf8Json و ZeroFormatter وما إلى ذلك

linkanyway ، ستكون النتيجة استبدال مجموعة فرعية من json.net ، مع توفير apis جديد بدون تخصيص.

أظن أن غالبية مستخدمي aspnet لن يكون لديهم تبعية قوية لتطبيق json.net وسيكونون قادرين على الترحيل بسلاسة تقريبًا.

هل هناك واجهة أو واجهة API مقترحة يمكنني مراجعتها؟

لا يزال هناك الكثير للقيام به ، ولكن dotnet / corefx # 33216 هي بداية. فيما يلي ملاحظات مراجعة API .

تحديث: خارطة الطريق متاحة أيضا هنا .

khellang هل سنحصل على أي مساعدة في اللغة يمكننا كتابة json في c # بشكل حقيقي؟

حركة جيدة أخرى في اتجاه OSS. سوف يحفز مطوري المنصات التجارية الأخرى على تطوير شيء أفضل مما يفعله MS بالفعل مجانًا ، أو أن يصبح OSS بالكامل إذا كانوا مهتمين حقًا بالمجتمع.

هل سنحصل على أي مساعدة لغوية يمكننا كتابة json في c # بشكل حقيقي؟

dotnetchris لست متأكدًا مما لـ JSON ؟

khellang هذه بالتأكيد خطوة في الاتجاه الصحيح ، لكنني أعني دعم ضربة كاملة. باستخدام نفس الكائنات النموذجية من الرابط الخاص بك ، أقرب إلى:

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

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

باستخدام ما يكفي من الفودو ، مثل إنشاء كائن tuple / valuetuple / Record الضمني لجعل كل ذلك يعمل على مستوى lang خلف الكواليس.

على العكس من ذلك ، يمكن للمترجم استدعاء خدمات json ، وإنشاء فئة ثم العمل مع مثيل من الفئة كما لو كنت قد كتبت:

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

تحرير: LOL @ downvoters.

dotnetchris إذا كنت مهتمًا ، فيرجى التصويت على https://github.com/dotnet/roslyn/pull/24110. تم إغلاقه من قبل فريق IDE بسبب عدم الاهتمام. ولكن إذا كان هناك عدد كافٍ من الأصوات ، فربما يتغير ذلك.

هل تعني واجهات برمجة تطبيقات JSON "المضمنة" و "المنصة المقدمة" أنها لن تكون حزمة كتلة منفصلة (معيار الشبكة)؟ إذا لم يحدث ذلك ، فلماذا لا؟

أفترض أن إطار عمل ASP.NET Core المشترك الجديد لا يمكن أن يعتمد على nuget pakages ، أو هل يمكنه ذلك؟

أليس هناك بالفعل System.Json Namespace؟ هل هذه هي مساحة الاسم التي سيتم استخدامها / توسيعها لـ .NET Core 3.0 وفي النهاية .NET Standard. تم استخدام مساحة الاسم هذه بالفعل (قد لا يتم استخدامها كثيرًا ولكنها متوفرة 😅) على Xamarin.Android 7.1+ و Xamarin.iOS 10.8+ و Xamarin.Mac 3.0+.

إزالته من شأنه أن يكسر التوافق مع الإصدارات السابقة. قد يؤدي تركها وبدء واجهة برمجة تطبيقات جديدة إلى حدوث بعض الالتباس. قد يكون توسيعه / تحسينه دون إزالة أي واجهات برمجة تطبيقات مقيدًا بعض الشيء عند إضافة واجهات برمجة تطبيقات جديدة.

سيكون من الرائع أن يكون لديك واجهات لـ JsonReader / JsonWriter ، لأن هناك مصادر وأهداف أخرى غير التدفقات فقط. على سبيل المثال ، يمكنني أيضًا استخدام JSON.NET لـ MongoDB. إنه أسرع ولا يتعين علي الاحتفاظ بمسلسلات متعددة في تطبيقاتي.

أعلم أنه قد يضر بالأداء قليلاً ، لكنه مفيد للغاية.

SebastianStehle : JsonReader / JsonWriter هي تجريدات عالية المستوى ، انظر تعليق terrajobst

خطة 3.0 هي كما يلي:

  1. واجهات برمجة تطبيقات JSON مدمجة عالية الأداء. قارئ / كاتب منخفض المستوى ، قارئ / كاتب قائم على التدفق ، ومسلسل>.
  2. ASP.NET Core قابل للتوصيل إلى مكون JSON.

هناك سؤال مفتوح حول ما ستستخدمه قوالب ASP.NET في 3.0. اعتمادًا على الدقة التي يمكننا توفيرها بحلول 3.0 ، قد نجعلهم يسحبون في حزمة تكامل Json.NET. ومع ذلك ، فإن الهدف هو تقديم قدر كافٍ من الدقة والتكافؤ للاعتماد فقط على العناصر المضمنة بشكل افتراضي.

سيتم التفاف واجهة برمجة التطبيقات عالية المستوى وسهلة الاستخدام حول التدفقات لإلغاء التسلسل بسهولة من التدفقات وإليها (غالبًا ما يكون هذا أكثر شيوعًا ، عند التسلسل. إذا كنت تريد أفضل أداء في السيناريوهات التي لا يمكنك فيها استخدام التدفقات ، فيجب عليك استخدام واجهات برمجة تطبيقات المستوى التي تعمل على Span<T> أو Memory<T> ، خاصة عندما تكون لديك البيانات بالفعل في متناول اليد / في الذاكرة التي تريد استخدامها وليس لديك حمل غير متزامن.

تضمين التغريدة

لا يوفر https://github.com/neuecc/Utf8Json الوظيفة لكتابة قراء / كاتب مخصصين لأسباب تتعلق بالأداء (أعتقد أن المكالمات والتخصيصات الافتراضية) وأعتقد أنهم يرغبون في السير في نفس المسار. لكن حتى الآن لم أر أي رمز تسلسل حتى الآن.

أتفق مع @ JonasZ95 و gregsdennis ، وآمل ألا يكون التنفيذ مجرد تجريد بسيط لنفس تفاصيل تنفيذ JSON.Net ولكن بدلاً من ذلك سوف يركز على الشكل الذي يجب أن يبدو عليه.

أعتقد أيضًا أنه يجب التعامل معها على أنها وظيفتان منفصلتان ...

  1. التسلسل / إلغاء التسلسل
  2. نسخة json من التسلسل المذكور وإلغاء التسلسل.

نأمل أن يستخدم إطار عمل ASP.NET Core تجريدًا للتسلسل العام بدلاً من تجريد محدد لـ JSON.

فيما يتعلق بالقابلية للتوسعة ، آمل أن يستخدم الإطار تقنية DI للترميز إلى التجريدات (واجهات وليست فئات مجردة) وأن يوفر ببساطة افتراضيًا محليًا. من منظور مؤلفي مكتبة JSON ، سيوفر هذا أكبر قابلية للتوسعة لأن كل ما عليك فعله هو توفير فئة محول ASP.NET Core يستخدم تطبيق المكتبة للواجهات ثم تكوين ASP.NET Core لاستخدام محول المكتبة.

يمكن أن يبدو تنفيذ مكتبة تابعة لجهة خارجية على النحو التالي:
ج #
// مرجع مكتبات الطرف الثالث
باستخدام Newtonsoft.Json ؛

// مثال ساذج جدًا للإيجاز فقط
// جعل نقطة
فئة عامة NewtonsoftAdapter: ISerializer
{
إعدادات _settings JsonSerializer الخاصة ؛
تنسيق خاص _format؛

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

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

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

}

...

// محول الإعداد مع خيارات تخصيص الطرف الثالث
var settings = إعدادات JsonSerializer الجديدة
{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
} ؛
var adaptor = new NewtonsoftAdapter (settings، Formatting.Indented) ؛

// تكوين جوهر asp.net
// حيث يقوم المحول بتنفيذ ISerializer (أو أي اسم توصلت إليه)
// يمكن لمؤلفي المكتبة توفير طريقة امتداد UseXYZ () الخاصة بهم.
app.UseSerializer (محول) ؛
""

كان هناك الكثير من التقدم في تحليل النص المستند إلى SIMD ، بما في ذلك النصوص المهيكلة ، مثل JSON . هل هناك أي احتمال أن يقترب العمل في .NET Core من مستوى الأداء هذا؟ هل هناك طريقة لاستخدام هذه التقنيات؟

مرحبًا ، حتى Microsoft Research لديه بعض الحلول الجديدة عالية الأداء!

تضمين التغريدة أنا مهتم أيضًا بأي معايير للحصول على فكرة عن كيفية مقارنة ضمنية Json الحالية مع Simdjson.

من جانب الطريق، والكتاب من simdjson قالت أنها لا تزال تعمل على نشر هذا المشروع بالكامل (على ما أظن، أكثر ثيقة). في الوقت الحالي ، يمكنك قراءة بعض المناقشات الشيقة حول هذا المشروع على HN .

هل هناك طريقة لاستخدام هذه التقنيات؟

NET Core 3.0 فقط لشحن مجموعة من العناصر الجوهرية المعتمدة على النظام الأساسي ، لذا فهي بالتأكيد قابلة للتنفيذ 😄

بالنسبة لما يستحق ، أعتقد في نطاق الويب ، أن الشبكة هي عنق الزجاجة الأساسي ، وعلى الرغم من أنه من الرائع أن تتمكن من تحليل الجيجابايت في غضون ثوانٍ ، لا أعتقد أن هذا مفيد جدًا لمشروع الويب.

لا تفهموني خطأ ، فإن تحسينات الأداء مثل هذه رائعة جدًا وربما تفيد حتى مستندات JSON الصغيرة جدًا. لكن في الوقت الحالي ، أعتقد أن التركيز مع المكتبة الجديدة هو تجنب تخصيص الذاكرة ونقل كل شيء عن قرب إلى طبقة الشبكة. يجب أن يؤدي ذلك بمفرده بالفعل إلى تحسين الأداء كثيرًا عبر JSON.NET. ولكن عند الانتهاء من العمل الأولي ، قد يكون النظر إلى التحسينات الإضافية قصة أخرى.

حيث أعمل نقوم بتحليل تيرا بايت من JSON كل يوم. أعرف أيضًا آخرين يستخدمون .NET و F # لمعالجة الكثير من مستندات JSON أيضًا. أصبح JSON أكثر من مجرد خادم => آلية نقل المتصفح. يتم استخدامه كثيرًا في سيناريوهات الخلفية البحتة.

OFC. سيكون من الأفضل أن تتحول الخلفية إلى تنسيق ثنائي مثل AVRO / Protobuf ولكن غالبًا ما يكون ذلك صعبًا ولدى JSON بعض الفوائد (أعترف على مضض). يمكن أن يؤدي وجود محلل JSON سريع حقيقي إلى توفير 10000 دولار شهريًا للشركات المشابهة لنا.

poke يقع هذا المشروع ضمن NET Core (وليس ASP.NET ...) ، لذلك فهو

يمكنني أن أتفق على فكرة أن الوقت قد فات للعمل على تقنية التحسين المحددة هذه لـ .NET Core 3.0 ، لكنني آمل أن يتم إجراء بعض التحقيقات الآن للتأكد من أن التحسين سيكون ممكنًا في المستقبل (أي بدون كسر التغييرات ).

قد يكون من الأفضل عمل شيء مثل تجميع الخرائط الموحد ('System.Text.Json.Mapping') حيث يتم تحديد السمات والأشياء الأخرى لتعيين فئات JSON إلى C #؟ بعد تنفيذ هذا الشيء ، يمكن اعتماد جميع موزعي / كتاب JSON الحاليين لاستخدام التعيين الموحد. سيعطي القدرة لجميع تطبيقات .NET Standard على الترحيل بين مكتبات JSON المختلفة دون أي ألم

AlexeiScherbakov التجريدات الجديدة لا تساعد كثيرًا في الواقع. سوف تقيد نفسك مرة أخرى باختيار فكرة مجردة مشتركة وستكون هناك دائمًا مكتبات جديدة لا يمكنها استخدام التجريد وتتطلب المزيد. لطالما كان الأمر كذلك ، على سبيل المثال مع قطع الأشجار .

لا أعتقد أن إنشاء تجريد جديد بناءً على هذا التطبيق الجديد سيعطينا أي فائدة ، خاصةً عندما تكون المكتبة مصممة لتكون أقل ثراءً بالميزات على أي حال.

وهناك بالفعل تجريد معياري موجود بالفعل في شكل DataContract / DataMember والذي آمل أن تحظى هذه المكتبة باحترامه (حتى لو كان هذا التجريد محدودًا إلى حد ما).

بخلاف سمة التجاهل ، لا يمكننا الحصول على مليار سمة وسيناريوهات جديدة لتلبية احتياجاتنا. إذا كنت تفضل تعيين 1: 1 من JSON للفئات ، إذا كنت تريد القيام بأي شيء خارج عن القاعدة أو دعم الإرث ، فاستخدم json.net.

أنا شخصياً لا أهتم كثيراً بفصول JSON <=> C #. أعتقد أنه من المهم أن يكون مفهوم التحليل / الكتابة JSON منفصلًا عن نموذج كائن C # الذي تم إنشاؤه من نموذج JSON.
بهذه الطريقة أنا (التي لا تهتم كثيرًا بفئات JSON <=> C #) يمكن أن يكون لدي محلل فعال حقًا دون تعثر دائري على نموذج كائن لطيف.

mrange هذا ما هو القارئ والكاتب

هل يعني ذلك أنه يمكنني توقع واجهة برمجة تطبيقات قارئ / كاتب في النظام الأساسي الذي يوفره JSON API؟ هل نمط القارئ / الكاتب هو الأكثر فاعلية؟

هناك 3 أنواع في System.Text.Json حتى الآن :

  • Utf8JsonReader - طريقة سريعة ، غير مخبأة ، للأمام فقط لقراءة نص JSON المشفر UTF-8.
  • Utf8JsonWriter - ^ مثل Utf8JsonReader ، لكن للكتابة.
  • JsonDocument - نموذج مستند وصول عشوائي للقراءة فقط لحمولات JSON.

يجب أن تكون جميع الأنواع المذكورة أعلاه (أكثر أو أقل) خالية من التخصيص 👍

نشرنا ورقة simdjson: https://arxiv.org/abs/1902.08318

هناك أيضًا عمل مستمر على منفذ C # من simdjson: https://github.com/EgorBo/SimdJsonSharp

cc إيجوربو

قد يكون من الأفضل عمل شيء مثل تجميع الخرائط الموحد ('System.Text.Json.Mapping') حيث يتم تحديد السمات والأشياء الأخرى لتعيين فئات JSON إلى C #؟ بعد تنفيذ هذا الشيء ، يمكن اعتماد جميع موزعي / كتاب JSON الحاليين لاستخدام التعيين الموحد. سيعطي القدرة لجميع تطبيقات .NET Standard على الترحيل بين مكتبات JSON المختلفة دون أي ألم

آمل حقًا ألا يعتمد التجريد الجديد على السمات. أحاول استخدام كائنات POCO النظيفة في المكتبات الأساسية واستخدم DI لتجنب الاضطرار إلى معرفة التنفيذ. بالتأكيد لا أرغب في تزيين الفصول الدراسية الأساسية بسمات مطلوبة للتنفيذ. قد يؤدي هذا في النهاية إلى إنشاء فئات إضافية في طبقات واجهة المستخدم التي تقوم بشكل أساسي بتعيين كائن مجال موجود إلى json.

من المحتمل أن يكون تعيين 1-1 لفئات json إلى c # أسلوبًا أفضل ، على الأقل في بعض الحالات يمكنك تجنب إنشاء فئات جديدة حتى إذا كانت فئات نوع viewmodel ستظل ضرورية في حالات أخرى.

سيكون من الجيد لو كانت هناك طريقة ما لتجاهل الخصائص غير المطلوبة وعلى الأقل التحكم في بعض جوانب التسلسل (مثل غلاف الجمل مقابل باسكال).

mrange هذا ما هو القارئ والكاتب

davidfowl هل هذا يعني أن واجهات برمجة التطبيقات الجديدة تسير في هذا الطريق؟ هل تم الانتهاء من التصميم؟

دعم التسلسل هبوط كما نتحدث . تقول المسألة ذات الصلة :

  • نظرًا لقيود الوقت ، ولجمع التعليقات ، فإن مجموعة الميزات مخصصة للحد الأدنى من المنتج القابل للتطبيق لـ 3.0.
  • يتم استهداف سيناريوهات كائن POCO البسيطة. تُستخدم هذه عادةً لسيناريوهات DTO.
  • تم تصميم واجهة برمجة التطبيقات لتكون قابلة للتوسيع للميزات الجديدة في الإصدارات اللاحقة ومن قبل المجتمع.
  • سمات وقت التصميم لتحديد الخيارات المختلفة ، لكنها لا تزال تدعم التعديلات في وقت التشغيل.
  • أداء عالٍ باستخدام IL Emit مع الرجوع إلى الانعكاس القياسي للتوافق.

كما يوضح بالتفصيل كيف يخططون لدعم تحويل التعداد ، والتعامل مع القيم الفارغة ، و camel- vs PascalCasing وما إلى ذلك.

إذا كانت لديك ملاحظات حول أي من هذا ، فيجب عليك ترك تعليقاتك في هذه المشكلة أو طلب السحب.

lemire واو ، هذا رائع حقًا. Simdjson هو في الواقع سريع للغاية.

هل توجد أي فرصة لتطبيق معيار تسلسل JSON الخاص بـ TechEmpower ؟ (أعلم أنه سيكون هناك الكثير من العمل)

لقد وجدت هذه التطبيقات: في TechEmpower repo وفي ASP.NET repo .

KPixel هذا هو التسلسل ، أليس كذلك؟ في هذه الأثناء Simdjson هو محلل ... ما لم أكن في حيرة من أمري حول المصطلحات ، هذه الأشياء تسير في اتجاهين معاكسين؟

خطأي. افترضت وجود جزء خاص بإلغاء التسلسل (والذي سيستخدم المحلل اللغوي).

هل سيكون System.Text.Json حزمة كتلة صلبة قياسية .net؟ أو أنه شيء متاح فقط لـ .net core 3.0؟

أعتقد أن قابلية الاستخدام يجب أن تكون محور تركيز حزمة JSON الجديدة أيضًا. إحدى الميزات التي أعتقد أنه يجب توفرها هي دعم التحقق من صحة مخطط JSON. رسوم Newtonsoft لذلك. هذا شيء أساسي بدرجة كافية بحيث يجب توفيره في النظام الأساسي مجانًا ، كما كان الحال بالنسبة للتحقق من صحة مخطط XML.

@ jemiller0 انطباعي هو أن التحقق من صحة XML كان نوعًا ما عبارة عن حقيبة مختلطة وأن مخطط JSON قد تم اعتماده في الكلمة الحقيقية. يمكنك دائمًا إجراء فحص مخطط من خلال مكتبة كخطوة إضافية ... بالتأكيد ، قد يتضمن ذلك الحصول على ترخيص برنامج ، ولكن هل هي مشكلة كبيرة؟

lemire نعم ، إنها

لم أر مطلقًا مخطط json المستخدم في العالم الحقيقي. ومع ذلك ، لا ينبغي أن يكون جزءًا من التنفيذ الذي تمت مناقشته هنا. ولا يجب تطبيق أي من الميزات والمراوغات الأخرى في json.net هنا أيضًا. لا ينبغي أن يكون هذا أكثر من تنفيذ سريع وخفيف الوزن للغاية. إذا لم تكن راضيًا عن حاجتك إلى ترخيص لـ json.net لدعم التحقق من json. قم بإنشاء تطبيق مفتوح المصدر خاص بك واجعله متاحًا مجانًا.

تضمين التغريدة

لدي فضول حقًا: هل تقدم لغات البرمجة الأخرى دعم مخطط JSON في مكتبتها القياسية؟

الهدف من هذه المكتبة هو أن تكون مكتبة عالية الأداء ومنخفضة المستوى للعمل مع JSON. أي شيء ليس كذلك ، والذي يتضمن معظم الميزات الأكثر تقدمًا من JSON.NET وأيضًا مخططات JSON ، لن يكون جزءًا من هذا.

إذا كنت تريد التحقق من مخطط JSON ، فأنت حر في تنفيذ مدقق أعلى هذه المكتبة ، والذي يجب أن يكون منخفض المستوى بما يكفي للسماح لك بالقيام بذلك.

لا أعتقد أن الحصول على التحقق من صحة مخطط JSON في مكتبة قياسية له علاقة بأن النظام الأساسي قادر على المنافسة أم لا.

الهدف من هذه المكتبة هو أن تكون مكتبة عالية الأداء ومنخفضة المستوى للعمل مع JSON. أي شيء ليس كذلك ، والذي يتضمن معظم الميزات الأكثر تقدمًا من JSON.NET لن يكون جزءًا من هذا.

باستثناء أنه سيتضمن أيضًا ميزات عالية المستوى ، مصممة لتكون بديلاً عن Newtonsoft.

poke يحق لك الحصول على أي رأي تريده ، مثلي تمامًا. يتم استخدام XML في كل مكان. ومن ثم ، قامت Microsoft ، بحق ، بتضمين دعم التحقق من الصحة مع .NET Framework. الآن ، أصبح JSON رائجًا ويتم استخدامه في كل مكان ، في ملفات التكوين ، وواجهات برمجة تطبيقات الويب ، وما إلى ذلك. ومن المنطقي أن يكون لديك نفس المستوى من الدعم لـ JSON كما كان مدعومًا تاريخيًا لـ XML. أنا شخصياً أجد أنه من السخف بعض الشيء أن تستخدم Microsoft برامج طرف ثالث لكي يبدأ ذلك. يجب أن يكون ذلك سمة أساسية للمنصة.

lemire سأقوم قريباً بفحص بايثون. عند هذه النقطة ، سأكتشف إما أنها مضمنة أو مضمنة كحزمة قابلة للتثبيت بسهولة. سأكون مندهشا للغاية إذا لم يكن كذلك. أنا أبحث في استخدام NJsonSchema لما أحتاجه الآن. مباشرة من الجزء العلوي ، يمكنك رؤية الوثائق سيئة. نعم ، الاعتماد على مكتبات الطرف الثالث التي قد تكون ذات جودة أو لا تكون فكرة رائعة لأشياء مثل العمل مع JSON وهو موجود في كل مكان ويستخدم في كل مكان. دعنا نعتمد جميعًا على البرامج التجارية أو حزم الجهات الخارجية بدون وثائق. يجب ألا تتطابق .NET فقط مع الأنظمة الأساسية الأخرى مثل Python. يجب عليهم التغلب عليهم من خلال توفير برامج عالية الجودة مع التوثيق المناسب خارج الصندوق. كان هذا تاريخيا كيف يعمل. حيث أعمل ، يكره الجميع .NET ويريد إجباري على استخدام Python. لا أعرف ما إذا كنت قد لاحظت ذلك ، ولكن المزيد والمزيد من الناس يهجرون السفينة ويتحولون إلى بايثون. أخبر مديري أنني بحاجة إلى شراء ترخيص للقيام بشيء بسيط مثل التحقق من أن JSON لن يطير. ما سأحصل عليه في المقابل يتم استجوابي حول سبب رغبتي في استخدام .NET في المقام الأول. بغض النظر عن حقيقة أن هذا لمشروع مفتوح المصدر حيث لا يمكنك الحصول على ترخيص على أي حال. آمل أن أجد أن NJsonSchema يعمل فقط. أنا فقط أشير إلى إغفال صارخ في إطار العمل الذي يجب أن يكون واضحًا لأي شخص يعمل مع JSON.

أنا أستخدم مخططات JSON في العمل وأنا أفضل أن يكون لدي محلل JSON جيد حقيقي من نصف محلل JSON جيد + مدقق مخطط JSON. أيضا AFAIK JSON Schema هو _draft_ 7 الآن. لذا ، اجعل مخطط JSON كمكتبة خارجية يمكن أن تتطور بسرعة مع المخطط أمرًا منطقيًا بالنسبة لي. سيكون من الجيد وجود مخطط JSON في خريطة الطريق.

تضمين التغريدة

من المنطقي أن يكون لديك نفس المستوى من الدعم لـ JSON كما كان مدعومًا تاريخيًا لـ XML.

يتضمن .Net أيضًا دعم XSLT و XPath. إذا كنت تريد "نفس المستوى من الدعم" ، ألا يعني ذلك أنك ستحتاج أيضًا إلى بعض الإصدارات من تلك لـ JSON؟

ما أحاول قوله هو: يختلف نظام JSON البيئي عن نظام XML البيئي. كلاهما لهما أنماط استخدام مختلفة والتقنيات ذات الصلة لها أرقام استخدام ومستويات توحيد مختلفة. أيضًا ، تمت إضافة XML إلى .Net قبل وجود NuGet أو git أو GitHub. في الوقت الحاضر ، أصبح الاعتماد على مكتبة تابعة لجهة خارجية أسهل بكثير وأكثر قبولًا.

لذا ، لا ، لا أعتقد أنه من المنطقي أن نقول بشكل أعمى "XML كان به هذا ، لذا يجب أن يمتلكه JSON أيضًا".

أيضًا ، التحقق من الصحة هو ببساطة متعامد مع التحليل. سأكون على ما يرام تمامًا مع إضافة دعم التحقق في مرحلة ما (ربما في حزمة أخرى تمامًا). لكنها ليست ضرورية على الإطلاق لدعم التحليل المناسب.

نحن بحاجة إلى طريقة للتحقق الصارم من صحة البيانات في طلبات API REST.
لأننا نحفظ json الذي يأتي من خلال API بدون أخطاء وبعد ذلك لا يمكننا تحليله في JS بسبب الفواصل اللاحقة وما إلى ذلك.

ولماذا لا يمكنك التحقق من صحة هذا الطلب الآن؟

@ phillip-haydon @ freerider7777 أعتقد أن أي محلل JSON لائق يجب أن يلتزم بمواصفات JSON ويرمي الأخطاء (و / أو التحذيرات) عندما لا يتم تشكيل المستند جيدًا (على سبيل المثال ، عندما يحتوي على فواصل لاحقة). هذا أساسي جدًا ولكنه يختلف أيضًا عن التحقق من

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

Microsoft ، واحدة من أكبر شركات تطوير البرمجيات ، ليس لديها أي شخص يعمل على التحقق من الصحة. المحلل اللغوي السريع هو الأهم. سيتيح لك تحليل JSON غير الصحيح بسرعة الضوء. :-) لم يخطر ببال أي شخص أن التحقق السريع من الصحة قد يكون مفيدًا. هذا تمامًا مثل ASP.NET Core ، وهو ترقية سريعة إلى نماذج الويب.

ولماذا لا يمكنك التحقق من صحة هذا الطلب الآن؟
@ phillip-haydon في كود وحدة التحكم مع مثل json:
ModelState.IsValid == صحيح

🤦‍♂️

يمكنك إجراء التحقق استنادًا إلى مخطط json بالفعل باستخدام NSwag + System.ComponentModel.DataAnnotations :

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

أتفق مع lemire ، هناك اختلاف في التحقق من صحة بنية JSON والتحقق من صحة JSON مقابل المخطط. ليس لدي شك في أن Microsoft قد قضت وقتًا وجهدًا لتنفيذ الأول بشكل صحيح ... هذا الأخير يمثل حالة أساسية ولا أعتقد أنه يتناسب مع التصميم العام لمكتبة JSON هذه. أنا متأكد من أنهم أوضحوا أن مكتبة JSON هذه مصممة فقط لتوفير تحليل سريع وفعال حسب الضرورة لتشغيل asp.net الأساسية. لم يتم تصميمه ليشمل _extras_ التي تأتي مع محلل newtonsoft. (راجع تعليق poke سابقًا في الموضوع).

لا أعتقد أن حقيقة أنهم لم يتعمدوا تصميم هذا ليأتي مع كل الأجراس والصفارات تجعله منتجًا رديء الجودة.

هل حدث هذا للشحن مع المعاينة 4؟

هل هناك خطط لإنشاء System.Text.Json.Serialization.Policies.JsonValueConverterclass public للسماح باستبدال فئات المحول من Json.net؟

هل سيتم شحن System.Text.Json مع دعم كامل .Net عبر nuget؟ سيكون من الجيد بالتأكيد ضمان التشغيل المتداخل الكامل بالإضافة إلى الاستفادة من إطار العمل الكامل.

تم تغيير System.Text.Json مؤخرًا لإنتاج ثنائيات netstandard2.0 لشحن OOB ؛ https://github.com/dotnet/corefx/pull/37129 :

إذا كان ذلك ممكنًا ، يجب عليك استهداف .NET Core 3.0 والحصول على واجهات برمجة تطبيقات System.Text.Json المضمنة في العلبة. ومع ذلك ، إذا كنت بحاجة إلى دعم netstandard2.0 (على سبيل المثال ، إذا كنت مطور مكتبة) ، فيمكنك استخدام حزمة NuGet المتوافقة مع netstandard2.0.

يستفيد من الإطار الكامل

ما هذه مرة أخرى؟ 🤔

تضمين التغريدة

أفضّل أن يكون نوغيت بنكهات متعددة ، بما في ذلك الإطار الكامل (4.5 أو أي حد أدنى مقبول) ، ومعيار ، ونواة. يفضل استخدام التجميعات الصندوقية.

تشير المشكلة المرتبطة أعلاه إلى هذه الحزمة ، لكنها غير مدعومة:

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

هل هناك حزمة معتمدة حاليًا؟

أفضّل أن يكون نوغيت بنكهات متعددة ، بما في ذلك الإطار الكامل (4.5 أو أي حد أدنى مقبول) ، ومعيار ، ونواة.

لماذا تفضل ذلك؟ إذا لم تكن هناك حاجة إلى أهداف متعددة ، أي أن جميع واجهات برمجة التطبيقات المستخدمة هي جزء من المعيار ، فمن الأفضل أن يكون لديك هدف واحد فقط 😊

هل هناك حزمة معتمدة حاليًا؟

لا أعتقد أنه تم شحنه بعد. تم دمج العلاقات العامة منذ أيام. اعتادت هذه الحزمة أن تكون مشروعًا مجتمعيًا تم نقله الآن إلى MS.

khellang يعتمد الأمر على التفاصيل - كنت أدلي ببيان عام.

إذا كان على الإصدار القياسي الصافي حذف أي شيء من الإصدار الأساسي الصافي الذي يمكن أن يكون ممكنًا مع الإصدار الكامل الصافي ، فإنني أفضل أن تكون جميع النكهات الثلاثة متاحة. أعتقد أن نفس المنطق العام هو البيان الأصلي من المشكلة المرتبطة أعلاه حول تفضيل المستخدمين لاستهداف الإصدار الوارد في المربع.

عند إضافة مرجع إلى حزمة nuget ، سيتم اختيار النكهة الأكثر ملاءمة تلقائيًا. لذا ، فهي ليست مشكلة كبيرة. إذا كانت المكتبة المستهلكة هي معيار صافي ، فسيتم اختيار النكهة القياسية الصافية.

بلدي التفضيل العام للفي النكهات المربع هو أنني عندما goto definition المصادر، أحصل على decompiled. إذا قمت باستخدام goto definition على صافي المكتبات القياسية ، فأنا عادةً ما أرى فقط مصادر الروتين التي تطرح استثناءات NotImplemented .

يستفيد من الإطار الكامل

ما هذه مرة أخرى؟ 🤔

تستخدم العديد من التطبيقات .NET Framework ليس لأنها تريد تمامًا الابتعاد عن .NET Core ولكن لأن .NET Core ليس خيارًا. أستخدم NET Core عندما يكون خيارًا ؛ عندما يتعين عليّ استهداف إصدارات Windows أقل من Windows Server 2012 (الإصدار الأدنى من .NET Core 3.0) ، يجب أن أستخدم .NET Framework. بقدر ما أنا متأكد من أنه كان قرارًا مؤلمًا للغاية بإسقاط الدعم لنظام التشغيل Windows Server 2008 R2 والإصدارات الأقدم ، فهو قرار مؤلم للغاية لكل شركة تدفع للعملاء باستخدام خوادم لا يرغبون في ترقيتها / غالبًا ما يتم إعادة إنشائها من نقطة الصفر فقط حتى نتمكن من استخدام أداة أحدث قليلاً.

لن يكون أحد أكثر سعادة مني إذا كان بإمكاني التوقف عن استخدام .NET Framework غدًا ، ولكن حتى مع وجود جميع فرص WPF و Windows Forms في .NET Core 3.0 وما بعده ، فإن Microsoft تجعل ذلك استحالة عملية من خلال سياسات الدعم الخاصة بها. لقد حاولت مناقشة هذا الأمر مع أي شخص يستمع إلى Microsoft ، ولكن للأسف ، لم أتلق بعد بريدًا إلكترونيًا يقر بأن الرسالة قد تم تسليمها.

JesperTreetop ناهيك عن عدم وجود دعم LTS لإصدارات NET Core التي تستحق الاستخدام لمؤسسة ؛) آمل أن نحصل على دعم LTS على 3.x - بصفتي مهندس .NET الخاص

marksmeltzer يُظهر يقدم .NET 5 من الأمس أن NET Core 3.1 سيكون LTS ومن المقرر إصداره في نوفمبر 2019.

هل يدعم جهاز التسلسل JSON الجديد أنواع F #؟

rliman جيدًا حاليًا لا يدعم Guid أو Enum ، لذا فإن أمامه طريق طويل لنقطعه. أوافق على أن الدعم الكامل لأنواع خيارات F # التي تشبه C # nullable يجب أن يكون مطلوبًا IMHO

أنا شخصياً أعتقد أن هذا حل مستعجل لقرار تصميم معماري سيئ. كان يجب أن يتم ذلك منذ فترة طويلة .... الآن سوف يسبب الكثير من الألم في كل مكان ... من مطوري المكتبات إلى مطوري المؤسسات.

لا توجد طريقة سهلة "لتنعيم" هذه "الميزة" الجديدة.

هذا هو مرض التصلب العصبي المتعدد يحاول حل مشكلة تسببوا فيها في المقام الأول. والآن على الجميع دفع الثمن.

مع NET Core يبدو من البداية أن العربة صغيرة إلى "سريعة" ... قد تحتاج هذه الطريقة "الرشيقة" الخالصة إلى الإبطاء قليلاً والسماح للجميع بالتقاط أنفاسهم.

يبدو أنه مع ASP.NET Core ، أصبحت هذه "الميزات" (تغيير التغييرات) هي الوضع الطبيعي الجديد.

في رأيي ، إن ASP.NET Core في حاجة ماسة إلى إعادة صياغة عملية التصميم المعماري الخاصة بهم. لأنه مرارًا وتكرارًا استمر في عمل ميزات "سنصلحها لاحقًا".

لقد كنت أطور مع ASP.NET Core منذ أن كان في الإصدارات التجريبية المبكرة ... وهو تحسن كبير على .NET.

لكن يجب على فريق MS التوقف للحظة والتفكير في كيفية معالجة المشكلة الحقيقية هنا: قرارات التصميم المعماري المتسرعة وغير المتسقة.

ما عليك سوى الرجوع وقراءة المواضيع الأخرى ... يبدو أنها سمة متكررة.

لذلك قد يكون الوقت قد حان للجلوس وإعادة التفكير في أفضل نهج هو صنع منتج أكثر استقرارًا.

قد لا تكون Classic .NET قوية مثل Core ... لكنها مستقرة جدًا ومتسقة منذ الإصدار 2.0.

رأيي فقط.

مرحبًا suncodefactory ،
أتذكر منذ بعض الوقت عندما صرخ ppl في ms لعدم استخدام مكتبات مفتوحة المصدر ، والآن يتم إلقاء اللوم عليهم للقيام بذلك: D
من وجهة نظري ، كانت واجهة برمجة تطبيقات Aspnet / core MVC مستقرة جدًا منذ mvc1 / 2! السبب في استقرار aspnet منذ 2.0 هو أنه لم يتغير / يتحسن على الإطلاق 😄.
لكي نكون صادقين إذا كنت تستخدم ميزة متقدمة لمكتبة التسلسل ، فلديك فرصة لإعادة التفكير فيها وربما التعامل مع المشكلة بهيكل بيانات مناسب للمهمة ، بدلاً من التظاهر بأن جميع المسلسلات تدعم جميع ميزات اللغة ، imo it's المشكلة الخاطئة لحلها ، والطريقة الخاطئة لاستخدام التسلسل.
الوضوح والتوافق مع الإصدارات السابقة والامتدادات المستقبلية هي ما يدفع dtos القابل للتسلسل ، والمقايضات المختلفة جدًا المستخدمة في كائنات منطق العمل الشائعة (تلك الخاصة ، لها الكثير من الوظائف ، إلخ ..)

نحن قادرون على نقل الخدمات المصغرة من net framework إلى Linux (net core) دون أي جهد تقريبًا من فرق pruduct. لا أعرف ما الذي تتحدث عنه يا رفاق. تقوم Microsoft بعمل رائع في الإسراع بتنفيذ مثل هذه التغييرات التي طال انتظارها.

مرحبًا suncodefactory ،
أتذكر منذ بعض الوقت عندما صرخ ppl في ms لعدم استخدام مكتبات مفتوحة المصدر ، والآن يتم إلقاء اللوم عليهم للقيام بذلك: D

بالنسبة لي ، فإن النقطة لا تتعلق بمكتبات الطرف الثالث ... إنها تتعلق بالتصميم المعماري الذي يفتقر في هذه الحالة بالذات أو مجرد خطأ واضح.

كما أنني لم أتحدث مطلقًا عن asp.net الكلاسيكية ... كنت أتحدث عن .NET Framework 2.0. والسبب في استقراره لم يكن بسبب عدم وجود تحسينات كما تدعي كذباً (حيث أن. net الأساسية يعتمد على .NET 4.6.1). كان السبب هو أنه تم التخطيط له وتصميمه جيدًا.

بالنسبة لمدى جودة نواة aspnet مقابل الكلاسيكية asp.net mvc التي لا علاقة لها بهذا الخيط المحدد.

يدور هذا الخيط حول تغيير مفاجئ توشك MS على شحنه مرة أخرى دون التفكير فيه بدقة.

نحن قادرون على نقل الخدمات المصغرة من net framework إلى Linux (net core) دون أي جهد تقريبًا من فرق pruduct. لا أعرف ما الذي تتحدث عنه يا رفاق. تقوم Microsoft بعمل رائع في الإسراع بتنفيذ مثل هذه التغييرات التي طال انتظارها.

مثل هذه التغييرات لا يجب أن تحدث إطلاقاً ..... إذن أنت سعيد بتغيير التغييرات؟

والقول إن فريق asp.net الأساسي كان يقوم بعمل رائع في تغييرات الشحن ليس صحيحًا بكل بساطة.

لقد طورت مع asp.net core منذ الإصدار التجريبي 3 وأنا متأكد من أن عملية التصميم المعماري غير متوفرة.

بالنسبة لمدى جودة نواة asp.net مقابل الكلاسيكية ... ليس لدي أي اعتراضات لأنني أعتقد جيدًا أنها أفضل من الكلاسيكية.

ولكن لمجرد أن asp.net الأساسية أفضل من الكلاسيكية لا يعني أنها تقوم بعمل رائع في تصميم الهندسة المعمارية. هذان الموضوعان مختلفان تمامًا.

هل يمكننا قصر هذه المناقشة على وظيفة JSON في .NET Core 3 من فضلك؟

مثل هذه التغييرات لا يجب أن تحدث إطلاقاً ..... إذن أنت سعيد بتغيير التغييرات؟

لذلك لا ينبغي إجراء تحسينات؟ لماذا أنت حتى مبرمجًا إذا كنت لا تريد أن تتطور البرامج وتنمو وتتحسن؟

تضمين التغريدة

مثل هذه التغييرات لا يجب أن تحدث إطلاقاً ..... إذن أنت سعيد بتغيير التغييرات؟

آه ، هيا ، تجعل الأمر يبدو وكأنه "كسر التغيير" يعني أنه عليك إلغاء مشروعك والبدء من نقطة الصفر.

كم عدد التغييرات المعطلة التي يمكنك حسابها في ASP.NET Core 2.x / 3.0 والتي تتطلب أكثر من

  • الرجوع إلى حزمة مختلفة
  • استخدام مساحة اسم مختلفة
  • تغيير أكثر من 5 أسطر من التعليمات البرمجية
  • إزالة سطرين من التعليمات البرمجية (أي خصائص من فئات الخيارات)

؟؟

تضمين التغريدة

يدور هذا الخيط حول تغيير مفاجئ توشك MS على شحنه مرة أخرى دون التفكير فيه بدقة.

كيف يكون هذا في الواقع تغيير _كسر_؟ تعد JSON APIs الجديدة مجموعة جديدة تمامًا من واجهات برمجة التطبيقات التي تم تقديمها في .NET Core والتي لا تزيل أو تكسر أي عناصر موجودة. نعم ، سترى الأشياء والمكتبات تتحول إليها في النهاية لأنها توفر فرص تحسين مختلفة ، لكنك لست مضطرًا لتطبيق ذلك على التعليمات البرمجية الخاصة بك.

عند الحديث عن ASP.NET Core على وجه الخصوص ، على الرغم من أن _ "لا علاقة له بهذا الخيط المحدد" _ ، فلديك الخيار لمواصلة استخدام Newtonsoft.Json إذا كنت تعتمد على بعض ميزاته الأكثر تقدمًا. نعم ، سيتعين عليك تغيير بعض الكود لذلك لجعله يعمل ، لكنني لا أعتبر ذلك كسرًا حقًا بالنظر إلى أنه عليك فقط القيام بذلك إذا كنت تريد بالفعل الترقية إلى الإصدار الجديد. هذا هو الشيء الجميل الآن: لديك المزيد من الخيارات.

إذا لم يعجبك هذا لأي سبب من الأسباب ، فلا تتردد في التمسك بـ .NET Framework وهو مجموعة ميزات معروفة ومستقرة وثابتة. سيبقى ذلك لفترة طويلة ، لذا يمكنك الاعتماد تمامًا على ذلك. ولكن من فضلك توقف عن استخدام هذا الموضوع لنشر جدول أعمالك المناهض للأشياء الجديدة عندما _ "لا علاقة لذلك بهذا الموضوع المحدد" _.

سؤالان من مستخدم EF Core.

  1. هل يدعم System.Text.Json المراجع الدائرية؟ يمكن أن تحدث المراجع الدائرية في بيانات EF Core حيث توجد روابط تنقل في كلا الاتجاهين بين الفئات. تتعامل Json.NET مع هذا بإعدادات مثل
    c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
  2. مع ظهور فصول على غرار DDD مع المستوطنين الخاصين والمُنشئين الخاصين ، هل يمكن System.Text.Json إلغاء تسلسل هذه الأنواع من الفئات؟

JonPSmith IMO لا يهم. يجب ألا تقوم مطلقًا بتسلسل كيان بشكل مباشر. يجب عليك إجراء تسلسل للإسقاط. هذا يتجنب المراجع الدائرية ، ولا يعرض جميع البيانات ، خاصة عند إضافة المزيد من الخصائص إلى الكيان الذي قد ينتهي به الأمر إلى أن يكون حساسًا.

JonPSmith : كلتا حالتي استخدام Imho غير صالحة من وجهة نظر أفضل الممارسات و DDD.

  1. لم أشاهد مطلقًا أفضل الممارسات التي توصي بإلغاء تسلسل الكيانات مباشرةً (باستثناء أمثلة البرنامج التعليمي الأكثر بساطة). دائما ما تأتي المراجع الدائرية بتكلفة. يتطلب تتبع الكائنات التي تمت معالجتها بالفعل ، وهذا يعني: تخصيصات الذاكرة ودورات وحدة المعالجة المركزية الإضافية. لكن أحد أهداف البريد لمكتبة JSON الجديدة هو تجنب عمليات تخصيص الذاكرة هذه تمامًا
  2. غير صالح أيضًا ، نظرًا لأنك لا تتسلسل مطلقًا إلى نموذج مجال ، لا سيما عندما تحصل على البيانات عبر طلب ويب مثل مكالمة WebApi. في DDD ، يجب عليك دائمًا العمل مع الأحداث / الأوامر ، وإرسال الأمر إلى تطبيق الويب الخاص بك ، والحصول (وتجفيف) الكيان من المستودع (عبر تعيين ORM أو EventSourcing) ، قم بتطبيق الأمر ، استمر في ذلك.

علاوة على ذلك ، فإن واجهة برمجة تطبيقات JSON الجديدة مخصصة لسيناريوهات الأداء العالي. بالنسبة إلى كل شيء آخر تحتاج فيه إلى مجموعة ميزات غنية ، فلا يزال يتعين عليك (ويجب) استخدام 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 ليست مكتبة بطيئة بأي معايير ، لكنها تحقق توازنًا بين الأداء وثراء الميزات والدعم لمجموعة كبيرة من سيناريوهات المستخدم. لا تحتاج مكتبة JSON الجديدة من Microsoft إلى القيام بذلك ، نظرًا لوجود JSON.NET. لذلك يمكنه التركيز على التعامل مع الأساسيات المطلقة بأقصى أداء.

لطالما امتلكت .NET حل تسلسل JSON الخاص بها في System.Runtime.Serialization.Json ، ولكن في عالم .NET Core عالي الأداء ، لا يعد حلًا جيدًا جدًا. أنا بالتأكيد لا أريد أن يتم استدعاؤه للتحقق من بيانات الاعتماد في كل طلب وارد. مكتبة JSON الجديدة ، مع معالجة بيانات UTF-8 الحديثة والحد الأدنى من التخصيصات ، موضع ترحيب كبير.

ستظل قادرًا على الرجوع إلى Newtonsoft.Json في تطبيقك ، والاستمرار في استخدامه كخط أنابيب لإلغاء التسلسل / التسلسل لبيانات الطلب / الاستجابة كما كان من قبل. ومن الآن فصاعدًا ، ستتمكن من القيام بذلك دون القلق بشأن الإصدار الذي يعتمد عليه إطار العمل الأساسي. هذا فوز للجميع.

شكرا @ فيليب هايدون و @ TsengSR على أفكارك. كنت أسأل عما إذا كانت هذه الميزات سيتم دعمها وأنت تقول إنها ليست كذلك ، والتي تفهمها وتقبلها. سأستمر في استخدام Json.NET للحالة التي أحتاج فيها إلى إجراء تسلسل / إلغاء تسلسل فئات EF Core.

بالمناسبة. لدي سبب وجيه لإجراء تسلسل / إلغاء تسلسل فئات كيانات EF الأساسية لأنماط DDD. لدي مكتبة تحتوي على ميزة أسميها Seed from Production والتي تسمح للمطورين بأخذ لقطة من البيانات من قاعدة بيانات الإنتاج ، وإخفاء هوية أي بيانات خاصة ، ثم إنشاء قاعدة بيانات جديدة مع اللقطة.

كنت بحاجة إلى هذه الميزة لأحد عملائي وبدلاً من الكتابة لهم فقط قمت بتضمينها في مكتبتي مفتوحة المصدر عميلي أن يدفع لي مقابل ذلك).

هل هناك خطة لدعم [DataContract] و [DataMember] والأصدقاء؟

اليوم هذه طريقة لتحديد كيفية تسلسل الأنواع / إلغاء التسلسل (مثل اسم الحقل) بطريقة لا تجلب التبعية إلى أي مكتبة تسلسل للمشروع الذي تستخدمه.

يأخذ JsonNamingPolicy سلسلة فقط لذلك لا توجد طريقة لفحص سمات العضو.

أهلا.
لقد حاولنا للتو تحويل خدماتنا الصغيرة إلى معاينة DotNet core 3 6 ولا يمكننا إلغاء تسلسل أنواع المراجع الثابتة لدينا: فئة ذات خصائص ثابتة (بدون محددات) ومنشئ واحد فقط لتعيين جميع الخصائص. يتعامل Json.net بشكل صحيح مع هذه الفئات.
هل هذه مشكلة الحاجة System.Text.Json API أم أن هذه خطة لدعمها؟
شكرا لردودكم

شكرا @ khellang.
تم التخطيط للدعم بالفعل ولكن ليس للإصدار 3.0.
يبدو أنه من الممكن الاستمرار في استخدام Json.net مع DotNet core 3 ولكني لا أعرف كيفية القيام بذلك (إضافة مرجع الحزمة ليس كافياً). هل هناك طريقة للقيام بذلك؟

agjini :

C# services.AddControllers() .AddNewtonsoftJson()

شكرا لشباب مساعدتكم.
إنها تعمل !
فاتني دليل الترحيل حيث تم شرح كل شيء:

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

IMO json.net نصف مخبوز وجعله الافتراضي (أي لـ signalr) الذي يكسر الكود الحالي سابق لأوانه.

من ناحية أخرى ، يعد الترحيل من .NET Core 2.2 إلى 3.0 ترقية رئيسية للإصدار وحتى إذا لم يتبع فريق .NET Core الإصدار الدلالي بدقة ، أتوقع أن تتعطل الأشياء أثناء الترقية من إصدار إلى آخر دون تغييرات صريحة (مثل إضافة مكتبة Newtonsoft بشكل صريح في خط الأنابيب)

الختام نظرًا لأن هذا إعلان وليس مشكلة

على الرغم من أن المجتمع لديه الكثير من الأصوات ضد التحسين ، كإطار عمل جديد عالي الأداء ، فإن السرعة السيئة غير مقبولة.

أعلم أنه قد قيل من قبل ، لكني أود أن أضيف أمنيتي أيضًا.

سيكون رائعًا حقًا إذا كان لدينا أشياء غير قابلة للتغيير. أعلم أنه من الممكن إضافة Json.NET إلى MVC-Pipeline ولكن في حالتي فشلت جميع اختباراتي لأنني أستخدم ReadAsAsync<> والذي يتم تنفيذه الآن في مكان ما في تبعية الأقران Microsoft.AspNet.WebApi.Client وهذا يعتمد على System.Text.Json

نحن نوفر مكتبة .NET Standard Class للعملاء حتى يتمكنوا من استخدام مكتبتنا للعمل على أي نظام أساسي يدعم .NET Standard. نحتاج إلى استخدام System.Text.Json في مكتبة الفصل لدينا. ما هي خطة دعم System.Text.Json في .NET Standard؟

alsami

سيكون رائعًا حقًا إذا كان لدينا أشياء غير قابلة للتغيير.

هل تحتاج فقط إلى القدرة على منع الآخرين من تحويرها أم أنك تحتاج أيضًا إلى القدرة على إنشاء حالات جديدة مع استبدال الأجزاء بذكاء (مثل المجموعات غير القابلة للتغيير و Roslyn)؟ إذا كنت بحاجة إلى الأول ، فنحن نوفر لك واجهات برمجة تطبيقات JsonDocument DOM القادمة.

@ mwoo-o

ما هي خطة دعم System.Text.Json في .NET Standard؟

إنه متاح كحزمة NuGet لـ .NET Standard 2.0: System.Text.Json .

تضمين التغريدة

شكرا. متى سيتم تضمين System.Text.Json هذا في .NET Standard SDK؟
هل سيتضمن الإصدار القياسي من .NET 3.0 (أو بعض إصدارات الإصدارات اللاحقة الأخرى) حزمة System.Text.Json؟ هل سيحدث ذلك في إصدار إنتاج .NET Core 3.0 SDK؟

تضمين التغريدة

هل هناك أي خطط لجعل طريقة Deserialize تعمل مع PipeReader؟ أو أضف طريقة Patch التي يمكن استخدامها في سيناريوهات البث حيث لا تتوفر لدينا جميع البيانات عندما نبدأ في إلغاء التسلسل.

فيما يلي نسخة مبسطة من واجهة برمجة التطبيقات المقترحة:

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)
{
      ...            
}

تضمين التغريدة

القدرة على منع الآخرين من تحويرها

هذا فقط حاليا. هو في الحقيقة مجرد "كائنات نقل البيانات". أخبار رائعة!

@ mwoo-o

شكرا. متى سيتم تضمين System.Text.Json هذا في .NET Standard SDK؟
هل سيتضمن الإصدار القياسي من .NET 3.0 (أو بعض إصدارات الإصدارات اللاحقة الأخرى) حزمة System.Text.Json؟ هل سيحدث ذلك في إصدار إنتاج .NET Core 3.0 SDK؟

لا يوجد .NET Standard SDK. NET Standard هو سطح واجهة برمجة تطبيقات متاح على جميع الأنظمة الأساسية المدعومة. يمكنك شحن System.Text.Json في أي تطبيق يتم تشغيله ويستهدف الأنظمة الأساسية المدعومة التي يدعمها .NET Standard ، راجع دعم تنفيذ .NET .

تضمين التغريدة

لا يوجد .NET Standard SDK. NET Standard هو سطح واجهة برمجة تطبيقات متاح على جميع الأنظمة الأساسية المدعومة.

حسنًا ، هناك نوع مشروع يسمح لك باستخدام واجهات برمجة التطبيقات. أعتقد أن @ mwoo-o يسأل عما إذا كانت لدينا خطط لإضافة System.Text.Json إلى .NET Standard. الجواب لا. حسنًا ، نحن نخطط الآن لترك هذا ليكون حزمة NuGet.

إنه لأمر فظيع. عدد قليل جدًا من الوظائف ليتم تطبيقها في المشروع.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات