यह ठीक इस

Question

मेरे साथी डेवलपर से एक की तरह सी # संपत्ति का उपयोग करने के है यहाँ डाटा वर्ग गुण गतिशील डीबी से जानकारी लाने के लिए एक कोड स्निपेट

class Data 
{ 
    public string Prop1 
    { 
      get 
      { 
       // return the value stored in the database via a query 
      } 
      set 
      { 
       // Save the data to local variable 
      } 
    } 

    public void SaveData() 
    { 
      // Write all the properties to a file 
    } 

} 

class Program 
{ 
    public void SaveData() 
    { 
     Data d = new Data(); 
     // Fetch the information from database and fill the local variable 
     d.Prop1 = d.Prop1; 
     d.SaveData(); 
    } 
} 

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

यह अपने अंक हैं

1. लगभग 20 ऐसे गुणों के होते हैं।
2. बचत के अलावा सभी जानकारी प्राप्त करना आवश्यक नहीं है।
3. सभी को लाने के लिए एक उपयोगिता विधि लिखने के बजाय स्वयं असाइनमेंट के बजाय गुणों में एक ही डुप्लिकेट कोड होगा।

क्या यह उपयोग सही है?

Answer 1

मुझे नहीं लगता कि किसी अन्य डेवलपर, जो एक ही कोड के साथ काम करेंगे देखने के लिए खुश हो जाएगा:

d.Prop1 = d.Prop1; 

निजी तौर पर मैं ऐसा कभी नहीं होगा।

डीबी से डेटा लोड करने के लिए संपत्ति का उपयोग करना भी सबसे अच्छा विचार नहीं है। मेरे पास method होगा जो डीबी से स्थानीय चर में डेटा लोड करेगा और फिर आप उस डेटा को संपत्ति का उपयोग कर प्राप्त कर सकते हैं। get/set तर्कसंगत रूप से एक ही डेटा के साथ काम करना चाहिए। डीबी से डेटा प्राप्त करने के लिए get का उपयोग करना अजीब है लेकिन स्थानीय चर के साथ काम करने के लिए set का उपयोग करना है।

Answer 2

गुणों को यथासंभव हल्के वजन वाले होना चाहिए।

जब अन्य डेवलपर्स गुणों का उपयोग कर रहे हैं, तो वे उम्मीद करते हैं कि वे ऑब्जेक्ट के आंतरिक भाग (यानी, पहले ही लोड हो चुके हैं और स्मृति में) हैं।

असली मुद्दा यहां समरूपता का है - संपत्ति प्राप्त होती है और सेट एक दूसरे को दर्पण करना चाहिए, और वे नहीं करते हैं। यह उन डेवलपर्स के खिलाफ है जो आमतौर पर अधिकतर डेवलपर्स की अपेक्षा करते हैं।

डेटाबेस से संपत्ति लोड होने की अनुशंसा नहीं की जाती है - आम तौर पर एक वर्ग को एक विशिष्ट विधि के माध्यम से पॉप्युलेट करेगा।

Answer 3

मेरी राय में, यह एक भयानक डिजाइन है। कुछ "जादू" सामान करने के लिए एक संपत्ति गेटटर का उपयोग सिस्टम को बनाए रखने के लिए अजीब बनाता है। अगर मैं आपकी टीम में शामिल हो जाऊंगा, तो मुझे उन गुणों के पीछे जादू कैसे पता होना चाहिए?

एक अलग विधि बनाएं जिसे इसे व्यवहार किया जाता है।

Answer 4

"सही" अक्सर दर्शक की नजर में होता है। यह भी निर्भर करता है कि आप अपने डिजाइन को कितना दूर या कितना शानदार बनाना चाहते हैं। मैं आपके द्वारा वर्णित डिज़ाइन के लिए कभी नहीं जाऊंगा, यह पीओसीओ पर सीआरयूडी कार्यों के लिए एक रखरखाव दुःस्वप्न बन जाएगा।

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

डेटाबेस के साथ एक आम परिदृश्य छोटे इकाई वर्गों का उपयोग करना है जिनमें केवल गुण होते हैं, और कुछ भी नहीं। एक डीएओ परत डाटाबेस से डेटा के साथ इन पीओसीओ को पुनः प्राप्त करने और भरने का ख्याल रखती है और केवल सीआरयूडी कार्यों को परिभाषित करती है (कुछ जेनरिक के माध्यम से)। मैं ORM मानचित्रण के लिए NHibernate का सुझाव दूंगा। मूलभूत सिद्धांत यहां बताया गया है कि अन्य ओआरएम मैपर के साथ भी काम करता है और explained here है।

