स्प्रिंग ढांचे में बिल्कुल डीएओ और सर्विस लेयर क्या है?

Question

वसंत ढांचे में बिल्कुल डीएओ और सेवा परत क्या है?

मैं सैद्धांतिक उत्तर की तलाश में हूं।

Answer 1

जहाँ तक कोई भेद नहीं है के लिए एक तकनीक प्रदान करता है जैसा कि वसंत का संबंध है। सम्मेलन से आप @Repository और @Service वाली सेवाओं के साथ डीएओ कक्षाओं को चिह्नित कर सकते हैं। इसके अलावा पूर्व कुछ दृढ़ता परत अपवाद अनुवाद करता है।

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

अंत में डीएओ को दृढ़ता से विवरणों से अमूर्त व्यापार तर्क होना चाहिए, आदर्श रूप से व्यवसाय तर्क (सेवाओं) परिवर्तनों के बिना दृढ़ता परत स्विच करने की अनुमति देना चाहिए। दृढ़ता प्रदाताओं (उदाहरण के लिए आलसी लोडिंग) के लीकिंग अमूर्त के कारण यह शायद ही कभी संभव है।

Answer 2

डीएओ - डेटा एक्सेस ऑब्जेक्ट, आपके डेटा संग्रहण (सामान्य डेटाबेस) से कनेक्शन को संभालने के लिए ऑब्जेक्ट है। आपके यहां आपके प्रश्न हैं और डीएओ आपकी सेवाओं को डेटा प्रदान करता है।

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

Answer 3

डीएओ (डेटा एक्सेस वस्तु) एक डिजाइन पैटर्न है, जो अपने डेटाबेस एक वर्ग पर एक मेज के लिए बनाने पर मिलकर बनता है, यह वस्तु दृढ़ता और डेटा का उपयोग तर्क को अलग करने

Answer 4

हालांकि इस सवाल से पूछा गया है कि कई साल बीत चुके हैं, फिर भी लोग (मेरे जैसे) हैं जो इस प्रश्न का उत्तर जानना चाहते हैं। उपरोक्त उत्तरों के अलावा मैं जो साझा करता हूं उसे साझा करना चाहता हूं:

वसंत शिक्षार्थियों के डेटा के लिए लिखे गए कई मूल वसंत आधारित कोड में केवल संग्रहीत और डेटाबेस से पढ़ा जाता है। और डीएओ सत्र फैक्ट्री इंजेक्ट करते हैं। तब हमारे पास ऐसी सेवाएं होती हैं जो एक ही काम कर रही हैं। और नए शिक्षार्थियों का आश्चर्य है कि हमारे पास दो समान इंटरफेस और कक्षाएं हैं - दाओ और सेवा।

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

और इस तरह के मामलों में नियंत्रक कक्षाओं को कई अलग-अलग प्रकार के इंटरफेस इंजेक्ट करना होगा (डीबी के साथ काम करना और अन्य फाइलों और कुछ अन्य लोगों के साथ काम करना)। और यदि कोई मोबाइल ऐप है जो समान डेटा स्रोतों का उपयोग करता है जो मोबाइल ऐप सभी प्रकार के डेटा स्रोतों को भी स्थापित करेगा।

तो ऐसा करने के बजाय, जब सेवाओं का उपयोग किया जाता है तो नियंत्रक कक्षाएं, मोबाइल ऐप्स इत्यादि केवल एक सेवा और सेवा कार्य का उपयोग कर सकते हैं जो हमारे पास डेटा निरंतरता स्रोतों के साथ है।

बाद में जब डेटा में परिवर्तन या डेटा के प्रकार में परिवर्तन होता है तो सभी को बदलकर प्रभावित डीएओ और सेवा में किया जाएगा, इसलिए नियंत्रक, मोबाइल ऐप्स आदि प्रभावित नहीं होंगे - वे इसका उपयोग जारी रखेंगे सर्विस।

यह सब समझदारी से काम की मात्रा घट जाती है।

एक फेकाडे डिजाइन पैटर्न है जो एक बेहतर डिजाइन के रूप में इस तरह के सेटअप की सिफारिश करता है।

आप इस महान लेख में इस बात का महान चित्रमय प्रतिनिधित्व देख सकते हैं:

https://springframework.guru/gang-of-four-design-patterns/facade-pattern/

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

उम्मीद है कि इससे मदद मिलती है।