Runtime: سؤال: دعم التسلسل من الآن فصاعدًا. Net Core 1.0

https://github.com/dotnet/corefx/blob/2b15de70c1cf9f585c4878a722de4dbe42b4940b/Documentation/project-docs/porting.md#binary -serialization

مرحبًا joshfree ، نعم للأسف كان هذا هو المستند الذي تسبب في الارتباك. من بين الاقتراحات الموجودة هناك ، يقوم JSON.NET بإجراء تسلسل json ، ويقوم protobuf-net بإجراء تسلسل ثنائي ، ويقوم datacontractserializer بعمل تسلسل xml. المشكلة في ذلك ، إذا كنت أريد إجراء تسلسل ثنائي. بينما تعتبر protobuf-net مكتبة رائعة ، إلا أنها محدودة. من Protobuf-nets repo ، الأنواع المدعومة هي:
فئات مخصصة:
يتم تمييزها على أنها عقد بيانات
لها مُنشئ بدون معلمات
لـ Silverlight: عامة
العديد من الأوليات المشتركة وما إلى ذلك
المصفوفات ذات البعد الواحد: T []
قائمة / IList
القاموس / ID Dictionary
أي نوع يقوم بتنفيذ IEnumerable وله طريقة Add (T)
في الماضي كان هذا على ما يرام لأن binaryformatter كان دائمًا موجودًا ، ولكن لم يعد هذا هو الحال؟ ما هي الطريقة الموصى بها للتسلسل الثنائي للأنواع غير المدعومة بواسطة شبكة protobuf؟ نبنيها بأنفسنا؟
ما زلت مبتدئًا جدًا في كل هذه التقنيات ، لذا فقد أفتقد تمامًا النقطة المتعلقة بشيء ما.

أيضًا ، لا يمكن لأي منهم إجراء تسلسل موثوق للاستثناءات (والاحتفاظ بجميع البيانات ذات الصلة) ، حسب الحاجة ، على سبيل المثال في الحوسبة الموزعة (Azure ...).

تعد نقطة

مرحبًا SamuelCox ، كما أشار دليل النقل

cdrnet و @ RichiCoder1 ، شكرًا لملاحظاتك. كانت هناك مشكلة مفتوحة dotnet / coreclr # 2715 لمناقشة تسلسل الاستثناء. الرجاء إضافة ملاحظاتك هناك. أوافق على أنه من المهم أن تكون قادرًا على إجراء تسلسل للاستثناءات في نظام موزع. حاليًا ، بدون ISerializable على .NET Core ، لا يمكننا إجراء تسلسل للاستثناءات كما نفعل في إطار عمل .NET الكامل.

مرحبًا zhenlan ، ربما كان يجب أن أذكر في الأصل ، السبب الرئيسي الذي يجعلني أريد تنسيق binaryformatter هو (de) تسلسل الاستثناءات ، والفئات المخصصة التي تحتوي على استثناءات.

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

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

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

تأخرت قليلاً في المحادثة ، لكن إليكم سنتي:

أعتقد أنه سيكون من الخطأ الاعتقاد بأن فائدة BinaryFormatter تقتصر على .NET عن بُعد و AppDomains. ما يميز BinaryFormatter (المتقادم) عن نظرائه الأحدث هو قدرته المطلقة على تسلسل كائنات .NET الأكثر غرابة ، بما في ذلك عمليات الإغلاق والأنواع الفرعية والرسوم البيانية الدورية. لا أحد من المسلسلات الأخرى المدرجة في السلسلة الحالية قادرة على القيام بكل هذا. ليس من قبيل المصادفة أن العديد من الأطر الموزعة المتطورة ، بما في ذلك مشاريع Microsoft مثل Prajna و Mobius (المعروف أيضًا باسم SparkCLR) تعتمد على BinaryFormatter من أجل العمل. هذا ليس حصريًا لـ .NET world: يستخدم Spark برنامج Java الثنائي القديم والبطيء المتسلسل لتسلسل عمليات الإغلاق.