कारण, esp। एनआर 1, इसे और अधिक रखरखाव में पुन: सक्रिय करने के लिए मुख्य उम्मीदवार होना चाहिए। डुप्लिकेट कोड और तर्क, जब सामना किया, दृढ़ता से पुनर्विचार किया जाना चाहिए। यदि उपरोक्त गेटोर वास्तव में डेटाबेस डेटा प्राप्त कर रहा है (मुझे आशा है कि मैं इसे गलत समझाऊंगा), जितनी जल्दी हो सके इसे से छुटकारा पाएं।

चिंताओं के विभाजन का अत्यधिक सरल उदाहरण:

class Data 
{ 
    public string Prop1 {get; set;} 
    public string Prop2 {get; set;} 
} 

class Dao<T> 
{ 
    SaveEntity<T>(T data) 
    { 
     // use reflection for saving your properies (this is what any ORM does for you) 
    } 
    IList<T> GetAll<T>() 
    { 
     // use reflection to retrieve all data of this type (again, ORM does this for you) 
    } 
} 

// usage: 
Dao<Data> myDao = new Dao<Data>(); 
List<Data> allData = myDao.GetAll(); 
// modify, query etc using Dao, lazy evaluation and caching is done by the ORM for performance 
// but more importantly, this design keeps your code clean, readable and maintainable. 

संपादित करें:
एक सवाल है कि आप अपने सह कार्यकर्ता से पूछना चाहिए: यदि आप कई डाटा (डेटाबेस में पंक्तियों) है क्या होता है, या जब एक संपत्ति एक जुड़ी क्वेरी (विदेशी कुंजी तालिका) का परिणाम है। Fluent NHibernate पर एक नज़र डालें यदि आप एक परिस्थिति (अनजान) से दूसरे (रखरखाव) में एक चिकनी संक्रमण चाहते हैं जो कि किसी के द्वारा समझने में आसान हो।

Answer 5

यह बहुत भयानक है, आईएमओ।

1. गुणों को त्वरित/उपयोग करने में आसान माना जाता है; अगर संपत्ति के पीछे वास्तव में भारी चीजें चल रही हैं तो शायद इसके बजाय एक विधि होनी चाहिए।
2. एक ही संपत्ति के गेटर और सेटर के पीछे दो अलग-अलग चीजें चल रही हैं, यह बहुत भ्रमित है। d.Prop1 = d.Prop1 एक अर्थहीन स्व-असाइनमेंट की तरह दिखता है, न कि "डीबी से डेटा लोड करें" कॉल।
3. भले ही आपको डेटाबेस से बीस अलग-अलग चीज़ों को लोड करना पड़े, फिर भी इसे बलों को बीस अलग-अलग डीबी ट्रिप होने के लिए; क्या आप सुनिश्चित हैं कि एक ही कॉल में एकाधिक गुण नहीं लाए जा सकते हैं? यह संभवतः प्रदर्शन के अनुसार बेहतर होगा।

Answer 6

यदि मैं आप थे तो मैं एक धारावाहिक/deserialize समारोह लिखना होगा, फिर इन-मेमोरी परिणामों के आसपास हल्के रैपर के रूप में गुण प्रदान करते हैं।

ISerialization इंटरफेस पर एक नज़र डालें: http://msdn.microsoft.com/en-us/library/system.runtime.serialization.iserializable.aspx

Answer 7

यह बहुत के साथ काम करने के लिए कठिन हो सकता है,

आप Prop1 निर्धारित करते हैं, और उसके बाद Prop1 मिलता है, तुम अलग परिणाम जैसे के साथ समाप्त कर सकता है :

//set Prop1 to "abc" 
d.Prop1 = "abc"; 

//if the data source holds "xyz" for Prop1 
string myString = d.Prop1; 
//myString will equal "xyz" 

टिप्पणी आप mystring बराबर करने के लिए "abc" नहीं "xyz" उम्मीद करेंगे के बिना कोड को पढ़ने, यह भ्रामक हो सकता है।

यह गुणों के साथ बहुत कठिन काम करेगा और हर बार जब आप इसे काम करने के लिए संपत्ति बदलते हैं तो बचत की आवश्यकता होगी।

Answer 8

साथ ही इस उदाहरण पर हर किसी ने जो कहा है उससे सहमत हैं, डेटा क्लास में अन्य फ़ील्ड होने पर क्या होता है? यानी प्रोप 2, प्रोप 3 इत्यादि, क्या वे सभी डेटाबेस पर वापस जाते हैं, प्रत्येक बार उन्हें "क्वेरी के माध्यम से डेटाबेस में संग्रहीत मान वापस करने के लिए" एक्सेस किया जाता है।10 गुण 10 डेटाबेस हिट के बराबर होगा। 10 गुणों को सेट करना, 10 डेटाबेस में लिखता है। वह पैमाने पर नहीं जा रहा है।