डेटा मैपर, टेबल डेटा गेटवे (गेटवे), डेटा एक्सेस ऑब्जेक्ट (डीएओ) और रिपॉजिटरी पैटर्न के बीच अंतर क्या है?


133

मैं अपने डिजाइन पैटर्न कौशल पर ब्रश करने की कोशिश कर रहा हूं, और मैं उत्सुक हूं कि इन पैटर्न के बीच क्या अंतर हैं? उन सभी को ऐसा लगता है जैसे वे एक ही चीज हैं - एक विशिष्ट इकाई के लिए डेटाबेस तर्क को एन्क्रिप्ट करते हैं ताकि कॉलिंग कोड को अंतर्निहित दृढ़ता परत का कोई ज्ञान न हो। मेरे संक्षिप्त शोध से उनमें से सभी आमतौर पर आपके मानक सीआरयूडी तरीकों को लागू करते हैं और डेटाबेस-विशिष्ट विवरण को दूर करते हैं।

नामकरण सम्मेलनों के अलावा (जैसे CustomerMapper बनाम CustomerDAO बनाम CustomerGateway बनाम CustomerRepository), यदि कोई हो, तो क्या अंतर है? यदि कोई अंतर है, तो आप एक को दूसरे पर कब चुनेंगे?

अतीत में मैं निम्नलिखित के समान कोड लिखूंगा (स्वाभाविक रूप से, स्वाभाविक रूप से - मैं सामान्य रूप से सार्वजनिक संपत्तियों का उपयोग नहीं करूंगा):

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

और एक CustomerGatewayवर्ग है जो सभी तरीकों के लिए विशिष्ट डेटाबेस तर्क को लागू करता है। कभी-कभी मैं एक इंटरफ़ेस का उपयोग नहीं करता और सभी तरीके ग्राहकग्रेटवे स्टेटिक पर बना देता हूं (मुझे पता है, मुझे पता है, कि यह कम परीक्षण योग्य है) इसलिए मैं इसे कॉल कर सकता हूं:

Customer cust = CustomerGateway.GetCustomerByID(42);

यह डेटा मैपर और रिपॉजिटरी पैटर्न के लिए समान सिद्धांत प्रतीत होता है; DAO पैटर्न (जो गेटवे के समान है, मुझे लगता है?) डेटाबेस-विशिष्ट गेटवे को प्रोत्साहित करने के लिए भी लगता है।

क्या मैं कुछ भूल रहा हूँ? एक ही सटीक काम करने के 3-4 अलग-अलग तरीके होना थोड़ा अजीब लगता है।

जवाबों:


97

आपके उदाहरण की शर्तें; DataMapper, DAO, DataTableGateway और Repository, सभी का एक समान उद्देश्य होता है (जब मैं किसी एक का उपयोग करता हूं, तो मुझे ग्राहक वस्तु वापस मिलने की उम्मीद होती है), लेकिन अलग-अलग इरादे / अर्थ और परिणामस्वरूप कार्यान्वयन।

एक रिपॉजिटरी "एक संग्रह की तरह कार्य करता है, अधिक विस्तृत क्वेरी क्षमता के अलावा" [ इवांस, डोमेन ड्रिवेन डिज़ाइन ] और इसे "मेमोरी फैसेड में ऑब्जेक्ट" के रूप में माना जा सकता है ( रिपॉजिटरी चर्चा )

एक DataMapper "वस्तुओं और एक डेटाबेस के बीच डेटा ले जाता है, जबकि उन्हें एक-दूसरे से स्वतंत्र रखता है और खुद मैपर" ( Fowler, PoEAA, Mapper )

एक TableDataGateway "एक गेटवे (ऑब्जेक्ट जो एक बाहरी सिस्टम या संसाधन तक पहुंच को रोकता है ) एक डेटाबेस टेबल पर जाता है। एक उदाहरण तालिका में सभी पंक्तियों को संभालता है " ( फाउलर, PoEAA, TableDataGateway )

एक डीएओ "अपने डेटा एक्सेस तंत्र से एक डेटा संसाधन के क्लाइंट इंटरफ़ेस को अलग करता है / एक विशिष्ट डेटा संसाधन के एक्सेस एपीआई को एक जेनेरिक क्लाइंट इंटरफ़ेस में एडाप्ट करता है " डेटा एक्सेस तंत्र को डेटा का उपयोग करने वाले कोड से स्वतंत्र रूप से बदलने की अनुमति देता है " ( सन ब्लूप्रिंट )

