माइक्रोसो के बीच डीटीओ ऑब्जेक्ट्स साझा करना


15

TL; DR - सेवाओं के बीच POJO लाइब्रेरी साझा करना ठीक है?

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

मेरे मामले में - मैं एक ऐसी सेवा पर विचार कर रहा हूं जो डेटा का एक उद्देश्य बनाती है। मान लेते हैं कि यह ऑब्जेक्ट पीईटी है। यह डेटाबेस इकाई नहीं है, लेकिन कड़ाई से एक पीओजेओ है जो अंतर्निहित डेटा का स्पष्ट रूप से प्रतिनिधित्व करता है। यह POJO वह है जिसे एपीआई ने परिभाषित किया है। मान लें: पालतू - आयु, वजन, नाम, स्वामी, पता, प्रजाति, आदि।

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

सेवा 2 - पेटाओटोर: यह सेवाएं पालतू जानवरों को इकट्ठा करती है और सत्यापन जांच करती है

सेवा 3,4 - अधिक मध्यवर्ती सेवा कॉल

सेवा 5 - उपयोगकर्ता इंटेक्स

ये बहुत मनमानी हैं लेकिन बात सरल है। यूआई या कुछ उपयोगकर्ता-सामना करने वाली सेवा किसी तरह से इस "पीईटी" ऑब्जेक्ट को पेश करना चाहती है। यह एक एपीआई के माध्यम से एक सेवा को कॉल करना चाहिए, जो एक सेवा को कॉल करता है, जो एक सेवा को कॉल करता है, आदि जब तक यह उस सेवा तक नहीं पहुंचता है जो आवश्यक जानकारी एकत्र करता है और रिले वापस शुरू होता है। अंत में UI सेवा में PET ऑब्जेक्ट प्रदर्शित होता है।

यह बहुत आम है - लेकिन अपनी पूर्ण मानसिकता के साथ, हमने हर सेवा में पीईटी वस्तु की नकल की। DRY (खुद को दोहराएं नहीं) सिद्धांत केवल एक सेवा को सम्मिलित करने के लिए लागू होता है और सेवाओं में लागू नहीं होता है, लेकिन बिंदु अभी भी है। यदि हम कोई फ़ील्ड जोड़ते हैं, तो हमें प्रत्येक में POJO की 5 सेवाओं को संशोधित करना होगा।

--OR-- हम पेट-ऑब्जेक्ट्स-लाइब्रेरी प्रदान कर सकते हैं जिसमें एपीआई से कुछ पूजो शामिल है और प्रत्येक सेवा पुस्तकालय पर आयात / निर्भरता कर सकती है। स्वयं सेवा पर कोई निर्भरता नहीं है, लेकिन सिर्फ सामान्य पुस्तकालय है। मुझे यह विचार पसंद है ताकि प्रत्येक सेवा में एक ही प्रकार की वस्तु हो और अपडेट आसान हो। लेकिन मैं भगवान-वस्तुओं के बारे में चिंतित हूं।

क्या समर्थक / चोर की सबसे अच्छी डिजाइन है? डे-कपल रहते हुए समान POJO वर्गों को दोहराने के लिए सेवाओं के बीच डेटा पास करने के लिए आपने क्या किया है?


ईश्वर-वस्तु? en.wikipedia.org/wiki/God_object

@DaiKaixian: निश्चित रूप से आप यह नहीं सुझाव दे रहे हैं कि ओपी एक ईश्वर वस्तु के साथ जाए, क्या आप हैं? यह नियमित रूप से एक विरोधी पैटर्न माना जाता है।
मकोतो

मैं @javaguy के जवाब से सहमत हूं।

और मैं यह भी कहना चाहता हूं, आप विज़िटर-पैटर्न पर विचार कर सकते हैं। en.wikipedia.org/wiki/Visitor_pattern । एक POJO में सभी फ़ील्ड और सेटर / गेट्टर बनाएं, और इसे microservices.If के बीच साझा करें। यदि आप POJO पर कुछ ऑपरेशन अलग-अलग माइक्रो-सर्विस में करना चाहते हैं, तो कुछ विज़िटरक्लास लिखें।

धन्यवाद। इस 'सामान्य पुस्तकालय' के साथ मेरी झिझक यह है कि यह बढ़ेगा। और इसमें ऐसी वस्तुएं होंगी जो केवल 1 और 3 सेवाओं के बारे में देखभाल करती हैं, या 2 और 4, या सभी, या वहां के किसी भी संयोजन। एक प्रकार का सामान्य डीटीओ लाइब्रेरी पैकेज जिसमें सभी डीटीओ हैं चाहे मैं एक विस्टर पैटर्न या सरल डीटीओ पीओजेओ का उपयोग करता हूं या क्या नहीं। क्या यह इन सभी वस्तुओं को शामिल करने के लिए स्वीकार्य है लेकिन इसे यथासंभव सर्वोत्तम बनाए रखने का प्रयास करना है? कम से कम वस्तुओं को किसी भी व्यक्ति को प्रदान किया जाता है, जिनकी उन्हें आवश्यकता होती है यदि वे उनका उपयोग करना चाहते हैं ...

जवाबों:


5

सबसे अच्छा डिजाइन क्या है?

