2008-10-15 9 views
8

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

पिछले वर्ष हमने .NET 1.1 के लिए बना रहे थे, और एक मुश्किल मुद्दा जहां

  • हमारे कोड .NET 2.0
  • एक ग्राहक कुछ सॉफ्टवेयर है कि किसी तरह डिफ़ॉल्ट के रूप में 1.1 सेट के साथ उन्नत पर चलता था में भाग
  • हमारे कोड .NET 1.1 पर चलता था और उसके संग्रहीत राज्य

deserialize करने के लिए यह विशेष रूप से मुद्दा यह है कि विशेष रूप से सॉफ्टवेयर उन्नयन को छोड़कर द्वारा "संकल्प लिया" था असमर्थ था, और एक समस्या नहीं होनी चाहिए अब हम .NET 2.0 ढांचे को लक्षित कर रहे हैं (इसलिए हम संभवतः 1.1 पर नहीं चल सकते हैं)।

यह क्रमशः 2.0 और नए ढांचे के बीच असंगत रूप से बदल सकता है कि क्या संभावना है? यदि हम 2.0.50727 पर हमारे कोड को ठीक करने के लिए <supportedVersion> का उपयोग करते हैं, तो 2.0.50727.1434 और 2.0.50727.nnnn (कुछ भावी रिलीज) के बीच परिवर्तनों की संभावना क्या है? धारावाहिक होने वाली डेटा संरचनाएं मानक कक्षा पुस्तकालयों से सरणी, मानचित्र, तार, et cetera हैं।

इसके अतिरिक्त, क्या यह गारंटी है कि 2.0.50727 ढांचा हमेशा .NET उन्नयन के बाद भी स्थापित किया जाएगा? माइक्रोसॉफ्ट प्रलेखन के लिए पॉइंटर्स स्वागत है।

उत्तर

6

संभावना कम है (लेकिन शून्य नहीं!) कि फ्रेमवर्क संस्करणों के बीच परिवर्तन होंगे। इरादा यह होगा कि आप एक क्लाइंट और सर्वर के बीच संवाद करने के लिए बाइनरी क्रमबद्धता और रिमोटिंग का उपयोग करने में सक्षम होना चाहिए जो विभिन्न ढांचे संस्करणों को चला रहा है। .NET 1.x और 2.0 is a bug के बीच असंगतता जिसके लिए एक पैच उपलब्ध है।

हालांकि बाइनरी क्रमबद्धता में अन्य मुद्दे हैं, विशेष रूप से उस संरचना के संस्करण के लिए खराब समर्थन जो आप क्रमबद्ध कर रहे हैं।उपयोग किए गए उपयोग के मामले से, एक्सएमएल सीरियलाइजेशन स्पष्ट विकल्प है: यदि आप .NET 3.x पर निर्भरता को ध्यान में रखते हैं तो DataContractSerializer XmlSerializer से अधिक लचीला है।

आप गारंटी नहीं दे सकते कि .NET Framework 2.0 हमेशा विंडोज के भविष्य के संस्करणों पर स्थापित किया जाएगा। लेकिन मुझे यकीन है कि माइक्रोसॉफ्ट यह सुनिश्चित करने के लिए कड़ी मेहनत करेगा कि अधिकांश .NET 2.0 ऐप्स .NET 4.x और बाद के संस्करणों पर अपरिवर्तित चलेंगे। मेरे पास इसके लिए कोई संदर्भ नहीं है: ऐसी कोई प्रतिबद्धता किसी भी मामले में केवल विंडोज़ के अगले संस्करण (विंडोज 7) पर लागू होती है।

+1

मैं इनमें से अधिकांश से सहमत हूं, लेकिन मुझे विंडोज 7 बिंदु नहीं दिख रहा है ... मुझे .NET 4.x या Windows के बारे में बड़ी मात्रा में पता नहीं है 7, लेकिन मैं उम्मीद करता हूं कि .NET 4.x Vista और/शायद/XP संगत हो। बेशक, मैं अज्ञानी हो सकता हूं ;- –

+0

मेरा मतलब यह था कि माइक्रोसॉफ्ट विंडोज 7 के साथ .NET 2.0-3.5 और .NET 4.0 दोनों को शिपिंग करने के लिए प्रतिबद्ध हो सकता है, वे आज प्रतिबद्धताओं को बनाने की संभावना नहीं रखते हैं जिसके बारे में संस्करण होंगे ढांचे का विंडोज़ के बाद के संस्करणों के साथ जहाज जाएगा। – Joe

3

