WCF: बनाम सदस्य संपत्ति पर DataMember विशेषता

Question

WCF में, क्या एक संपत्ति

private int m_SomeValue; 

[DataMember] 
public int SomeValue { 
    get {...} 
    set {...} 
} 

बजाय के एक सदस्य चर

[DataMember] 
private int m_SomeValue; 

public int SomeValue { 
    get {...} 
    set {...} 
} 

पर DataMember विशेषता लागू करने के बीच का अंतर है?

Answer 1

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

Answer 2

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

हालांकि यदि आप अपने accessors में किसी विशेष तर्क यह है कि मान दिया संशोधित कर सकते है (ToUpper() एक स्ट्रिंग ing, उदाहरण के लिए), तो आप एक अलग मूल्य लौट आते हैं।

Answer 3

जब तक आप Name मार्कर का उपयोग करें, अनुबंध है क्षेत्र या संपत्ति का उपयोग किया जाता है या नहीं।

[DataMember(Name="SomeValue")] 
private int m_SomeValue; 

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

Answer 4

व्यक्तिगत रूप से मैं केवल संपत्ति का उपयोग करता हूं और सदस्य चर को पूरी तरह से हटा देता हूं। यानी

[DataMember] 
public int SomeValue 
{ get; set; } 

संपत्ति दृश्यों के पीछे एक सदस्य चर को निष्पक्ष रूप से तैयार करेगी।

Answer 5

यदि निजी int m_SomeValue पर [डेटामेम्बर] जोड़ें, तो यह सदस्य क्रमिकरण नहीं हो सकता है, इसलिए इसे सार्वजनिक int SomeValue पर जोड़ना चाहिए।

[डेटामेम्बर]
निजी int m_SomeValue;

सार्वजनिक पूर्णांक SomeValue { प्राप्त {...} सेट {...} }

ऊपर की कोड यदि आप इसे WCF के माध्यम से का उपयोग ग्राहक में मूल्य प्राप्त नहीं हो सकता।

Answer 6

डेटामेम्बर के रूप में गुणों के बजाय फ़ील्ड को चिह्नित करने के अच्छे कारण हैं।

कृपया अधिक जानकारी के लिए इस जाँच: http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html

वैसे: ContractSerializers कि DataMemberAttribute उस पर है किसी भी निजी क्षेत्र को क्रमानुसार होगा केवल पूर्ण विश्वास के माहौल में चल रहा है।आंशिक विश्वास में काम नहीं करता

Answer 7

यह निर्णय आप के उपयोग पर निर्भर करता है सेवा WCF (एक समाधान के लिए ऊपर सूचीबद्ध ब्लॉग की जाँच करें):

1. आप द्वारा खपत आंतरिक सेवा ही नेट प्रणाली, कि शेयर एक ही डोमेन मॉडल।
2. विभिन्न प्लेटफार्मों द्वारा खपत बाहरी सेवा, जो समान डोमेन मॉडल साझा नहीं करती है।

केस 1.

क्रमबद्धता - वस्तु के राज्य बने की प्रक्रिया है। सी # में ऑब्जेक्ट की स्थिति को इसके डेटा फ़ील्ड द्वारा दर्शाया जाता है।

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

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

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

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

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

इसके अलावा, मैं यह उल्लेख करना चाहूंगा कि सिल्वरलाइट निजी क्षेत्रों को \ deserialize नहीं कर सकता है, क्योंकि आप उन्हें प्रतिबिंब का उपयोग करके बाहर से नहीं पहुंच सकते हैं, और आपको उन्हें निजी बनाना होगा और InternalsVisibleToAttribute का उपयोग करना होगा।

प्रकरण 2.

यह कठिन एक है। यहां मुख्य फोकस अंतःक्रियाशीलता है। 99.9% में आपके पास इस मामले में अलग-अलग डीटीओ कक्षाएं होंगी और अधिकतर पुराने ग्राहकों का समर्थन करने के लिए उनमें से कई अलग-अलग संस्करण होंगे। इससे कोई फ़र्क नहीं पड़ता कि आपने डेटामेम्बर को इस पर अटैचमेंट किया है, क्योंकि आप डीटीओ का उपयोग करते हैं। मैं इस परिदृश्य को समझाने से परेशान नहीं हूं, क्योंकि ऐसे बड़े पैमाने पर सिस्टम पर काम करने वाले डेवलपर्स आमतौर पर काफी अनुभवी होते हैं, और वे एसओ पढ़ने को परेशान नहीं करते हैं।