2011-06-08 7 views
7

कई बड़ी मुख्य सारणी के साथ प्रारंभिक प्रोजेक्ट के साथ काम करते समय रिपोजिटरी पैटर्न अच्छी तरह से काम करता प्रतीत होता है।रिपोजिटरी पैटर्न के लिए सबसे अच्छा अभ्यास क्या है - प्रति टेबल रेपो?

हालांकि परियोजना बढ़ने के साथ यह थोड़ा लचीला लगता है। मान लें कि आपके पास बहुत सारी बाल सारणीएं हैं जो मुख्य तालिका से लटकती हैं, क्या आपको प्रत्येक तालिका के लिए एक भंडार की आवश्यकता है?

उदा।

CustomerAddress रिकार्ड निम्न है बच्चे टेबल:

-> काउंटी

-> देश

-> CustomerType

यूआई पर, 3 लटकती सूचियों प्रदर्शित करने के लिए की जरूरत है, लेकिन यह उपर्युक्त सारणी में से प्रत्येक के लिए एक भंडार लिखना थोड़ा कठिन हो जाता है जो ड्रॉपडाउन के लिए डेटा का चयन करता है।

क्या ऐसा करने का सबसे अच्छा अभ्यास/अधिक प्रभावी तरीका है?

एक उदाहरण के रूप में कहें कि आपके पास एक मुख्य ग्राहक एड्रेस रिपोजिटरी है जो मुझे लगता है कि 'कुल रूट' है जो बेस रेपो इंटरफेस से मुख्य सीआरयूडी ऑपरेशंस प्राप्त करता है।

पहले मैंने कुल रूट को छोटा कर दिया है और सीधे इस तरह के तालिकाओं के संदर्भ में चला गया है।

उदा।

public Customer GetCustomerById(int id) 
{ 
    return Get(id); 
} 

public IEnumerable<Country> GetCountries() 
{ 
    return _ctx.DataContext.Countries.ToList(); 
} 

आदि ...

लेकिन कभी कभी यह सही नहीं लग रहा करता है, जैसे देशों ग्राहक का हिस्सा नहीं हैं, लेकिन मैं जैसे मैं बिना कुछ पर यह हमले करने की जरूरत महसूस हो रहा है प्रत्येक तालिका के लिए रिपो के ज़िलियन बनाएं। प्रति टेबल एक रेपो निश्चित रूप से मेरे लिए सही प्रतीत नहीं होता है।

+0

अच्छी तरह से। imho a 'country' को नष्ट नहीं किया जाएगा क्योंकि आप 'ग्राहक एड्रेस' हटाते हैं। मुझे लगता है कि यह बढ़ना जारी रहेगा। यह एक बच्चा कुल नहीं है। – jgauffin

+0

ओआरएम के साथ भंडार से बचें;) http: // ayende।कॉम/ब्लॉग/3 9 55/रिपोजिटरी-है-द-न्यू-सिंगलटन – fex

उत्तर

0

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

1) इंटरफ़ेस लिखें कोई विशेष तरीके (आम तौर पर इन प्रश्नों कर रहे हैं)

2 उपयोग करने के लिए) उन कार्यान्वयन

मैं नहीं है जरूरी ऐसा करना चाहते हैं लिखने जब सब मैं प्राप्त करना चाहते हैं या उन देशों की सूची को आबाद करने के लिए कुछ सरल प्रकार है एक बूंद यदि आपके पास 10 संदर्भ प्रकार सारणी हैं तो प्रयास के बारे में सोचें।

मैंने जो करने का फैसला किया वह सरल रेपो नामक एक नई कक्षा थी जिसे आईएसआईम्प्लेरियो इंटरफ़ेस के साथ बनाया गया था जो 1-2 विधियों का खुलासा करता है। जबकि मैं आमतौर पर रेपो I/f वर्ग से IQueryable इंटरफ़ेस का पर्दाफाश करना पसंद नहीं करता, मुझे यहां पर कोई फर्क नहीं पड़ता क्योंकि मैं प्रदान की गई लचीलापन चाहता हूं। मैं बस एक 'क्वेरी()' विधि का पर्दाफाश कर सकता हूं जो लचीलापन हुक प्रदान करता है। ऑर्डरिंग, या फ़िल्टरिंग के लिए मुझे इसकी आवश्यकता हो सकती है।

जब भी किसी सेवा को कुछ साधारण डेटा का उपयोग करने की आवश्यकता होती है, तो ISimple < टी> इंटरफ़ेस पास किया जाता है, जहां टी तालिका/वर्ग है।

अब मैं डेटा के इन साधारण टुकड़ों के लिए इंटरफ़ेस/कक्षा बनाने की आवश्यकता से बचता हूं। कोई विचार करता है?

0

सबसे पहले आपके द्वारा पोस्ट किया गया कोड रिपोजिटरी पैटर्न नहीं है। इंटरफेस की तरह संग्रह कहां है? यदि यह कुल है तो यह केवल कुल प्रकार को वापस कर रहा है।

