استقرار تسلسل .NET عبر إصدارات إطار العمل المختلفة

Question

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

في العام الماضي، كنا نبني لـ .NET 1.1، وواجهنا مشكلة صعبة حيث

• تم تشغيل الكود الخاص بنا على .NET 2.0
• قام أحد العملاء بالترقية باستخدام بعض البرامج التي قامت بطريقة ما بتعيين 1.1 كإعداد افتراضي
• تم تشغيل الكود الخاص بنا على .NET 1.1 ولم يتمكن من إلغاء تسلسل حالته المخزنة

تم "حل" هذه المشكلة تحديدًا عن طريق منع ترقية البرنامج المحدد، ولا ينبغي أن تكون مشكلة الآن حيث أننا نستهدف إطار عمل .NET 2.0 (لذا لا يمكننا التشغيل على الإصدار 1.1).

ما هي احتمالية أن يتغير هذا التسلسل مرة أخرى بشكل غير متوافق بين 2.0 والأطر الأحدث؟إذا استخدمنا <supportedVersion> لإصلاح الكود الخاص بنا إلى 2.0.50727، ما هي فرص التغييرات بين 2.0.50727.1434 و2.0.50727.nnnn (بعض الإصدارات المستقبلية)؟هياكل البيانات التي يتم تسلسلها هي المصفوفات والخرائط والسلاسل وما إلى ذلك من مكتبات الفئة القياسية.

بالإضافة إلى ذلك، هل من المضمون أن إطار عمل 2.0.50727 سيتم تثبيته دائمًا حتى بعد ترقيات .NET الإضافية؟نرحب بالمؤشرات إلى وثائق Microsoft.

Answer 1

هناك احتمالات منخفضة (لكنها ليست معدومة!) بحدوث تغييرات بين إصدارات إطار العمل.سيكون الهدف هو أن تكون قادرًا على استخدام التسلسل الثنائي والاتصال عن بعد للتواصل بين العميل والخادم الذي يقوم بتشغيل إصدارات إطار عمل مختلفة.عدم التوافق بين .NET 1.x و2.0 هو خطأ الذي يتوفر التصحيح.

ومع ذلك، فإن التسلسل الثنائي به مشكلات أخرى، خاصة الدعم الضعيف لإصدار البنية التي تجري تسلسلها.من حالة الاستخدام التي وصفتها، يعد تسلسل Xml هو الخيار الواضح:يعد DataContractSerializer أكثر مرونة من XmlSerializer إذا كنت لا تمانع في الاعتماد على .NET 3.x.

لا يمكنك ضمان تثبيت .NET Framework 2.0 دائمًا على الإصدارات المستقبلية من Windows.لكنني متأكد من أن Microsoft ستعمل جاهدة لضمان تشغيل معظم تطبيقات .NET 2.0 دون تغيير على .NET 4.x والإصدارات الأحدث.ليس لدي أي مراجع لهذا:وعلى أية حال، فإن أي التزام من هذا القبيل لن ينطبق إلا على الإصدار التالي من Windows (Windows 7).

Answer 2

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

Answer 3

ما هو التسلسل الذي تستخدمه؟في العديد من الطرق، يقوم برنامج التسلسل مثل XmlSerializer أو DataContractSerializer بعزلك عن العديد من التفاصيل، ويوفر خيارات توسعة أبسط.في مرحلة ما، سيكون إصدار CLR الجديد ضروريًا بلا شك - لذلك لا أعتقد أن أي شخص يمكنه تقديم أي ضمانات بشأن 2.0.50727؛يجب أن تكون آمنًا على المدى القصير.وأتمنى أن تكون هناك تغييرات أقل..

[تم تحديث الملاحظة التالية في رد آخر]

إذا كنت تريد تنسيقًا ثنائيًا لأسباب تتعلق بالمساحة/الأداء، فهناك خيار آخر وهو استخدام مُسلسل ثنائي مختلف.على سبيل المثال، شبكة بروتوبوف يعمل على جميع متغيرات ‎.NET*، ولكن التنسيق الثنائي (الذي ابتكرته Google) متوافق مع الأنظمة الأساسية المتعددة (Java وC++ وما إلى ذلك) - مما يجعله سهل الحمل والسرعة وصغير الحجم.

*=لم أجربه على إطار عمل صغير، لكن CF وSilverlight وMono و.NET 2.0 وما إلى ذلك كلها مدعومة.

Answer 4

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

Answer 5

لدي شيئين لأضيفهما إلى الإجابات الأخرى ...

أولا: الاستفادة من العرف SerializationBinder يمكن أن تساعدك على التغلب على الكثير من الصعوبات في استيراد البيانات المتسلسلة القديمة.

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

1. اختبار ذهابًا وإيابًا - هل يمكنك إجراء تسلسل للكائنات الخاصة بك وإلغاء تسلسلها واستعادة نفس الشيء تمامًا؟
2. اختبار الاستيراد القديم - تأكد من أن لديك إصدارات من البيانات المتسلسلة التي تم تصديرها من كل إصدار تم إصداره لتطبيقك.قم باستيراد البيانات وتأكد من عودة كل شيء كما هو متوقع.

Answer 6

ليس عليك استخدام XML للحصول على مرونة وإصدارات أعلى.

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

من السهل جدًا القيام به ، على الرغم من أنه مملة إلى حد ما بسبب التسلسل / التسلسل الصريح.

كمكافأة، فهو أسرع بمقدار 20 إلى 40 مرة ويستهلك مساحة أقل لمجموعات البيانات الكبيرة (ولكن قد يكون غير مهم في حالتك).