هناك متسلسلات أخرى (غير ثنائية التنسيق) تقوم بتكرار قدرات BinaryFormatter ، بما في ذلك مكتبة FsPickler الخاصة بنا والتي يستخدمها إطار عمل mbrace. ومع ذلك ، فقد قامت CoreCLR بإهمال العديد من واجهات برمجة التطبيقات (API) الرئيسية ، إلى الحد الذي أعتقد أن نقل المكتبة إلى CoreCLR هو مسعى غير عملي.

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

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

راجع أيضًا https://github.com/dotnet/coreclr/issues/2715

fwiw، CSLA .NET تعتمد على تسلسل كامل الدقة لأنه يعتمد على مفهوم الكائنات المتنقلة.

عندما جاء Silverlight ولم يكن لديه BinaryFormatter أو NetDataContractSerializer ، _ و_ كان لدينا كل قيود الانعكاس السيئة ، انتهى بنا الأمر إلى تطبيق المسلسل الخاص بنا الذي يستخدم الحد الأدنى من الانعكاس ولا يعتمد على BF أو NDCS.

في عالم ما بعد Silverlight ، تظل المشكلة قائمة ، لأن BF / NDCS غير متاحين بشكل موثوق في UWP و WinRT و .NET Core وما إلى ذلك.

لذلك أعتقد أن هناك حجة يجب أن يتم إجراؤها على وجود مُسلسل كامل الدقة _should_ ، لكنه مفيد حقًا فقط (على الأقل imo) إذا كان موجودًا في جميع أشكال .NET المختلفة.

rockfordlhotkaopinionmachineeiriktsarpalis سعيد لسماع المزيد من الناس يشعر نفسه، على الرغم من أنني أشعر أنه سيكون أكثر إنتاجية إذا قيلopinionmachine أكثر قليلا بأدب، ولكن كل لبلدهم. نظرًا لإغلاق هذه المشكلة ، أتصور أن فريق corefx لم يعد يراقبها. أنصحك بتصحيح مخاوفك على dotnet / coreclr # 2715 كما هو مذكور بواسطة forki

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

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

نظرًا لأنه من المفترض أن يكون coreclr هو إصدار "الخادم" من .net ، فقد تم ترك الكثير من ميزات الخادم على الأرضية.

مثال على ذلك: تقرر ترك StackTrace / StackFrame خارج corefx لأنه تم "إساءة استخدامه" من قبل بعض المطورين ، ولأنه نادرًا ما تم استخدامه (وفقًا لـ MS). أعتقد أنهم عادوا إلى رشدهم بشأن ذلك (بعد الكثير من ردود الفعل العكسية) لكنني أعني حقًا؟ من يفكر في هذه الأشياء؟

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

تضمين التغريدة :-)

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

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

Json.NET + TypeNameHandling.All + PreserveReferencesHandling.All + MemberSerialization.Fields تأخذك تقريبًا إلى هناك. لا توجد FormatterServices.GetUninitializedObject ومع ذلك ، يجب أن يكون المنشئ متاحًا.

لا توجد FormatterServices.GetUninitializedObject

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

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

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

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

لمعلوماتك: يعمل هذا على .NET Core: Type appDomainType = Type.GetType("System.AppDomain"); . ونعم ، يتيح لك القيام بالكثير من الأشياء ....

فقط للقول إننا قمنا بتحسين استجابة خادم الواجهة الأمامية لدينا بنسبة 30٪ ، وتم تقليلها من 12 مركزًا عند التحميل الأقصى إلى مركزين عند التحميل الأقصى ، قللنا حجم ذاكرة التخزين المؤقت redis من 1.7 جيجا بايت إلى 350 ميجا بايت بشكل عام مما أدى إلى تقليل استضافة Azure بنسبة 20٪ (بت) أكثر حقا)

كنت تفكر في ذلك BinaryFormatter!

تم استخدام netdatacontractserializer

لقد جئت إلى هنا أبحث عن إجابات لـ .Net 4.6.1 أبطأ بكثير مع BinaryFormatter.

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

هناك أيضًا قيمة في تصميم مُسلسل كائن بسيط آخر لإطار العمل الأساسي ، وهو أيضًا خفيف الوزن ولكنه أكثر مرونة في التعامل مع مشكلات الأجهزة المتقاطعة وربما عبر الإصدارات

