सेवा परत और नियंत्रक: कौन ख्याल रखता है?

Question

कक्षा में अब हम सीख रहे हैं कि स्प्रिंग एप्लिकेशन कैसे बनाया जाए, भले ही वसंत सीधे शामिल न हो, हमने सीएओ और सेवा परत वस्तुओं के लिए इंटरफेस बनाने का तरीका सीखा।

कृपया मुझे ठीक कर लें मैं गलत हूँ: डीएओ परत बहुत सार है: यह सिर्फ CRUD संचालन होता है और आगे डेटा पढ़ने के लिए प्रयोग किया जाता है। (यानी: सभी वस्तुओं मिलता है, विशिष्ट वस्तुओं मिल आदि)

सेवा परत: चीजों को बनाने और चीजों को हटाने के लिए सेवाएं शामिल हैं, यह वह जगह है जहां व्यापार तर्क होना चाहिए।

अब यह सब सेवा परत में समझ में आता है; वस्तुओं को "अद्यतन" को छोड़कर। क्या आपने अभी "अपडेट" फ़ंक्शन डाला है जो ऑब्जेक्ट को आपके डेटाबेस में सहेजता है? या क्या आपको वहां तर्क को परिभाषित करने की ज़रूरत है? यह वह जगह है जहां मेरा भ्रम है, मेरी समझ वसंत में वस्तुएं सिर्फ पीओजेओ हैं। अब फिर डेटा को कौन मान्य करता है?

चलो कहते हैं कि मैं एक वस्तु "बच्चा" करते हैं यह है: Name, SurName, Gender, Photo, Birthdate क्षेत्रों। मैं सेवाओं का नाम कैसे दूंगा? या आप बस नियंत्रक को सत्यापन की देखभाल करने दें, जो मेरे लिए सही नहीं लगता है। दूसरी तरफ यह सेवा सेटर को बुलाए जाने वाले हर सेटटर को प्रतिनिधि देने के लिए सही नहीं लगेगा।

तो बस मूल रूप से: सेवा परत के माध्यम से अपनी वस्तुओं को सहेजने के तरीके के साथ मेरी सहायता करें।

Answer 1

आप नियंत्रकों एक Child वस्तु में परिवर्तन लागू करने के लिए सक्षम होने के लिए है, तो पारंपरिक रूप से आप इस बच्चे का नया संस्करण बने रहने की ChildService.update(Child newchild) की तरह कुछ नामित सेवा है, जो सही DAOs बुला संभाल लेंगे में एक विधि के लिए होगा चाहते हैं ।

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

इसके बजाए, नियंत्रक और/या सेवा को Child ऑब्जेक्ट प्राप्त करना चाहिए, काम की इकाई में ऑब्जेक्ट को जो कुछ भी चाहिए उसे करें, और फिर परिवर्तनों को जारी रखने के लिए एक सेवा (और फिर डीएओ) से पूछें।

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

Answer 2

आम तौर पर एक स्प्रिंग सेवा को उजागर के रूप में लेनदेन है चीजें एक विशेष सेवा विधि में जाती हैं क्योंकि उन्हें एक ही लेनदेन में एक साथ समूहीकृत किया जाना चाहिए। यदि आप डेटाबेस से किसी ऑब्जेक्ट को पुनर्प्राप्त करना चाहते हैं, इसे घुमाएं, और नया संस्करण सहेजें, पुनर्प्राप्ति और सहेजना उसी सेवा विधि में होना चाहिए। इसलिए आपकी सेवा विधियों को निर्धारित किया जाता है कि आपको उपयोगकर्ता के लिए आवेदन करने की आवश्यकता है।

मैं नियंत्रकों को http पैरामीटर को सत्यापित करने से संबंधित कार्य करने के लिए प्रतिबंधित करने का प्रयास करता हूं, यह तय करता हूं कि किस पैरामीटर के साथ कॉल करने के लिए कौन सी सेवा विधि, httpsession या अनुरोध में क्या रखा जाए, रीडायरेक्ट करने या अग्रेषित करने के लिए क्या दृश्य, या इसी तरह के वेब से संबंधित सामान।

जहां तक ​​सत्यापन जाता है: नियंत्रक में इनपुट पैरामीटर मान्य करना यह सुनिश्चित करने के लिए एक अच्छी बात है कि कोई भी आपके आवेदन को फर्जी इनपुट के साथ तोड़ नहीं सकता है। नियंत्रक में प्रमाणीकरण यह सुनिश्चित करने के बारे में होता है कि इनपुट सिंटैक्टिक रूप से ठीक है (इंजेक्शन हमलों का पता लगाने सहित) जबकि सेवा-स्तरीय सत्यापन यह सुनिश्चित करने के बारे में है कि डेटाबेस में चीजों की स्थिति वह है जो आप उम्मीद करते हैं।

इसलिए नियंत्रकों में वेब-फ्रेमवर्क आधारभूत संरचना कोड होता है, सेवाओं में एप्लिकेशन तर्क कोड होता है।