डेटाबेस इंटरैक्शन की कोई धारणा उजागर करने पर रिपॉजिटरी बहुत सामान्य लगती है। एक डीएओ एक इंटरफ़ेस प्रदान करता है जो विभिन्न अंतर्निहित डेटाबेस कार्यान्वयन को सक्षम करता है। एक TableDataGateway विशेष रूप से एक सिंगल टेबल के आसपास एक पतला आवरण है। DataMapper एक मध्यस्थ के रूप में कार्य करता है जो डेटाबेस ऑब्जेक्ट को स्वतंत्र रूप से डेटाबेस प्रतिनिधित्व (समय के साथ) विकसित करने के लिए सक्षम करता है।


15
सही मायने में DAO और TableDataGateway के बीच और [Fowler, PoEAA] [1] में कोई बड़ा अंतर नहीं है, वे ठीक कहते हैं कि: "[Alur et al।] [2] डेटा एक्सेस ऑब्जेक्ट पैटर्न पर चर्चा करता है, जो एक Table Data Gateway है। .. मैंने एक अलग नाम का उपयोग किया है, आंशिक रूप से क्योंकि मैं इस पैटर्न को अधिक सामान्य गेटवे (466) अवधारणा के एक विशेष उपयोग के रूप में देखता हूं और मैं चाहता हूं कि पैटर्न नाम उसे प्रतिबिंबित करे। " [१]: martinfowler.com/books/eaa.html [२]: books.google.pt/books/about/…
मिगुएल

9
अच्छी बात। मेरी धारणा यह है कि TableDataGateway की PoEAA प्रदत्त परिभाषा DataAccessObject की तुलना में संकरी है। पूर्व एक (संबंधपरक) डेटाबेस तालिका के साथ एक से एक मैपिंग का अर्थ है, जहां एक DAO कई अंतर्निहित गैर-संबंधपरक संसाधनों के लिए एक मुखौटा के रूप में कार्य कर सकता है। DAO में जोर अंतर्निहित डेटास्टोर को बदलने की क्षमता है, TableDataGateway में जोर एकल तालिका पर SQL संचालन का एनकैप्सुलेशन है (जरूरी नहीं कि डेटास्टोर तटस्थ / पोर्टेबल फैशन में)।
पियर्स हिक्की

31

सॉफ्टवेयर डिजाइन की दुनिया में एक प्रवृत्ति है (कम से कम, मुझे ऐसा लगता है) अच्छी तरह से ज्ञात पुरानी चीजों और पैटर्न के लिए नए नामों का आविष्कार करने के लिए। और जब हमारे पास एक नया प्रतिमान होता है (जो शायद पहले से मौजूद चीजों से थोड़ा अलग होता है), यह आमतौर पर प्रत्येक टियर के लिए नए नामों के एक पूरे सेट के साथ आता है। तो "बिजनेस लॉजिक" सिर्फ "सर्विसेज लेयर" बन जाता है क्योंकि हम कहते हैं कि हम SOA करते हैं, और DAO रिपॉजिटरी बन जाता है क्योंकि हम कहते हैं कि हम DDD करते हैं (और उनमें से प्रत्येक वास्तव में कुछ नया और अनूठा नहीं है, लेकिन फिर से: नए नाम एक ही पुस्तक में पहले से ही ज्ञात अवधारणाओं के लिए)। इसलिए मैं यह नहीं कह रहा हूं कि ये सभी आधुनिक प्रतिमान और शब्दांश का मतलब एक ही बात है, लेकिन आपको वास्तव में इसके बारे में बहुत अधिक पागल नहीं होना चाहिए। ज्यादातर ये एक ही पैटर्न हैं, बस अलग-अलग परिवारों से।


4
@MladenMihajlovic, सिर्फ इसलिए कि आप समझ नहीं रहे हैं या सहमत नहीं हैं, इसका मतलब यह नहीं है कि यह उत्तर वैध या सही नहीं है।
साइरफ

2
@MladenMihajlovic कि यह उत्तर क्या कहता है। अंतिम वाक्य इसे गाया जाता है।
साइपर

2
@ क्या ये पैटर्न ज्यादातर एक जैसे होते हैं? नहीं, वे नहीं हैं। गेटवे पैटर्न का कार्यान्वयन रिपॉजिटरी पैटर्न के कार्यान्वयन से अलग है। वे अप्रशिक्षित आंख के समान दिख सकते हैं, लेकिन वे नहीं हैं। इसके अलावा, म्लाडेन मिहाजलोविक ने सही ढंग से कहा, यह उत्तर काफी गलत है। बिजनेस लॉजिक और सर्विस लेयर दो अलग-अलग चीजें हैं।
फ्रेडरिक क्राउटवल्ड 11

