दो डेटा स्रोतों के बीच तंग युग्मन को कैसे कम करें

10

मुझे निम्नलिखित वास्तुकला समस्या का उचित समाधान खोजने में थोड़ी परेशानी हो रही है।

में हमारे सेटिंग (नीचे खाका खींचा) हम 2 डेटा स्रोतों, जहां डेटा स्रोत एक प्रकार फू की मदों के लिए प्राथमिक स्रोत है। एक माध्यमिक डेटा स्रोत मौजूद है जिसका उपयोग किसी फू पर अतिरिक्त जानकारी प्राप्त करने के लिए किया जा सकता है; हालाँकि यह जानकारी हमेशा मौजूद नहीं होती है।

इसके अलावा, डेटा स्रोत A का उपयोग टाइप बार की वस्तुओं को पुनः प्राप्त करने के लिए किया जा सकता है। हालाँकि, प्रत्येक बार एक फू को संदर्भित करता है। यहां कठिनाई यह है कि प्रत्येक बार को एक फू का उल्लेख करना चाहिए, यदि उपलब्ध हो, तो डेटा स्रोत बी द्वारा संवर्धित जानकारी भी शामिल है।

मेरा सवाल है: सबसिस्टम 1 और डेटा स्रोत के बीच की चुस्त युग्मन को कैसे हटाया जाए?

architecture

— fstuijt
स्रोत

11

वह एक खूबसूरत स्केच है। आपने इसे आकर्षित करने के लिए किस कार्यक्रम का उपयोग किया?

— मार्सेलो एमडी

मैं यह भी जानना चाहता हूं कि आपने इसे आकर्षित करने के लिए किस कार्यक्रम का उपयोग किया था। कृप्या।

— ट्यूलेंस कोर्डोवा

2

yuml.me वह साइट है जिसका उसने आरेख बनाने की संभावना से अधिक उपयोग किया है।

— जेसन टर्नर

1

नहीं DataSourceAऔर DataSourceBपहले से ही decoupled? DataSourceAदोनों पर निर्भरता है SubSystemA.1और SubSystemA.2, पर नहीं DataSourceB।

— ट्यूलेंस कोर्डोवा

1

@fstuijt नहीं, यह नहीं है। यदि आप SubsystemA.1इसके अलावा किसी अन्य चीज़ का उपयोग करने के लिए संशोधित करते हैं DataSourceB, DataSourceAतो आपको नहीं पता होगा। DataSourceAकेवल परवाह करता है कि SubsystemA.1एक getFoo(id)विधि है। के बीच एक अमूर्त है DataSourceAऔर DataSourceB।

— ट्यूलेंस कोरडोवा

3

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

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

मेरे सिस्टम में, मैंने डोमेन लेयर में दूसरे के किसी भी बच्चे को वस्तु नहीं बनाया; दोनों स्टोर से डेटा का कोई भी उपयोग दो ऑब्जेक्ट इंस्टेंस बनाए रखना चाहिए। न तो किसी के अस्तित्व की गारंटी है, यही कारण है कि मैंने इसे इस तरह से किया; ऐप केवल क्लाउड डेटा, या ऑनसाइट डेटा, या दोनों के साथ काम कर सकता है, अधिक सीमाओं के साथ कम डेटा।

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

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

आप ज्यादातर मामलों में आवश्यक युग्मन को कम कर सकते हैं, जहां से डेटा आता है, ठीक उसी प्रकार के विवरणों को अलग करके। यदि आप एक वेब सेवा से डेटा प्राप्त करते हैं, जो आपको जेनरेट की गई कक्षाओं के उदाहरणों के रूप में दिया जाता है, तो सर्विस क्लास की एक गहरी प्रतिलिपि बनाने के लिए एक कनवर्टर रखें, जिसे आप नियंत्रित करते हैं, जो डेटा को बदलने की जरूरत नहीं है। स्रोत करता है (केवल अगर स्कीमा करता है)।

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

— Keiths
स्रोत

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

— fstuijt

1

फैक्टरी पैटर्न पर कुछ भिन्नता उपयोगी हो सकती है। यदि आपके पास CloudInvoice और SqlInvoice ऑब्जेक्ट (उनके संबंधित डेटा स्रोतों से) हैं और आप एक एकल एकीकृत इनवॉइस बनाना चाहते हैं, तो एक ऐसी फैक्ट्री बनाएं जो दोनों डेटा स्रोतों के बारे में पर्याप्त जानती हो, जो रिकॉर्ड बनाने के प्रत्येक आधे हिस्से को प्राप्त करने के लिए है, और फिर आपके डोमेन वर्ग में जानकारी को मर्ज करता है।

— कीथ्स

4

इससे निपटने का एक तरीका यह है कि एक समग्र डेटा स्रोत बनाया जाए जिसमें दोनों डेटा स्रोतों का डेटा एक ही स्थान पर हो। एक नौकरी स्रोतों में परिवर्तन के लिए जाँच करने के लिए समय पर चलने के हैं Aऔर B, और आपके समेकित डेटा स्रोत में "डेल्टा" लेखन। यह दो कसकर युग्मित डेटा स्रोत को एकल सुसंगत डेटा स्रोत में बदल देगा।

कई चीजें आपको इस दृष्टिकोण को लेने से रोक सकती हैं:

