ऑब्जेक्ट दृढ़ता शब्दावली: 'रिपोजिटरी' बनाम 'स्टोर' बनाम 'संदर्भ' बनाम 'रेट्रिवर' बनाम (...)

Question

मुझे यकीन नहीं है कि किसी प्रोग्राम की डेटा एक्सेस परत को डिज़ाइन करते समय डेटा स्टोर कक्षाओं का नाम कैसे दिया जाए (दाल)।

(डेटा संग्रह वर्ग, मैं एक वर्ग है कि स्मृति में एक मौजूदा वस्तु को पढ़ने के लिए, या एक में स्मृति वस्तु लागू करने के लिए जिम्मेदार है मतलब है।)

यह उचित लगता है एक डेटा की दुकान वर्ग के नाम पर दो चीजों के अनुसार:

• यह किस प्रकार की वस्तुओं को संभालता है;
• चाहे वह लोड हो और/या ऐसी वस्तुओं को जारी रखे।

⇒ एक वर्ग है कि Banana वस्तुओं को लोड करता है जैसे कहा जा सकता है BananaSource।

मुझे नहीं पता कि दूसरे बिंदु के बारे में कैसे जाना है (यानी Source उदाहरण में बिट)।

• भंडार: मैं अलग संज्ञाओं जाहिरा तौर पर सिर्फ इतना है कि उद्देश्य के लिए इस्तेमाल देखा है यह बहुत ही सामान्य लग रहा है। क्या यह कुछ पढ़ता है-/लिखने योग्य है?
• स्टोर: ऐसा कुछ ऐसा लगता है जो संभावित रूप से लेखन पहुंच की अनुमति देता है।
• संदर्भ: बहुत सार लगता है। मैंने इसे LINQ और ऑब्जेक्ट-रिलेशनल मैपर (ओआरएम) के साथ देखा है।
  पीएस (कई महीने बाद): यह शायद उन कंटेनरों के लिए उपयुक्त है जिनमें "सक्रिय" या अन्यथा पर्यवेक्षित वस्तुएं होती हैं (कार्य पैटर्न की इकाई दिमाग में आती है)।
• रेट्रिवर: केवल पढ़ने के लिए कुछ लगता है।
• स्रोत & सिंक: शायद वस्तु दृढ़ता के लिए उपयुक्त नहीं है; डेटा धाराओं के साथ एक बेहतर फिट?
• पाठक/लेखक: अपने इरादे में काफी स्पष्ट है, लेकिन मेरे लिए बहुत तकनीकी लगता है।

क्या ये नाम मनमानी हैं, या क्या प्रत्येक के पीछे व्यापक रूप से स्वीकार्य अर्थ/अर्थपूर्ण मतभेद हैं? अधिक विशेष रूप से, मुझे आश्चर्य है:

• केवल-पढ़ने वाले डेटा स्टोर के लिए कौन से नाम उपयुक्त होंगे?
• केवल-लिखने वाले डेटा स्टोर के लिए कौन से नाम उपयुक्त होंगे?
• अधिकतर पढ़ने-योग्य डेटा स्टोरों के लिए कौन से नाम उचित होंगे जिन्हें कभी-कभी अपडेट किया जाता है?
• अधिकतर लिखने वाले केवल डेटा स्टोर के लिए कौन से नाम उचित होंगे जिन्हें कभी-कभी पढ़ा जाता है?
• क्या कोई नाम सभी परिदृश्यों को समान रूप से फिट करता है?

Answer 1

जैसा कि किसी ने अभी तक सवाल का जवाब नहीं दिया है, इस दौरान मैंने जो निर्णय लिया है, उस पर पोस्ट करूंगा।

बस रिकार्ड के लिए

, मैं बहुत ज्यादा सबसे डेटा संग्रह कक्षाएं खजाने बुला पर फैसला किया है। सबसे पहले, यह सुझाई गई सूची से सबसे तटस्थ, गैर तकनीकी शब्द प्रतीत होता है, और यह Repository pattern के साथ अच्छी तरह से प्रतीत होता है।

आम तौर पर, "भंडार" अच्छी तरह से फिट करने के लिए जहां डेटा पुनर्प्राप्ति/हठ इंटरफेस निम्न जैसा कुछ कर रहे हैं लगता है:

public interface IRepository<TResource, TId> 
{ 
    int Count { get; } 
    TResource GetById(TId id); 
    IEnumerable<TResource> GetManyBySomeCriteria(...); 
    TId Add(TResource resource); 
    void Remove(TId id); 
    void Remove(TResource resource); 
    ... 
} 

---

एक और शब्द मैं का उपयोग करने पर फैसला किया है प्रदाता है, जो भी "भंडार" पर पसंद करेगा जब भी एक स्थिरता स्टोर से पुनर्प्राप्त होने के बजाय ऑब्जेक्ट्स ऑन-द-फ्लाई उत्पन्न होती है, या जब एक दृढ़ता स्टोर तक पहुंच पूरी तरह से पढ़ने के तरीके में होती है। (फैक्टरी भी उचित होगा, लेकिन अधिक तकनीकी लगता है, और मैं सबसे उपयोगों के लिए तकनीकी शब्दों के खिलाफ फैसला किया है।)

पुनश्च: कुछ समय इस उत्तर लेखन के बाद से से चला गया है, और मैं है किसी और के कोड की समीक्षा करने के लिए काम पर कई मौके थे। एक अवधि मैं इस प्रकार मेरी शब्दावली में शामिल किया है सेवा, जो मैं एसओए परिदृश्यों के लिए आरक्षित कर रहा हूँ: मैं एक FooService है कि एक निजी Foo भंडार या प्रदाता द्वारा समर्थित है प्रकाशित हो सकता है। "सेवा" मूल रूप से इनके ऊपर एक पतली सार्वजनिक-सामना करने वाली परत है जो सेवा प्रतिक्रियाओं के उचित "चंचलता" के लिए प्रमाणीकरण, प्राधिकरण, या समेकन/बैचिंग डीटीओ जैसी चीजों का ख्याल रखती है।