गेटवे डिज़ाइन पैटर्न का उपयोग कब करें

Question

कुछ डिज़ाइन पैटर्न में अपना सिर प्राप्त करने का प्रयास करते समय मैंने एक नमूना चलाया जो मुझे भ्रमित करता है - उम्मीद है कि यह समझाने में कुछ आसान है, और मैं इसे अभी याद कर रहा हूं।

मेरा प्रश्न है "गेटवे" कहां फिट है? यह एक अतिरिक्त डेटा पहुंच बिंदु के रूप में अनावश्यक लगता है।

नमूना कोड तीन वर्गों है -

1. person - वस्तुओं में से प्रत्येक के लिए जिम्मेदार बताते हैं
2. personDAO जो मनुष्य और सेटर तरीके है - जो डेटा है CRUD करने के लिए कहता है।
3. personGateway - जिसमें getAll और getCount हैं - जो डेटा कॉल भी हैं ... ???

मैं पूरी तरह डेटा के लिए एक डीएओ कॉल कर मिलता है, और डीएओ एक वस्तु बनाने के लिए वापस पारित करने के लिए "व्यक्ति" वर्ग का उपयोग करता है - लेकिन क्यों getAll और डीएओ में getCount नहीं डाल ???

इस गेम में "गेटवे" किस लॉजिकल स्थिति को चलाता है?

--- पढ़ने प्रतिक्रियाओं के बाद जोड़ा ---

ठीक है - मैं जाहिरा तौर पर इस जबकि खोज याद है - और यह "मदद" है स्पष्ट - Need some clarification with Patterns (DAO x Gateway) - हालांकि, यह बहुत जावा केंद्रित लगते हैं और यह वास्तव में छोड़ देता है भेद मैं उम्मीद कर रहा था -

मुझे लगता है कि उत्तर यह है कि डीएओ एक "ऑब्जेक्ट" देता है और "ऑब्जेक्ट" एक इकाई है ... संग्रह नहीं। आप एक संग्रह retuning रहे हैं (और यह बहस का मुद्दा है कि अगर आप "चाहिए") तो आप प्रवेश द्वार का उपयोग करना चाहते हैं ... लेकिन कोई परिस्थिति के तहत आप संग्रह के साथ डीएओ ...

Answer 1

गेटवे पैटर्न
मैला चाहिए

एक गेटवे ऑब्जेक्ट उन्मुख डोमेन परत और संबंध-उन्मुख दृढ़ता परत के बीच अर्थपूर्ण अंतर को समाहित करता है।

here से परिभाषित परिभाषा।

आपके उदाहरण में गेटवे को "सेवा" भी कहा जाता है। सेवा परत महत्वपूर्ण है क्योंकि यह एक व्यक्ति इकाई से निपटने में एक उच्च अमूर्तता और अधिक "समग्र" तरीका प्रदान करता है।

इस "अतिरिक्त" परत का कारण किसी अन्य व्यक्ति से जुड़े सिस्टम में अन्य ऑब्जेक्ट्स का कारण है। उदाहरण के लिए, कहें Car ऑब्जेक्ट्स हैं और प्रत्येक व्यक्ति के पास कार हो सकती है। अब, जब हम एक कार बेचते हैं तो हमें "मालिक" फ़ील्ड अपडेट करना चाहिए, आगे आप उस व्यक्ति ऑब्जेक्ट्स (विक्रेता/खरीदार) के लिए ऐसा करना चाहेंगे।

आदेश BuyCarService नए मालिकों अद्यतन करेगा (वस्तुओं कार्यान्वयन युग्मन के बिना) इस "व्यापक" एक OO ढंग से प्राप्त करने के लिए: सेवा डीबी में प्रासंगिक क्षेत्रों अवगत कराने के लिए CarDAO और PersonDAO कॉल करेंगे तो यह है कि डीएओ को एक-दूसरे को "जानना" नहीं होगा और इसलिए कार्यान्वयन को रद्द कर दिया जाएगा।

उम्मीद है कि यह चीजों को स्पष्ट बनाता है।

Answer 2

अधिकांश डिजाइन पैटर्न स्पष्टीकरण कुछ समय या अन्य भ्रमित हो जाते हैं क्योंकि मूल रूप से इसे किसी के द्वारा नामित और समझाया गया था, लेकिन समय के साथ-साथ कई अन्य समान पैटर्न अस्तित्व में आते हैं जिनके समान उपयोग और स्पष्टीकरण होता है लेकिन बहुत कम अंतर होता है। यह सूक्ष्म अंतर तब बहस का स्रोत बन जाता है :-)। गेटवे पैटर्न के संबंध में, यहाँ क्या है मार्टिन Fowler उद्यम अनुप्रयोग architecture.I के कैटलॉग में उल्लेख सीधे here

से उद्धृत कर रहा हूं "गेटवे -। एक वस्तु है कि एक बाहरी प्रणाली या संसाधन के लिए उपयोग समाहित"

दिलचस्प सॉफ्टवेयर शायद ही कभी अलगाव में रहता है। यहां तक ​​कि सबसे शुद्ध ऑब्जेक्ट-ओरिएंटेड सिस्टम को अक्सर ऐसी चीजों से निपटना पड़ता है जो ऑब्जेक्ट्स जैसे रिलेशनल डेटा-बेस टेबल, सीआईसी लेनदेन, और एक्सएमएल डेटा संरचनाओं से निपटने के लिए हैं।

इस तरह के बाहरी संसाधनों तक पहुंचने पर, आपको आम तौर पर उनके लिए एपीआई प्राप्त होगा। हालांकि, ये एपीआई स्वाभाविक रूप से जटिल होने जा रहे हैं क्योंकि वे संसाधन की प्रकृति को ध्यान में रखते हैं। कोई भी जिसे संसाधन को कम करने की आवश्यकता है उसे एपीआई - क्या जेडीबीसी और एसक्यूएल को रिला-टियोनल डेटाबेस या एक्स 3 के लिए डब्ल्यू 3 सी या जेडीओएम के लिए समझने की आवश्यकता है। न केवल यह सॉफ़्टवेयर को समझने में कठोर बनाता है, यह भी संबंध डेटाबेस से कुछ डेटा को किसी बिंदु पर किसी बिंदु पर स्थानांतरित करने के लिए बहुत कठिन बनाता है।

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

Answer 3

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