2012-05-31 32 views
7

मुझे डब्लूसीएफ में अपने व्यापार वस्तुओं को परिवहन के लिए कुछ डीटीओ कक्षाएं बनाने की जरूरत है।डीटीओ। गुण या फ़ील्ड?

चूंकि ये केवल कार्यक्षमता वाले डेटा के बैग हैं, क्या कोई कारण है कि मैं केवल फ़ील्ड का उपयोग नहीं कर सकता, या क्या संपत्तियों के रूप में उन्हें ठीक से बेनकाब करने का कोई अच्छा कारण है?

//fields 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int  Id; 
    [DataMember] public string Name; 
} 

//or properties? 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int Id    { get; set; } 
    [DataMember] public string Name    { get; set; } 
} 

उत्तर

4

चूंकि इन नहीं कार्यक्षमता के साथ डेटा का सिर्फ बैग हैं, वहाँ किसी भी कारण से मैं सिर्फ क्षेत्रों

यहां सार्वजनिक क्षेत्रों के खिलाफ कोई मजबूत तर्क हैं उपयोग नहीं कर सकते है। लेकिन यह महसूस करें कि यह केवल इसलिए है क्योंकि डीटीओ के अंदर कोई तर्क (व्यवहार) नहीं है ताकि encapsulation की सामान्य तर्क न हो।

मैं अभी भी गुण पसंद करूंगा लेकिन वे वास्तव में यहां आवश्यक नहीं हैं।

+0

धन्यवाद दोस्तों। निरंतरता के लिए पूरी तरह से गुणों का उपयोग करेंगे। – GazTheDestroyer

0

मैं कभी भी फ़ील्ड का खुलासा नहीं करता, ज्यादातर कंपनियां इसे अपने मानकों में प्रतिबंधित करती हैं। प्रभावी ढंग से आप पूरी तरह से encapsulation फेंक देते हैं। डीटीओ, कुछ और जटिल के एनीमिक प्रस्तुतियां होने के नाते एक अजीब मामला है क्योंकि उनके गुणों में वैसे भी बहुत अधिक ब्रेक encapsulation है। व्यक्तिगत रूप से, मैं गुणों का उपयोग करता हूं क्योंकि वे वही हैं जो वे हैं। यह आपको "गंदे" कार्यक्षमता इत्यादि को लागू करने देता है यदि आपको आवश्यकता है तो यदि आप सीधे फ़ील्ड tweaking कर रहे हैं तो इतना आसान नहीं है।

+0

गुणों के साथ एक समस्या यह है कि यदि किसी संपत्ति के पास संरचना प्रकार है, तो उस संरचना के किसी भी हिस्से तक पहुंचने के लिए पूरी चीज़ की एक अतिरिक्त अस्थायी प्रतिलिपि बनाने की आवश्यकता होगी। एक संरचना क्षेत्र का पर्दाफाश करते समय इस तरह के अपर्याप्त प्रति संचालन आवश्यक नहीं हैं। – supercat

2

DataMember विशेषता सार्वजनिक क्षेत्रों और संपत्तियों दोनों के साथ काम करेगी, इसलिए या तो संभव होगा। हालांकि, मैं गुणों के साथ चिपके रहने की सिफारिश करेंगे।

विशेष रूप से, यदि आप स्टाइलकॉप का उपयोग कर रहे हैं, तो आप rule SA1401 तोड़ देंगे।

इस नियम के अस्तित्व का कारण वास्तव में आपके मामले में लागू नहीं होता है, लेकिन यदि आप निरंतर एकीकरण सर्वर पर निर्माण के हिस्से के रूप में स्टाइलकॉप सत्यापन चला रहे हैं तो यह एक रखरखाव समस्या होगी।

+3

यदि समाधान इन डीटीओ को किसी विशिष्ट स्थान पर रखता है, तो उस स्थान के लिए, इस विशिष्ट नियम पर स्टाइलकॉप ओवरराइड हो सकता है। – Oded

+0

वास्तव में, लेकिन यह अभी भी एक रखरखाव समस्या है जिसे हल करने की आवश्यकता है। – devdigital

1

आप या तो उपयोग कर सकते हैं। चूंकि यह प्रदर्शन को प्रभावित नहीं करता है, इसलिए यदि आप कुछ धारावाहिक ढांचे या इसी तरह के सार्वजनिक क्षेत्रों के साथ काम नहीं करते हैं तो आप संपत्तियों के साथ जाकर सुरक्षित रहेंगे।

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