सेवा परत बनाम डीएओ - दोनों क्यों?

Question

मैं एक जावा वेब अनुप्रयोग उदाहरण में स्प्रिंगएमवीसी, हाइबरनेट और कुछ डेटाबेस के साथ काम कर रहा हूं।

ऐसा करने वाले कुछ अलग हैं, लेकिन उदाहरण के साथ इस स्प्रिंग 3 और हाइबरनेट एकीकरण ट्यूटोरियल में एक मॉडल वर्ग, दृश्य (जेएसपी में), और नियंत्रक के लिए एक सेवा और डाओ कक्षाएं हैं।

मेरा प्रश्न यह है कि क्या सेवा और DAO दोनों वर्ग समान कार्य नहीं करते हैं? आपको उन दोनों की आवश्यकता क्यों होगी?

यह वह ट्यूटोरियल था जिसका मैं वास्तव में उपयोग कर रहा था: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

Answer 1

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

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

एक और कारण सुरक्षा है - यदि आप एक ऐसी सेवा परत प्रदान करते हैं जिसका DB से कोई संबंध नहीं है, तो क्या सेवा के अलावा क्लाइंट से DB तक पहुंच प्राप्त करना अधिक कठिन है। अगर DB को क्लाइंट से सीधे एक्सेस नहीं किया जा सकता है (और सेवा के रूप में काम करने वाला कोई मामूली डीएओ मॉड्यूल नहीं है), तो ग्राहक पर कब्जा करने वाले सभी हमलावर सेवा लेयर को हैक करने का प्रयास कर सकते हैं, जबकि वह सभी को प्राप्त करने से पहले आपके डेटा के लिए अधिकतम स्वच्छता पहुंच।

Comments

मैं आपके व्यवसाय तर्क सहित सेवा और डाओ परतों और आपकी सेवा परत के अलगाव से सहमत हूं।

— पीटर डेलानी

यह उल्लेख नहीं करने के लिए कि 1 सेवा कई DAO कह सकती है, उदाहरण के लिए उपयोगकर्ता को बचाते समय आप UserDao, UserOrdersDao, आदि से बात कर सकते हैं या हमें प्रत्येक के लिए एक सेवा बनानी चाहिए? और फिर इन सभी सेवाओं को कौन कह सकता है?

— फर्मिन सिल्वा

Answer 2

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

इसके अलावा, वसंत में, सुरक्षा को सेवा परत पर आदर्श रूप से लागू किया जाता है। आप इसे बदलना नहीं चाहेंगे।

Comments

अरे, मेरे प्रश्न का उत्तर देने के लिए बहुत बहुत धन्यवाद; यह आपके ब्लॉग के लिए समर्पण है! महान उदाहरण के लिए धन्यवाद, लिखते रहें।

— जेफ

यह कुछ समय के लिए मेरे दिमाग को खराब कर रहा था और मुझे लगता है कि इन स्थितियों में अनुभव सबसे अधिक मदद करता है। धन्यवाद।

— उत्कर्ष emमदीर

मैं आपके व्यवसाय तर्क से युक्त सेवा और डाओ परतों और आपकी सेवा परत के पृथक्करण से सहमत हूं और केवल दाओ विधियों को बुलाऊंगा। जब मेरी एक सेवा पद्धति को किसी अन्य सेवा पद्धति को कॉल करने की आवश्यकता होती है, तब क्या होता है। क्या मुझे सेवा स्तर के ऊपर एक और अमूर्तता रखनी चाहिए जो कई सेवा विधियों को कॉल करती है?

— पीटर डेलानी

सेवा स्तर पर सं। वर्गों में एक दूसरे के संदर्भ (आवश्यकतानुसार) हो सकते हैं और वे आवश्यक विधियों को कॉल कर सकते हैं।

— लाकेश

Answer 3

एडम बायन ने अपनी पुस्तक में इस तथ्य की ओर संकेत किया है कि जेपीए एंटिटी मैनजर डीएओ का एक अच्छा सार्वभौमिक कार्यान्वयन है:

http://realworldpatterns.com/