डेटा की मात्रा निषेधात्मक हो सकती है - Aऔर Bअंतरिक्ष आवश्यकताओं को दोगुना करने की आवश्यकता है।
डेटा म्युज़ लाइव हो - स्रोत में डेटा के बदल जाने के बीच की अवधि होगी और एग्रीगेटिंग जॉब ने इसे एग्रीगेटेड स्रोत में प्रचारित किया है।
आपको मूल स्रोतों के साथ डेटा को समेटने की आवश्यकता है - यदि आप इस दृष्टिकोण को लेते हैं तो परिवर्तनों को उनके मूल स्थानों में वापस ले जाने का कार्य बहुत अधिक जटिल हो जाता है।

— dasblinkenlight
स्रोत

मैं सहमत हूँ, एक अमूर्त परत को पेश करना पसंदीदा तरीका है

— neontapir

2

आप डेटा की नकल के बिना एक अमूर्त परत हो सकते हैं।

— smp7d

@ smp7d यह एक अच्छे फ्रंट एंड के पीछे कपलिंग को छिपा देगा; मैंने मान लिया कि आप पहले से ही अपने सिस्टम में ऐसा कुछ कर रहे थे, हालांकि, क्योंकि अन्यथा जटिलता आपके पूरे डिजाइन में फैल जाएगी।

— dasblinkenlight

DB पर्यावरण पर निर्भर करता है कि यह भी एक / अधिक दृश्य के साथ संभाला जा सकता है, डेटा की प्रतिलिपि बनाने की आवश्यकता को हटा रहा है।

— वाल्टर

नहीं DataSourceAऔर DataSourceBपहले से ही decoupled? DataSourceAदोनों पर निर्भरता है SubSystemA.1और SubSystemA.2, पर नहीं DataSourceB।

— ट्यूलेंस कोरडोवा

1

ऐसा लगता है कि शीर्ष स्तर पर दो प्रकार हैं: फू और बार, और आपके पास केवल दो शीर्ष-स्तरीय क्रियाएं हैं: findFoo(...)और findBar(...)। वह I / O लेयर का इंटरफ़ेस है।

डेटा स्रोतों के आपके विवरण का तात्पर्य है कि A पर दो विधियाँ हैं: findFooऔर findBarB पर एक विधि findFooAuxiliaryInformation। में findFooआप ए और बी से जानकारी मर्ज करने के लिए की आवश्यकता होगी

मुझे यकीन नहीं है कि आप किस "तंग युग्मन" का उल्लेख कर रहे हैं। वहाँ दो डेटासेट में निहित तीन डेटा प्रकार हैं: Bar, Foo, और FooAuxData। के बीच युग्मन Fooऔर FooAuxDataइनपुट डेटा में निहित है, और कम नहीं किया जा सकता है। लेकिन यह युग्मन केवल findFooविधि में दिखाई देना चाहिए । वह सबसे अच्छा आप कर सकते हैं। आवश्यकता को एक ही स्थान पर लागू किया जाता है। यदि यह बदल जाता है, तो आपको उस कोड को बदलना होगा।

— केविन क्लाइन
स्रोत

0

आप नहीं कर सकते।

अगर मैं सही तरीके से समझूं, Fooऔर इससे Barआता हूं dsA। Bars से संबंधित हैं Foo।
अधिमानतः, आप नहीं चाहते हैं कि Barएस को सौंपा जाए Foo, जब तक कि Fooउस से पूरक नहीं किया गया Foo.enhancedInfoहै dsB।

Barएस को एस को असाइन करने के लिए आपकी प्राथमिकता Fooआपके तंग युग्मन को बना रही है। मैं इसे "आवश्यकताओं की चुनौती" के रूप में अर्हता प्राप्त करूंगा जो आपको एक विशेष मार्ग के लिए मजबूर कर रहा है।

तो तकनीकी चुनौतियाँ ऐसी हैं जो dsBकिसी भी जानकारी के बारे में नहीं हो सकती हैं Fooऔर जो dsBउपलब्ध भी नहीं हो सकती हैं।

आपको यह तय करने की जरूरत है कि Foo.enhancedInfoवास्तव में वरीयता कितनी कठिन और तेज है। उस आवश्यकता के आधार पर, आप या तो एक Foo+ Barवस्तु प्रदान करने का निर्णय ले सकते हैं , या नहीं। Fooप्रदान की जाने वाली एक गैर-संवर्धित अनुमति केवल तर्क को जटिल करती है और मुझे बताती है कि वरीयता उतनी सख्त नहीं है जितनी यह दिखाई दे सकती है। निर्धारित करें कि किस संस्करण का Foo, Foo.enhancedऔर Barआपका एप्लिकेशन समर्थन कर सकता है और आपके पास अपना अंतिम उत्तर होगा।

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

दूसरा तरीका 'राउंड: फू एस का संबंध बार एस से है

— फ्सटुइज

@fstuijt मैं अपने उत्तर को थोड़ा अद्यतन करूँगा। मौलिक रूप से, यह वही रहेगा। आपको यह तय करने की आवश्यकता है कि आप बार + फू के सर्वर को कैसे करना चाहते हैं।

0

यदि डेटा स्रोत B का डेटा अपने दम पर खड़ा नहीं हो सकता है, तो आप संभवत: यदि संभव हो तो इसे डेटा स्रोत A पर माइग्रेट करना चाहेंगे।

यदि वे स्वतंत्र लेकिन संबंधित हैं, तो आपको डेटा वर्चुअलाइजेशन में देखना चाहिए । यह एप्लिकेशन को अज्ञेय तरीके से डेटा को एक सेट (जब उचित हो) के रूप में व्यवहार करने की अनुमति देगा। आपके प्लेटफॉर्म के आधार पर, संभवतः एक मौजूदा ढांचा / पुस्तकालय होगा जो आपको इसे लागू करने में मदद कर सकता है।

— smp7d
स्रोत