रिपोजिटरी पैटर्न विभिन्न प्रकारों का चयन करने में सक्षम होने पर अधिक लचीलापन प्रदान नहीं करता है। रिपोजिटरी पैटर्न एक संग्रह इंटरफ़ेस (डालें/जोड़ें/अपडेट/हटाएं/प्राप्त करें/आदि) का पालन करता है, स्मृति स्मृति में मिररिंग करता है, और यह आमतौर पर केवल प्रकार पर पुनर्प्राप्त होता है। तो यदि आप रिपोजिटरी पैटर्न का उपयोग करना चाहते हैं तो आपको सभी ग्राहक एड्रेस का चयन करना होगा और फिर * देशों को फ़िल्टर करना होगा। मैं सुझाव दूंगा कि आप एक अलग पैटर्न पर जाएं, जो अधिक लचीलापन उर्फ ​​डीएओ की अनुमति देता है।

यदि इन चीजों को हमेशा ग्राहक एड्रेस के माध्यम से बनाए रखा जा रहा है, तो पैटर्न स्विच करें और एक डीएओ कक्षा बनाएं जो आपको अन्य प्रकार की चीजों के लिए कुछ अन्य गेटर्स प्रदान करे।


एक अधिक सामान्य टिप्पणी पर, जरूरत के लिए निर्माण।

कभी भी अंधाधुंध भंडार वर्ग नहीं बनाते हैं, यह एक रखरखाव दुःस्वप्न है। एक बार जब मैं एक प्रति रेपो के लिए बहस करता हूं तो वह होता है जब आप चीजों की तरह सीएमएस कर रहे होते हैं, और सब कुछ बनाने में सक्षम होने की आवश्यकता होती है।

उदाहरण:

तो तुम एक CustomerAddress जो एक साथ एक ग्राहक और एक देश बाँधती है, लेकिन आप कुछ अन्य प्रक्रिया है कि देश CRUD करने में सक्षम होने की जरूरत है की है। नतीजतन आपको * देश में हेरफेर करने के लिए भंडार की आवश्यकता है और यदि आप DRY का पालन कर रहे हैं तो आप देशों में हेरफेर करने के लिए डुप्लिकेट तर्क नहीं चाहते हैं। आपके पास एक ग्राहक उत्तरदायी होगा जो देश भंडार का उपयोग करता है।

+0

क्षमा करें मैंने अपना कोड नमूना अपडेट किया है। – jaffa

+0

@jaffa मुझे कोई बदलाव नहीं दिख रहा है? – Nix

+0

मैंने अपने GetCustomerById को रेपो से एक ठोस ऑब्जेक्ट वापस करने के लिए फ़ंक्शन हस्ताक्षर बदल दिए हैं और वह देश संग्रह संग्रह है। – jaffa

2

मैं निश्चित रूप से प्रति तालिका एक भंडार नहीं बनाऊंगा। इसके विपरीत: मैं एक सामान्य भंडार को परिभाषित करता हूं जो प्रत्येक तालिका के लिए काम करता है। ऐसा करके आप स्वयं को बहुत से कोड को सहेजते हैं, और जब आप उस वर्ग पर IQueryable लागू करते हैं, तो यह आपको उस पर LINQ क्वेरीज़ का उपयोग करने की अनुमति देगा, और आप अपने ओ/आरएम फ्रेमवर्क को एक अमूर्तता के पीछे छुपा सकते हैं, जो आपको प्रभावी रूप से लिखने की अनुमति देता है यूनिट परीक्षण मैंने इस पर एक लेख लिखा, Faking your LINQ provider देखें।

+0

मैं कक्षा के लिए पहले से ही एक मूल भंडार वर्ग लागू कर रहा हूं, लेकिन मुझे अभी भी प्रत्येक तालिका के लिए आई/एफ के साथ एक विशेष रेपो क्लास बनाना है। मुझे समझ में नहीं आ रहा है कि मैं देश के किसी भी तरह से देश के एक सूची को कैसे पास कर सकता हूं मॉडल को किसी भी तरह लागू करने के बिना मॉडल? – jaffa

+0

यदि आप जिस आलेख को इंगित करते हैं, उसे देखते हैं, तो आप देखते हैं कि मैं वर्क क्लास की एक इकाई को परिभाषित करता हूं जिसमें सभी रिपॉजिटरीज गुणों के रूप में रखती हैं। एक नया भंडार जोड़ना मतलब है कि काम की इकाई में एक नई संपत्ति जोड़ना, एक नई भंडार वर्ग नहीं जोड़ना। – Steven

0

प्रश्नकर्ता के own answer पर प्रतिक्रिया: यह मुझे समझ में नहीं आता है; हालांकि यह संभव है कि आपके पास अभी भी एक अच्छा उपयोग केस था, मैं इसका पालन नहीं कर रहा हूं। अंक 1 और 2 ... यदि आपको विशेष तरीकों की आवश्यकता है, तो ऐसा लगता है कि वे अपने स्वयं के रेपो में हैं। प्वाइंट 2: हाँ, इसे कार्यान्वयन की आवश्यकता है।

रेपो के बीच साझा करना, छोटे रेपो प्रश्न के साथ साझा करना (क्या वह आवश्यक है), मैं इस सवाल/समस्या की सराहना करता हूं, लेकिन इस धागे पर लोगों ने मुझे प्रति रेपो प्रति तालिका के साथ ठीक होने के लिए प्रेरित किया, जिसमें संभावना भी शामिल है 'सेवा परत' रखने के बावजूद, उन्होंने इसका कोई उदाहरण नहीं दिया है, और मैंने अभी तक यह कोशिश नहीं की है (वर्तमान में मेरे अभ्यास, अच्छे या बीमार के लिए, बड़े रिपो शेयर होने या छोटे को तुरंत चालू करना है इसे एक की जरूरत है):

One repository per table or one per functional section?

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