मैं अपने प्रोजेक्ट में DAO डिज़ाइन पैटर्न लागू करने वाला हूं और मैं समझता हूं कि यह डेटाबेस के साथ संवाद करने के लिए सबसे अधिक उपयोग किया जाता है।
लेकिन चूंकि आमतौर पर एक इंटरफ़ेस और एक हैकार्यान्वयन मैं यह सोचने में मदद कर सकता हूं कि यह HTTP के लिए भी उपयोग किया जा सकता है। अर्थात आपके पास डेटाबेस के खिलाफ CRUD के लिए DAO कार्यान्वयन और CRUD API तक पहुंचने के लिए एक और DAO कार्यान्वयन है। लेकिन अगर यह भी इस तरह का उपयोग किया जाता है, तो क्या इस समस्या को हल करने का सामान्य तरीका है कि आपके पास एपीआई पर अनुमतियाँ नहीं हो सकती हैं?
क्या यह सही है या मुझे इसके लिए इंटरफ़ेस की आवश्यकता क्यों होगी? या यह सिर्फ मुझे डेटाबेस कार्यान्वयन को आसानी से बदलने की अनुमति देने के लिए है?
उत्तर:
उत्तर № 1 के लिए 1डीएओ पैटर्न का उपयोग आमतौर पर डिकूप करने के लिए किया जाता हैडेटा प्रतिनिधित्व के विभिन्न रूपों; उदाहरण के लिए, जावा एप्लिकेशन लॉजिक से एक डेटाबेस स्कीमा को अलग करें। इंटरफेस (इस अर्थ में कि मुझे लगता है कि आप चर्चा कर रहे हैं) आमतौर पर जावा लॉजिक के कार्यान्वयन को उसके कार्यान्वयन से हटाने के लिए उपयोग किया जाता है। डिकॉउलिंग के ये दो रूप पूरी तरह से अलग हैं, और कोई कारण नहीं है कि दोनों को एक साथ उपयोग न करें, यदि यह डिज़ाइन को अधिक बनाए रखने योग्य या अभिव्यंजक बनाता है। भले ही जावा कोड सामान्य उद्देश्य के लिए हो (उदाहरण के लिए, कुछ पुन: प्रयोज्य पुस्तकालय में) , तो मुझे लगता है कि यह इंटरफेस द्वारा अपने व्यवहार को निर्दिष्ट करने के लिए अनिवार्य नहीं है, हालांकि इस बिंदु पर अलग-अलग विचार हैं।
अपने विशिष्ट प्रश्न के रूप में: यदि आपके पास जावा विधियां हैं जो डेटा पर काम करती हैं, और वे ऑपरेशन विफल हो सकते हैं, तो परंपरागत रूप से आप एक अपवाद फेंक देंगे। यदि आप DAO का उपयोग कर रहे हैं और आपके java लॉजिक का कुछ हिस्सा डेटा स्टोरेज कार्यान्वयन से बहुत कम है, तो हो सकता है कि वह तर्क सार्थक अवधारणा के रूप में "पहुँच अस्वीकृत" को भी मान्यता न दे। ऐसे मामलों में आपको अपवादों को भी अलग करना होगा, और आपके DAO तर्क को सामान्य "अपडेट विफल" अपवाद फेंकना होगा। वह अपवाद मूल अपवाद ("एक्सेस अस्वीकृत") को ले जा सकता है जो कि इसके कॉलर तक विशिष्ट भंडारण कार्यान्वयन से आया है, जो इसके बारे में कोई मतलब नहीं कर सकता है या नहीं कर सकता है। व्यापक डिकम्पलिंग के खतरों में से एक यह है कि त्रुटि हैंडलिंग तेजी से गैर-विशिष्ट हो जाती है जो आपको त्रुटि के स्रोत से मिलती है।