1
@ क्रेफ़ यह वास्तव में राय का विषय नहीं है, बल्कि तथ्य है। गेटवे पैटर्न को उनके पोएएए में मार्टिन फाउलर द्वारा तैयार किया गया था, और यह ज्यादातर मुखौटा या एडाप्टर पैटर्न [गोफ] से संबंधित है। अंतर यह है कि गेटवे एक विशेष उपयोग के लिए लिखा गया है और आमतौर पर एक मौजूदा इंटरफ़ेस नहीं है। गेटवे, आमतौर पर, केवल दो ऑब्जेक्ट शामिल करता है, और जिस संसाधन को लपेटा जा रहा है, उसे गेटवे का कोई ज्ञान नहीं है। (जारी है ...)
फ्रेडरिक क्राउटवल्ड

3
यह एक उत्तर की तुलना में अधिक टिप्पणी है।
पेतुर इनगी एगिल्सन

31

एक लंबी कहानी को छोटा करने के लिए डेटा मैपर बनाम टेबल डेटा गेटवे :

  • डेटा मैपर डोमेन मॉडल ऑब्जेक्ट (इकाई) को परम के रूप में प्राप्त करेगा और इसका उपयोग सीआरयूडी संचालन को लागू करने के लिए करेगा
  • तालिका डेटा गेटवे विधियों के लिए सभी परम (प्राप्तियों के रूप में) को प्राप्त करेगा और डोमेन मॉडल ऑब्जेक्ट (एंट्रेंस) के बारे में कुछ भी नहीं जान पाएगा।

    अंत में दोनों इन-मेमोरी ऑब्जेक्ट्स और डेटाबेस के बीच मध्यस्थ के रूप में कार्य करेंगे।


  • 6
    लिंक बासी हो गया है
    imel96


    15

    आपकी एक अच्छी बात है। वह चुनें जिसे आप सबसे अधिक परिचित हैं। मैं कुछ चीजों को इंगित करना पसंद करता हूं जो स्पष्ट करने में मदद कर सकती हैं।

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

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

    तो, आम तौर पर एक मैपर में, आप इनसर्ट, अपडेट, डिलीट और टेबल डेटा गेटवे जैसे तरीके देखते हैं, आपको getcustomerbyId, getcustomerbyName, आदि मिलेंगे।

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

    मैं रिपॉजिटरी पैटर्न का अच्छी तरह से वाकिफ नहीं हूं क्योंकि मुझे अब तक इस्तेमाल करने का मौका नहीं मिला है लेकिन मैं दूसरों के जवाब देख रहा हूं।


    1

    नीचे बस मेरी समझ है।

    TableGateWay / RowDataGateWay : इस संदर्भ में, गेटवे एक विशिष्ट कार्यान्वयन का उल्लेख कर रहा है जिसमें प्रत्येक "डोमेन ऑब्जेक्ट" मैपिंग प्रत्येक "डोमेन ऑब्जेक्ट गेटवे" है। उदाहरण के लिए, यदि हमारे पास व्यक्ति है , तो हमारे पास डोमेन ऑब्जेक्ट पर्सन को डेटाबेस में संग्रहीत करने के लिए एक व्यक्तिगृह होगा । अगर हमारे पास व्यक्ति, कर्मचारी, ग्राहक, आदि हैं, तो हमारे पास व्यक्तिगृह, कर्मचारीगृह और ग्राहक मार्ग होंगे। प्रत्येक गेटवे का उस वस्तु के लिए विशिष्ट CRUD फ़ंक्शन होगा और इसका अन्य गेटवे से कोई लेना-देना नहीं है। यहां कोई पुन: प्रयोज्य कोड / मॉड्यूल नहीं है। गेटवे को आगे RowDataGateway या TableGateway में विभाजित किया जा सकता है, यह निर्भर करता है कि आप "आईडी" या "ऑब्जेक्ट" पास करते हैं। गेटवे की तुलना आमतौर पर एक्टिव रिकॉर्ड से की जाती है। यह आपके डोमेन मॉडल को डेटाबेस स्कीमा से जोड़ता है।

    रिपोजिटरी / डाटामैपर / डीएओ : वे एक ही चीज हैं। वे सभी दृढ़ता परत को संदर्भित करते हैं जो डेटाबेस संस्थाओं को डोमेन मॉडल में स्थानांतरित करते हैं। प्रवेश द्वार के विपरीत, रिपोजिटरी / डेटामैपर / डीएओ कार्यान्वयन को छिपाते हैं। आप नहीं जानते कि व्यक्ति के पीछे एक व्यक्तिगृह है या नहीं। यह हो सकता है, या यह नहीं हो सकता है, आपको परवाह नहीं है। आप सभी जानते हैं कि यह प्रत्येक डोमेन ऑब्जेक्ट के लिए समर्थित CRUD ऑपरेशन होना चाहिए। यह डेटा स्रोत और डोमेन मॉडल को डिकूप करता है।

    हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
    Licensed under cc by-sa 3.0 with attribution required.