आप बैकएंड सेवाओं (जो विशिष्ट व्यावसायिक तर्क को संसाधित करते हैं) के बीच एक ही Pet डीटीओ ऑब्जेक्ट का पुन: उपयोग कर सकते हैं , लेकिन जब यह प्रस्तुति टियर (उपयोगकर्ता इंटरफ़ेस) की बात आती है, तो आमतौर पर फॉर्मबीन (अतिरिक्त क्षेत्रों के साथ एक अलग बीन) का उपयोग करना एक अच्छा अभ्यास है प्रस्तुति तर्क के लिए) ताकि प्रस्तुति तर्क और व्यावसायिक तर्क के बीच एक स्पष्ट अलगाव हो

यह आवश्यक है क्योंकि सेवाओं को पुन: प्रयोज्य किया जाना चाहिए और एक ही सेवा को कई / अलग-अलग समापन बिंदुओं द्वारा उजागर / पुन: उपयोग किया जा सकता है (जैसे कि फ्रंटएंड या एक अलग वेबबेस सेवा हो सकती है, आदि ..) और उन सभी समापन बिंदुओं में से कुछ अतिरिक्त फ़ील्ड की आवश्यकता हो सकती है जो पॉपुलेटेड होंगे संबंधित नियंत्रकों या परतों (जैसे एडेप्टर) सेवाओं के ऊपर।

डे-कपल रहते हुए समान POJO वर्गों को दोहराने के लिए सेवाओं के बीच डेटा पास करने के लिए आपने क्या किया है?

यदि आप व्यवसाय और वेब स्तरों के बीच एकल बीन का उपयोग करते हैं तो आप व्यावसायिक तर्क के साथ प्रस्तुति तर्क को कसकर जोड़ रहे हैं जो अच्छा अभ्यास नहीं है और आप फ़्रंटेंड में आवश्यकता के लिए सेवाओं को बदलना समाप्त कर देंगे (उदाहरण के लिए, एक अलग दिनांक स्वरूप यूजर इंटरफेस में दिखाया जाएगा)। इसके अलावा, बीन्स भर में डेटा को पॉप्युलेट करने / कॉपी करने की इस प्रक्रिया को बनाने के लिए (जैसे डीटीओ से फॉर्मबीन या वाइसवर्स), आप बॉयलरप्लेट कोड से बचने के लिए अपाचे BeanUtils.copyProperties() या डोजर जैसी लाइब्रेरी का उपयोग कर सकते हैं ।


मैं मानता हूं कि प्रस्तुति परत को आने वाली पेलोड को संभवतः अलग-अलग विशेषताओं के साथ एक प्रस्तुति बीन के रूप में चित्रित करना चाहिए। लेकिन सामान्य तौर पर सभी बैकएंड सेवाओं में समान डीटीओ ऑब्जेक्ट (ओं) का पुन: उपयोग करना ठीक है? हम आम तौर पर इन डीटीओ पैकेजों को केवल उन कुछ सेवाओं के लिए छोटे पैकेजों में अलग करने की कोशिश करेंगे जिनकी उन्हें आवश्यकता है। मैं एक डीटीओ लाइब्रेरी पैकेज के कुछ जंक-ड्रॉअर होने से थका हुआ हूं, जिसमें डीटीओ के कुछ 75+ माइक्रोसर्विस के लिए है जो सभी सेवाओं पर निर्भर करते हैं। जब तक यह ठीक नहीं है क्योंकि यह सिर्फ डीटीओ ऑब्जेक्ट है जो पहली जगह में वैकल्पिक हैं?

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

4

यदि डीटीओ सभी माइक्रोसर्विसेज में एक ही व्यावसायिक इकाई का प्रतिनिधित्व करता है, तो सेवाओं के बीच साझा किया गया केवल एक वर्ग होना चाहिए। यह (लगभग) एक ही वस्तु के लिए डुप्लिकेट कोड के लिए सही नहीं है।


3
माइक्रोसर्विस में डीटीओ को साझा करना एक बुरा सपना है। "क्या यह संस्करण पहले से ही इस क्षेत्र में है? हम शायद?" आप थोड़ी देर के बाद एक असली गड़बड़ के साथ समाप्त हो जाएगा। इस मामले में डुप्लिकेट कोड अच्छा है।
मेजमो

1

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

अब बैकएंड-टू-फ्रंटेंड को देखें और इसके विपरीत मैं पिछली टिप्पणियों से असहमत हूं कि यूआई प्रेजेंटेशन लेयर के रूप में अलग है। यह नहीं!!! यूआई मेरे लिए सिर्फ एक अन्य माइक्रोसेवा है जो ईवेंट का उपभोग और उत्पादन भी करता है।

बैकएंड-टू-फ्रंटएंड दिशा मैं क्या करता हूं कि POJO (dtos) को टाइपस्क्रिप्ट इंटरफेस और एनपीएम में पैकेज करें और उन्हें नेक्सस में भी लोड करें। UI नोड्ज आधारित परियोजना तब खपत करता है और उन का उपयोग करता है। यह यूआई की तरह सेवा है।

फ्रंट-टू-बैकएंड दिशा यूआई के लिए सेवा स्तर की घटनाओं के लिए मैं टाइपस्क्रिप्ट इंटरफेस को परिवर्तित करता हूं और उन्हें पीओजेओ (डीटीओ) में परिवर्तित करता हूं, जार के रूप में पैकेज करता हूं और बैकेंड सेवाओं के लिए उपयोग किए जाने वाले जार के रूप में नेक्सस (या कुछ रेपो) पर अपलोड करता हूं।

इन प्रक्रियाओं को आसानी से CI प्रक्रियाओं (ट्रैविस, गिटलैब सीआई, आदि) द्वारा नियंत्रित किया जाता है।

इस दृष्टिकोण के लिए किसी भी टिप्पणी का स्वागत किया।

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