जावा ईई दुनिया में लगभग अपना खुद का डीएओ लिखने की आवश्यकता नहीं है क्योंकि जेपीए कार्यान्वयन में एक शामिल है। आपको केवल सर्विस लेयर लिखना होगा।

अपनी खुद की DAO परत को लागू करना वास्तव में 15 साल पहले की बहुत खराब J2EE वास्तुकला से हैंगओवर है, लेकिन कई लोग अभी भी इसे करने के लिए मजबूर महसूस करते हैं। ये कस्टम DAO परतें अक्सर अग्रेषण कार्यों से अधिक कुछ नहीं प्रदान करती हैं जो EntityManager पर संबंधित विधि को कॉल करती हैं।

तो आपके प्रश्न का उत्तर देने के लिए, हाँ आपको एक सेवा स्तर और एक DAO की आवश्यकता है, लेकिन आपको केवल सेवा स्तर लिखना होगा।

Comments

मुझे यकीन नहीं है कि अगर यह स्प्रिंग पर लागू होता है - हमेशा एक कस्टम डीएओ होता है जिसे मॉडल के लिए बनाया जाना चाहिए। हो सकता है कि आपका बयान "लगभग अपना खुद का डीएओ लिखने की आवश्यकता नहीं है" विशेष रूप से ईजेबी कंटेनर / एप्लिकेशन सर्वर पर लागू होता है?

— डॉन चीडल

अपना खुद का (DAO / DAOImpl) लिखना बेहतर है, हालांकि यह केवल EntityManager - Thats के लिए मैप करेगा क्योंकि भविष्य में आप सेवा परत कोड को बदलने की आवश्यकता के बिना एक और DAO कार्यान्वयन जोड़ सकते हैं ।

— ahmednabil88

@YajliMaclo क्या अंतर है जो बदलना है?

— एलेक्स78191

Answer 4

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

Answer 5

मैंने पाया है कि सर्विस लेयर ज्यादातर मामलों में अनावश्यक जटिलता जोड़ती है। सिद्धांत रूप में, डाओ परत में व्यवसायों के तर्क से बचने के लिए है, लेकिन अंत में यह सिर्फ भ्रम की स्थिति पैदा करता है, यहां तक ​​कि कुछ लोगों ने पूरी तरह से डाओ परत को हटाने के लिए उपयोग किया है क्योंकि उन्हें लगता है कि यह मूल्य नहीं जोड़ता है। http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

लेकिन अगर आपके पास कई व्यावसायिक लॉजिक्स हैं तो हाँ यह एक अच्छा विचार है। सर्विस लेयर बनाना कितना आवश्यक है?

Comments

मैंने अब तक कई बार आयंडे के ब्लॉग पोस्ट को पढ़ा है, और बस इस भावना को हिला नहीं सकता कि मैं (जो कि मैं एक बिंदु पर सहमत होगा), जबकि YAGNI की भावना के लिए सच है, लगभग अनिवार्य रूप से अधिक देव समय भी खर्च होंगे मध्यम अवधि की तुलना में यह पहली जगह में परतों के अमूर्त को स्थापित करने के लिए खर्च होगा। मुझे आश्चर्य है कि अगर उसने पूरे एप्लिकेशन और NHibernate के बीच तंग युग्मन पर अपनी राय बदल दी है तो यह है कि एक एकल एप्लिकेशन के लिए कई SQL, NoSQL और API डेटा स्रोतों को क्वेरी करना और भी सामान्य है।

— श्री कोच

@ LennyGodber हाँ, मुझे पता है कि आपकी भावनाएं IMO DAO / रिपॉजिटरी लेयर से बेहतर है क्योंकि इसके और भी फायदे हैं जो नुकसान करती हैं क्योंकि जैसा कि आप कह रहे थे कि कई डेटा स्रोत होना बहुत आम है

— Jesus

Answer 6

IMHO सेवा परत को नियंत्रक और DAO परत के बीच एक परत माना जा सकता है। यह सेवा परत ठीक वही है जहाँ हम व्यावसायिक तर्क जोड़ सकते हैं और यहाँ तक कि दृश्य द्वारा प्रदान की जाने वाली आवश्यकताओं के लिए विशिष्ट रिटर्न ऑब्जेक्ट भी बना सकते हैं।