आप किस धारावाहिक का उपयोग कर रहे हैं? कई मायनों में, XmlSerializer या DataContractSerializer जैसे एक धारावाहिक आपको कई विवरणों से बफर करते हैं, और सरल विस्तारशीलता विकल्प प्रदान करते हैं। किसी बिंदु पर, एक नया सीएलआर संस्करण निस्संदेह आवश्यक होगा - इसलिए मुझे नहीं लगता कि कोई भी 2.0.50727 के बारे में कोई गारंटी दे सकता है; हालांकि, आपको सुरक्षित अल्पकालिक होना चाहिए। और मैं कम तोड़ने परिवर्तन के लिए आशा करता हूं ...

[एक और जबाब पर अद्यतन निम्नलिखित टिप्पणी]

आप अंतरिक्ष/प्रदर्शन कारणों से एक द्विपदीय प्रारूप चाहते हैं, तो एक और विकल्प एक अलग द्विआधारी serializer उपयोग करने के लिए है। उदाहरण के लिए, protobuf-net सभी .NET वेरिएंट * पर काम करता है, लेकिन बाइनरी प्रारूप (Google द्वारा दिखाया गया) क्रॉस-प्लेटफ़ॉर्म संगत (जावा, सी ++, आदि) है - इसे बहुत पोर्टेबल, त्वरित और छोटा बना देता है।

* = मैंने माइक्रो फ्रेमवर्क पर इसकी कोशिश नहीं की है, लेकिन सीएफ, सिल्वरलाइट, मोनो, .NET 2.0 आदि सभी समर्थित हैं।

4

अंगूठे का नियम आम तौर पर है: एक्सएमएल सीरियलाइजेशन नए ढांचे के संस्करणों में जीवित रहने में सक्षम होना चाहिए और इसलिए दीर्घकालिक संग्रहित किया जा सकता है, लेकिन बाइनरी सीरियलाइजेशन नहीं कर सकता (और इसलिए केवल क्षणिक होना चाहिए)।

+1

उस पर लेने के लिए; बाइनरीफॉर्मेटर इत्यादि/समस्याएं हो सकती हैं ... ऐसे बाइनरी प्रारूप हैं जो डाटा-केंद्रित हैं, टाइप-केंद्रित नहीं हैं, और इस उद्देश्य के लिए "घने xml" के समान माना जा सकता है। "protobuf-net" उनमें से एक है ;- –

2

यदि संगतता चिंता का विषय है, तो ISerializable इंटरफ़ेस वह इलाज हो सकता है जिसे आप ढूंढ रहे हैं। यह इंटरफ़ेस आपको अधिक नियंत्रित करता है कि वस्तुओं को क्रमबद्ध कैसे किया जाता है। अधिक जानकारी के लिए यह article on msdn आज़माएं।

2

मैं दो बातें अन्य उत्तर में जोड़ने के लिए ...

सबसे पहले है, एक कस्टम SerializationBinder के उपयोग आप विरासत धारावाहिक डेटा आयात करने कठिनाइयों के दौर बहुत प्राप्त कर सकते हैं बना रही है।

दूसरा, मुझे किसी भी स्थायी डेटा के लिए विस्तृत इकाई परीक्षण लिखना अनिवार्य है। मैं हमेशा विशेष रूप से दो परीक्षण करता हूं:

  1. राउंड-ट्रिप टेस्ट - क्या आप अपनी ऑब्जेक्ट्स को क्रमबद्ध और deserialize कर सकते हैं और वही चीज़ वापस प्राप्त कर सकते हैं?
  2. विरासत आयात परीक्षण - सुनिश्चित करें कि आपके ऐप के प्रत्येक रिलीज़ संस्करण से निर्यात किए गए क्रमबद्ध डेटा के संस्करण हैं। डेटा आयात करें और जांचें कि सब कुछ अपेक्षित रूप में वापस आता है।
0

उच्च लचीलापन और संस्करण प्राप्त करने के लिए आपको XML का उपयोग करने की आवश्यकता नहीं है।

मैंने साइमन हेविट की ओपन सोर्स लाइब्रेरी का उपयोग किया है, डिफ़ॉल्ट रूप से Optimizing Serialization in .NET - part 2 डिफ़ॉल्ट .NET क्रमबद्धता देखें। यह कुछ स्वचालन प्रदान करता है, लेकिन अनिवार्य रूप से आप धारावाहिक और deserialised जानकारी की धारा को नियंत्रित कर सकते हैं। संस्करण (फ़ाइल) संस्करण को संस्करणित करने के लिए पहले क्रमबद्ध किया जा सकता है और deserialisation समय जिस तरह से जानकारी की धारा का अर्थ है, संस्करण पर निर्भर है।

यह करना काफी आसान है, हालांकि स्पष्ट धारावाहिक/deserialisation के कारण कुछ हद तक कठिन है।

बोनस के रूप में यह 20-40 गुना तेज है और बड़े डेटा सेट के लिए कम जगह लेता है (लेकिन आपके मामले में महत्वहीन हो सकता है)।

संबंधित मुद्दे