जवाबों:
DAOडेटा दृढ़ता का एक अमूर्त है । वस्तुओं के संग्रह का
Repository एक अमूर्त हिस्सा है ।
DAOडेटाबेस के करीब माना जाएगा, अक्सर तालिका-केंद्रित।
Repositoryडोमेन के करीब माना जाएगा, केवल एग्रिगेट रूट्स में काम करेगा।
Repositoryलागू किया जा सकता है DAO, लेकिन आप इसके विपरीत नहीं करेंगे।
इसके अलावा, Repositoryआम तौर पर एक संकीर्ण इंटरफ़ेस है। यह बस वस्तुओं का संग्रह होना चाहिए, एक साथ Get(id), Find(ISpecification), Add(Entity)।
जैसे एक विधि Updateउपयुक्त है DAO, लेकिन नहीं है Repository- जब एक का उपयोग कर Repository, संस्थाओं में परिवर्तन आमतौर पर अलग UnitOfWork द्वारा ट्रैक किया जाएगा।
यह देखने में सामान्य प्रतीत होता है कि कार्यान्वयन जिसे Repositoryवास्तव में अधिक कहा जाता है DAO, और इसलिए मुझे लगता है कि उनके बीच अंतर को लेकर कुछ भ्रम है।
ठीक है, मुझे लगता है कि मैं बेहतर समझा सकता हूं कि मैंने टिप्पणियों में क्या रखा है :)। तो, मूल रूप से, आप दोनों को समान रूप से देख सकते हैं, हालांकि डीएओ रिपोजिटरी की तुलना में अधिक लचीला पैटर्न है। यदि आप दोनों का उपयोग करना चाहते हैं, तो आप अपने DAO-s में रिपॉजिटरी का उपयोग करेंगे। मैं उनमें से प्रत्येक को नीचे समझाता हूँ:
यह एक विशिष्ट प्रकार की वस्तुओं का भंडार है - यह आपको एक विशिष्ट प्रकार की वस्तुओं की खोज करने और साथ ही उन्हें स्टोर करने की अनुमति देता है। आमतौर पर यह केवल एक प्रकार की वस्तुओं को संभालता है। उदा AppleRepositoryआपको AppleRepository.findAll(criteria)या करने की अनुमति देगा AppleRepository.save(juicyApple)। ध्यान दें कि रिपॉजिटरी डोमेन मॉडल शब्द का उपयोग कर रहा है (डीबी शब्द नहीं - डेटा कैसे कहीं भी जारी है, इससे संबंधित कुछ भी नहीं)।
एक रिपॉजिटरी सबसे अधिक संभावना है कि सभी डेटा को एक ही तालिका में संग्रहीत करेगा, जबकि पैटर्न को इसकी आवश्यकता नहीं है। तथ्य यह है कि यह केवल एक प्रकार के डेटा को संभालता है, लेकिन यह तार्किक रूप से एक मुख्य तालिका से जुड़ा होता है (यदि डीबी दृढ़ता के लिए उपयोग किया जाता है)।
एक डीएओ एक ऐसा वर्ग है जो आपके लिए डेटा का पता लगाता है (यह ज्यादातर एक खोजक है, लेकिन इसका उपयोग आमतौर पर डेटा को संग्रहीत करने के लिए भी किया जाता है)। पैटर्न आपको एक ही प्रकार के डेटा को संग्रहीत करने के लिए प्रतिबंधित नहीं करता है, इस प्रकार आपके पास आसानी से एक डीएओ हो सकता है जो संबंधित वस्तुओं को रेखांकित / संग्रहीत करता है।
उदाहरण के लिए, आपके पास आसानी से उपयोगकर्ताडॉ हो सकता है जो कि तरीकों को उजागर करता है
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
वे सभी उपयोगकर्ता (और सुरक्षा) से संबंधित हैं और उसी डीएओ के तहत निर्दिष्ट किए जा सकते हैं। यह रिपॉजिटरी के लिए मामला नहीं है।
ध्यान दें कि दोनों पैटर्न वास्तव में समान हैं (वे डेटा संग्रहीत करते हैं और वे इसे एक्सेस करने के लिए सार करते हैं और वे दोनों डोमेन मॉडल के करीब व्यक्त किए जाते हैं और शायद ही कोई DB संदर्भ होता है), लेकिन उनका उपयोग करने का तरीका थोड़ा अलग हो सकता है, DAO जा रहा है थोड़ा अधिक लचीला / सामान्य, जबकि रिपॉजिटरी केवल एक प्रकार के लिए थोड़ा अधिक विशिष्ट और प्रतिबंधक है।
CarDescriptionकि मेरे पास कुछ ऐसा है जैसे कि language_idविदेशी कुंजी के रूप में - तो यह पुनः प्राप्त करने के लिए कि मुझे ऐसा कुछ करना चाहिए: CarRepository.getAll(new Criteria(carOwner.id, language.id));जो मुझे किसी भाषा की सभी कारों को एक विशिष्ट भाषा में देगा - क्या यह करने का सही तरीका है ?
CarRepository.findByLanguageId(language.id)और आपको कोड लिखने की भी आवश्यकता नहीं होगी, आप बस उस नाम के साथ एक विधि के साथ इंटरफ़ेस को परिभाषित करते हैं और स्प्रिंग डेटा आपके लिए डिफ़ॉल्ट क्लास कार्यान्वयन के निर्माण का ख्याल रखता है। बहुत साफ सामान;)
findById)। और आप व्यावहारिक रूप से कर रहे हैं। फिर स्प्रिंग डेटा क्या करता है, यह आपके द्वारा बनाए गए इन सभी इंटरफेस को ढूंढता है जो रिपॉजिटरी इंटरफ़ेस का विस्तार करते हैं और आपके लिए कक्षाएं बनाते हैं। आप कभी भी उन कक्षाओं को नहीं देख पाएंगे और आप नए उदाहरण नहीं बना पाएंगे, लेकिन आपको इसकी आवश्यकता नहीं है क्योंकि आप इंटरफ़ेस को केवल ऑटोवेयर कर सकते हैं और स्प्रिंग को उस रिपॉजिटरी ऑब्जेक्ट का पता लगा सकते हैं।
DAO और रिपोजिटरी पैटर्न डेटा एक्सेस लेयर (DAL) को लागू करने के तरीके हैं। तो, चलो पहले DAL से शुरू करते हैं।
ऑब्जेक्ट-ओरिएंटेड एप्लिकेशन जो डेटाबेस तक पहुंचते हैं, उनके पास डेटाबेस एक्सेस को संभालने के लिए कुछ तर्क होना चाहिए। कोड को साफ और मॉड्यूलर रखने के लिए, यह अनुशंसा की जाती है कि डेटाबेस एक्सेस लॉजिक को एक अलग मॉड्यूल में अलग किया जाए। स्तरित वास्तुकला में, यह मॉड्यूल डीएएल है।
अब तक, हमने किसी विशेष कार्यान्वयन के बारे में बात नहीं की है: केवल एक सामान्य सिद्धांत जो डेटाबेस एक्सेस लॉजिक को एक अलग मॉड्यूल में डालता है।
अब, हम इस सिद्धांत को कैसे लागू कर सकते हैं? खैर, इसे लागू करने का एक तरीका है, विशेष रूप से हाइबरनेट जैसे ढांचे के साथ, डीएओ पैटर्न है।
डीएओ पैटर्न डीएएल उत्पन्न करने का एक तरीका है, जहां आमतौर पर, प्रत्येक डोमेन इकाई का अपना डीएओ होता है। उदाहरण के लिए, Userऔर UserDao, Appointmentऔर AppointmentDao, आदि हाइबरनेट के साथ DAO का एक उदाहरण: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html ।
फिर रिपोजिटरी पैटर्न क्या है? DAO की तरह, रिपोजिटरी पैटर्न भी DAL को प्राप्त करने का एक तरीका है। रिपॉजिटरी पैटर्न में मुख्य बिंदु यह है कि क्लाइंट / उपयोगकर्ता के दृष्टिकोण से, इसे संग्रह के रूप में देखना या व्यवहार करना चाहिए। एक संग्रह की तरह व्यवहार करने का मतलब यह नहीं है कि इसे तुरंत पसंद किया जाना चाहिए Collection collection = new SomeCollection()। इसके बजाय, इसका मतलब है कि इसे जोड़ने, हटाने, शामिल करने आदि जैसे कार्यों का समर्थन करना चाहिए। यह रिपॉजिटरी पैटर्न का सार है।
व्यवहार में, उदाहरण के लिए, हाइबरनेट का उपयोग करने के मामले में, डीएओ के साथ रिपोजिटरी पैटर्न का एहसास होता है। यह डीएओ का एक उदाहरण है जो डीएओ पैटर्न और रिपॉजिटरी पैटर्न के एक ही उदाहरण पर दोनों हो सकते हैं।
रिपॉजिटरी पैटर्न जरूरी नहीं है कि कोई डीएओ के ऊपर बनाता है (जैसा कि कुछ सुझाव दे सकता है)। यदि DAO एक ऐसे इंटरफेस के साथ डिज़ाइन किया गया है जो उपर्युक्त संचालन का समर्थन करता है, तो यह रिपॉजिटरी पैटर्न का एक उदाहरण है। इसके बारे में सोचो, अगर DAO पहले से ही एक संग्रह-जैसा सेट प्रदान करता है, तो इसके ऊपर एक अतिरिक्त परत की क्या आवश्यकता है?
सच कहूँ तो, यह एक अर्थ भेद की तरह दिखता है, तकनीकी भेद नहीं। वाक्यांश डेटा एक्सेस ऑब्जेक्ट "डेटाबेस" को बिल्कुल भी संदर्भित नहीं करता है। और, यद्यपि आप इसे डेटाबेस-केंद्रित होने के लिए डिज़ाइन कर सकते हैं, मुझे लगता है कि अधिकांश लोग ऐसा डिज़ाइन दोष करने पर विचार करेंगे।
DAO का उद्देश्य डेटा एक्सेस तंत्र के कार्यान्वयन विवरण को छिपाना है। रिपोजिटरी पैटर्न कैसे अलग है? जहाँ तक मैं बता सकता हूँ, यह नहीं है। यह कहना कि एक डीएओ के लिए एक रिपॉजिटरी अलग है क्योंकि आप वस्तुओं के संग्रह के साथ काम कर रहे हैं / वापस कर सकते हैं, सही नहीं हो सकता; DAO वस्तुओं का संग्रह भी लौटा सकते हैं।
मैंने जो कुछ भी रिपॉजिटरी पैटर्न के बारे में पढ़ा है, वह इस अंतर पर निर्भर करता है: खराब डीएओ डिज़ाइन बनाम अच्छा डीएओ डिज़ाइन (उर्फ रिपोजिटरी डिज़ाइन पैटर्न)।
रिपॉजिटरी अधिक अमूर्त डोमेन ओरिएंटेड टर्म है जो कि डोमेन ड्रिवेन डिज़ाइन का हिस्सा है, यह आपके डोमेन डिज़ाइन और एक सामान्य भाषा का हिस्सा है, DAO डेटा एक्सेस टेक्नोलॉजी के लिए एक तकनीकी अमूर्त है, रिपॉजिटरी मौजूदा डेटा के प्रबंधन और कारखानों के निर्माण के साथ ही चिंता है। डेटा।
इन लिंक की जाँच करें:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
मुख्य अंतर यह है कि एक संग्रह में कुल जड़ों तक पहुंच को संभालता है, जबकि DAO संस्थाओं तक पहुंच को संभालता है। इसलिए, यह आम है कि एक भंडार डीएओ को कुल मूल जड़ों की वास्तविक दृढ़ता का प्रतिनिधित्व करता है। इसके अतिरिक्त, चूंकि कुल रूट को अन्य संस्थाओं की पहुंच को संभालना चाहिए, इसलिए इसे इस पहुंच को अन्य DAO को सौंपने की आवश्यकता हो सकती है।
DAO डेटाबेस / डेटा फ़ाइलों या किसी अन्य दृढ़ता तंत्र पर अमूर्तता प्रदान करता है ताकि, इसके कार्यान्वयन के विवरण को जाने बिना दृढ़ता परत में हेरफेर किया जा सके।
जबकि रिपॉजिटरी कक्षाओं में, "ऐप के नजरिए" से एक ऑपरेशन करने के लिए एक एकल रिपॉजिटरी पद्धति के अंदर कई डीएओ कक्षाओं का उपयोग किया जा सकता है। इसलिए, डोमेन परत पर कई DAO का उपयोग करने के बजाय, इसे प्राप्त करने के लिए रिपॉजिटरी का उपयोग करें। रिपॉजिटरी एक परत है जिसमें कुछ एप्लिकेशन लॉजिक हो सकते हैं जैसे: यदि डेटा इन-मेमोरी कैश में उपलब्ध है तो इसे कैश से प्राप्त करें अन्यथा, नेटवर्क से डेटा प्राप्त करें और अगली बार पुनर्प्राप्ति के लिए इन-मेमोरी कैश में संग्रहीत करें।
रिपोजिटरी कुछ भी नहीं बल्कि अच्छी तरह से डिज़ाइन किए गए डीएओ हैं।
ओआरएम टेबल सेंट्रिक हैं लेकिन डीएओ नहीं।
रिपॉजिटरी में कई डीएओ का उपयोग करने की आवश्यकता नहीं है क्योंकि डीएओ स्वयं ओआरएम रिपॉजिटरी / संस्थाओं या किसी भी डीएएल प्रदाता के साथ ऐसा ही कर सकता है, कोई फर्क नहीं पड़ता कि कोई कार कहाँ और कैसे 1 टेबल, 2 टेबल, एन टेबल, हाफ टेबल के रूप में बनी रहती है। वेब सेवा, एक टेबल और एक वेब सेवा आदि सेवाएं कई DAO / रिपॉजिटरी का उपयोग करती हैं।
मेरा अपना DAO, मान लें कि कारडाओ केवल कार डीटीओ के साथ सौदा करता है, मेरा मतलब है, केवल इनपुट में कार डीटीओ लें और आउटपुट में केवल कार डीटीओ या कार डीटीओ संग्रह लौटाएं।
इसलिए रिपॉजिटरी की तरह, DAO वास्तव में एक IoC है, जो व्यापारिक तर्क के लिए, दृढ़ता की अनुमति देता है, दृढ़ता रणनीतियों या विरासत से भयभीत नहीं होना चाहिए। DAO दोनों दृढ़ता की रणनीति को ध्वस्त करता है और डोमिनियन-संबंधित दृढ़ता इंटरफ़ेस प्रदान करता है। रिपॉजिटरी उन लोगों के लिए सिर्फ एक और शब्द है जो यह नहीं समझ पाए थे कि डीएओ की वास्तविक परिभाषा क्या है।
यह पता लगाने की कोशिश करें कि क्या DAO या रिपॉजिटरी पैटर्न निम्नलिखित स्थिति के लिए सबसे अधिक लागू होता है: कल्पना कीजिए कि आप विभिन्न प्रकार के डेटा स्रोतों जैसे RDBMS, LDAP, OODB, XML रिपॉजिटरी और एक सतत तंत्र के लिए एक समान डेटा एक्सेस API प्रदान करना चाहेंगे। फ्लैट फ़ाइलें।
यदि आवश्यक हो तो निम्न लिंक भी देखें:
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
एक बहुत ही सरल वाक्य में: महत्वपूर्ण अंतर यह है कि रिपॉजिटरी संग्रह का प्रतिनिधित्व करते हैं, जबकि डीएओ डेटाबेस के करीब होते हैं, अक्सर तालिका अधिक केंद्रित होते हैं।
वसंत रूपरेखा में, रिपॉजिटरी नामक एक एनोटेशन है, और इस एनोटेशन के विवरण में, रिपॉजिटरी के बारे में उपयोगी जानकारी है, जो मुझे लगता है कि यह इस चर्चा के लिए उपयोगी है।
इंगित करता है कि एक एनोटेट वर्ग एक "रिपॉजिटरी" है, जो मूल रूप से डोमेन-ड्रिवेन डिज़ाइन (इवांस, 2003) द्वारा परिभाषित किया गया है, "वस्तुओं के संग्रह का अनुकरण करने वाले भंडारण, पुनर्प्राप्ति और खोज व्यवहार के लिए एक तंत्र"।
पारंपरिक जावा ईई पैटर्न जैसे "डेटा एक्सेस ऑब्जेक्ट" को लागू करने वाली टीमें भी इस स्टीरियोटाइप को डीएओ कक्षाओं पर लागू कर सकती हैं, हालांकि ऐसा करने से पहले डेटा एक्सेस ऑब्जेक्ट और डीडीडी-शैली रिपॉजिटरी के बीच अंतर को समझने के लिए ध्यान रखा जाना चाहिए। यह एनोटेशन एक सामान्य उद्देश्य वाला स्टीरियोटाइप है और अलग-अलग टीमें अपने शब्दार्थ को संकीर्ण कर सकती हैं और उचित रूप में उपयोग कर सकती हैं।
इस प्रकार एनोटेट किया गया वर्ग स्प्रिंग डेटाअबसेप्शन ट्रांसलेशन के लिए योग्य है जब एक PersistenceExceptionTranslationPostProcessor के साथ संयोजन में उपयोग किया जाता है। टंकण, पहलुओं आदि के प्रयोजन के लिए समग्र अनुप्रयोग वास्तुकला में इसकी भूमिका के रूप में एनोटेट वर्ग को भी स्पष्ट किया जाता है।
IRepositoryइंटरफ़ेस को लागू नहीं करना चाहेंगे । आप अपने भंडार को इसके कार्यान्वयन में DAO का उपयोग करना चाहेंगे। याद रखें, एक डीएओ एक प्रति-टेबल ऑब्जेक्ट होगा, जबकि एक रिपॉजिटरी को हमेशा एकल एंटिटी बनाने के लिए कई डीएओ का उपयोग करना होगा। यदि आप पाते हैं कि ऐसा नहीं है, कि आपके रिपॉजिटरी और एंटिटी को केवल एक ही टेबल का उपयोग करने की आवश्यकता है, तो आप सबसे अधिक संभावना है कि एक एनीमिक डोमेन का निर्माण कर रहे हैं।