asp.net mvc रिपोजिटरी पैटर्न बनाम डीएएल




asp.net-mvc data-access-layer (9)

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

  • विभिन्न मानकों के साथ विशिष्टता परिभाषा का पुन: उपयोग करें ,
  • मौजूदा विशिष्टता उदाहरणों के पैरामीटर (उदाहरण के लिए विशेषज्ञ) में हेरफेर करें ,
  • उन्हें गठबंधन ,
  • किसी भी डेटाबेस पहुंच के बिना उन पर व्यापार तर्क प्रदर्शन करें,
  • और, ज़ाहिर है, उन्हें वास्तविक रिपोजिटरी कार्यान्वयन से स्वतंत्र इकाई परीक्षण

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

specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)

assert that specification200.isSpecialCaseOf(specification100)

specificationAge = new AccountIsOlderThan('2000-01-01')

combinedSpec = new CompositeSpecification(
    SpecificationOperator.And, specification200, specificationAge)

for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
    assert that account.Created < '2000-01-01'
    assert that account.Orders.Count > 200

विवरण के लिए फाउलर के विशिष्टता निबंध देखें (यही वह है जो मैंने ऊपर दिया है)।

एक डीएएल के पास विशेष तरीके होंगे

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

आप देख सकते हैं कि यह कैसे तेजी से बोझिल हो सकता है, खासकर जब से आपको इस दृष्टिकोण के साथ प्रत्येक डीएएल / डीएओ इंटरफेस को परिभाषित करना होगा और डीएएल क्वेरी विधि को कार्यान्वित करना होगा।

.NET में, LINQ क्वेरी विनिर्देशों को लागू करने का एक तरीका हो सकता है, लेकिन विशिष्टता (अभिव्यक्ति) को संयोजित करना घर के उगाए गए समाधान के साथ उतना आसान नहीं हो सकता है। इसके लिए कुछ विचार इस SO प्रश्न में वर्णित हैं।

क्या ये एक ही चीज हैं? रॉब कॉनरी के स्टोरफ्रंट ट्यूटोरियल को देखने के लिए बस समाप्त हो गया और वे समान तकनीक के समान प्रतीत होते हैं। मेरा मतलब है, जब मैं एक डीएएल ऑब्जेक्ट को कार्यान्वित करता हूं तो मेरे पास GetStuff, Add / Delete आदि विधियां हैं और मैं हमेशा पहले इंटरफ़ेस लिखता हूं ताकि मैं बाद में डीबी स्विच कर सकूं।

क्या मैं चीजों को भ्रमित कर रहा हूँ?


Answer #1

यह व्याख्या और संदर्भ के बारे में सब कुछ है। वे बहुत समान या वास्तव में बहुत अलग हो सकते हैं, लेकिन जब तक समाधान नौकरी करता है, तो नाम क्या है!


Answer #2

जो मैं समझता हूं उससे मूल रूप से वही बात हो सकती है - लेकिन नामकरण संदर्भ के आधार पर भिन्न होता है।

उदाहरण के लिए, आपके पास एक दल / दाओ वर्ग हो सकता है जो एक आईरिपोजिटरी इंटरफेस लागू करता है।

दल / दाओ एक डेटा परत शब्द है; आपके आवेदन के उच्च स्तर रेपॉजिटरीज़ के संदर्भ में सोचते हैं।


Answer #3

एक भंडार एक पैटर्न है जिसे कई अलग-अलग तरीकों से लागू किया जा सकता है, जबकि डेटा एक्सेस लेयर की एक बहुत ही स्पष्ट ज़िम्मेदारी है: डीएएल को सीआरयूडी परिचालन करने के लिए अपने डेटा स्टोरेज से कनेक्ट करने का तरीका पता होना चाहिए।

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


Answer #4

मेरी व्यक्तिगत राय यह है कि यह मैपिंग के बारे में है, देखें: http://www.martinfowler.com/eaaCatalog/repository.html । इसलिए भंडार से आउटपुट / इनपुट डोमेन ऑब्जेक्ट्स हैं, जो डीएएल पर कुछ भी हो सकता है। मेरे लिए यह एक महत्वपूर्ण जोड़ / प्रतिबंध है, क्योंकि आप डेटाबेस / सेवा / जो भी अलग लेआउट के साथ एक रिपोजिटरी कार्यान्वयन जोड़ सकते हैं, और आपके पास मैपिंग करने पर ध्यान केंद्रित करने के लिए एक स्पष्ट स्थान है। यदि आप उस प्रतिबंध का उपयोग नहीं करना चाहते थे और मैपिंग कहीं और नहीं कर रहे थे, तो डेटा का प्रतिनिधित्व करने के विभिन्न तरीके होने से उन स्थानों पर कोड को प्रभावित किया जा सकता है, जिन्हें इसे बदला नहीं जाना चाहिए।


Answer #5

एक बड़ा अंतर यह है कि एक डीएओ आपके डोमेन में किसी भी इकाई के लिए दृढ़ता से निपटने का एक सामान्य तरीका है। दूसरी तरफ एक भंडार केवल कुल जड़ों से संबंधित है।


Answer #6

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


Answer #7

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


Answer #8

बाहरी दुनिया में (यानी ग्राहक कोड) भंडार डीएएल के समान है, सिवाय इसके कि:

(1) यह पैरामीटर के रूप में डेटा कंटेनर ऑब्जेक्ट रखने के लिए विधियों को सम्मिलित / अद्यतन / हटाएं प्रतिबंधित है।

(2) पढ़ने के लिए यह एक डीएएल (उदाहरण के लिए GetByPK) या उन्नत विनिर्देश जैसे सरल विनिर्देश ले सकता है।

आंतरिक रूप से यह वास्तविक सीआरयूडी ऑपरेशन करने के लिए डेटा मैपर लेयर (उदाहरण के लिए इकाई फ्रेमवर्क संदर्भ इत्यादि) के साथ काम करता है।

रेपोजिटरी पैटर्न का क्या मतलब नहीं है: -

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

उम्मीद है की यह मदद करेगा!





data-access-layer