هناك أيضًا مشكلات أمنية على رأس الهشاشة.

blowdart WRT security ، هل تقصد أشياء مثل هذا https://blog.scrt.ch/2016/05/12/net-serialiception/؟

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

migueldeicazablowdartSamuelCox
المسلسلات مطلوبة ليس فقط لإرسال الأشياء ، ولكن حتى أثناء العملية.
المتسلسلات الثنائية ، عندما يتم إجراؤها بشكل صحيح تتفوق على كومة الكائن الأصلي بالكامل تمامًا عندما يتعلق الأمر بتخزين عشرات الملايين من الكائنات قيد المعالجة.
انظر الى هذا:
https://www.infoq.com/articles/Big-Memory-Part-2

هناك حاجة ماسة لواجهات برمجة تطبيقات التسلسل للبرمجة العنقودية العقلانية.
من غير الملائم للغاية النقل الآني لمثيلات الكائن CLR -> text -> CLR ، إنه عبء ضخم.
ربما ليس من الخطأ إخراج BinaryFormatter ، لأنه بطيء جدًا ومخططات البيانات ضخمة ، ولكن
كان هذا هو المسلسل الوحيد في السوق إلى جانب NFX.Slim الذي دعم دلالي تسلسل CLR الكامل.
راجع الرسوم البيانية التفصيلية للسرعة والحجم:
http://aumcode.github.io/serbench/

ISerializable مع عائلة [OnSer / Deser] يجعل الكثير من المعنى للنقل الآني داخل النظام الأساسي.
إنه ليس إلزاميًا ، تمامًا كما هو الحال في NET القديم. لماذا لا تحتفظ به.
على الأقل دعمه في مجموعات معقدة (أي قاموس) ، ليس من الصعب على الإطلاق.

جعل الجميع يستخدمون JSON - فكرة سيئة تمامًا لأنها أبطأ من برنامج التسلسل الثنائي (وليس BinaryFormatter).
يبدو أن الجميع ينشئون تطبيقات شبيهة بتويتر بدون منطق أعمال؟

itadapter لديه اسم واحد

تضمين التغريدة
نعم طبعا. كما هو موضح في الرسوم البيانية أدناه ، على سبيل المثال ، JIL هو أسرع مُسلسل JSON ، ولكن لا يمكن لأي من المسلسلات النصية أن تلمسها ، الثنائية. يعتبر Protobuf سريعًا جدًا على حساب عدم قدرته على دعم تعدد الأشكال الحقيقي والرسوم البيانية المعقدة.

كل ما أقوله هو:

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

مقاييس أداء "شخص نموذجي" ، تعرض المسلسلات الشائعة:
http://aumcode.github.io/serbench/Specimens_Typical_Person/web/overview-charts.htm

فقط في حالة عدم علم أي شخص في هذا الموضوع ، تم توفير برنامج التسلسل الثنائي بما في ذلك ISerializable وما إلى ذلك في corefx
https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Serialization.

zhenlan جزء من عمل NETStandard2.0 أفترض؟

@ RichiCoder1 نعم ، صحيح.

zhenlan رائع!

zhenlan لا يمكنني العثور على سمة Serializable المتوفرة في معاينة Standard. هل أنا فقط أفتقدها؟

justinhelgerson يجب أن يكون هناك.

هل قمت بتثبيت 2.0 Preview1 SDK كما هو موضح في منشور مدونة الإعلان ؟

بعد إنشاء مشروع .NET Core ، هل يمكنك التأكد من احتواء ملف .csproj على <TargetFramework>netstandard2.0</TargetFramework> إذا أنشأت Class Library أو <TargetFramework>netcoreapp2.0</TargetFramework> إذا أنشأت تطبيق Console؟

راجع للشغل ، نظرًا لأن العديد من الأشخاص في هذا الموضوع يهتمون بالمسلسل الثنائي ، فقد تكون مهتمًا بالمناقشة في dotnet / corefx # 19119 ، والتي تدور حول تقليص [Serializable] لـ .NET Core 2.0. يرجى إعلامنا هناك في حال كان لديك أي ملاحظات.

zhenlan شكرا جزيلا

justinhelgerson ،