शुरुआत के लिए जावा स्प्रिंग के साथ प्रतिष्ठित सेवा की संरचना

Question

मैं जावा वेब डेवलपमेंट स्किल्स के मामले में अपेक्षाकृत नया हूं। मेरे पास एक ऐसी परियोजना है जो मुझे लगता है कि एपीआई के बारे में जो कुछ समझ में आया है, उससे बेहतर सेवा के लिए एक अच्छा उम्मीदवार बनाऊंगा। मैं इस बारे में विवरण प्राप्त करने की कोशिश कर रहा हूं कि यह कैसे संरचित माना जाता है, लेकिन वास्तव में Google खोजों के संदर्भ में कहीं भी नहीं मिल रहा है और मेरे पास पहले से मौजूद सामग्री को पढ़ रहा है। मुझे उम्मीद है कि इस पोस्ट से इस विषय पर मेरे ज्ञान और मान्यताओं के संदर्भ में कुछ मान्यता और / या पुनर्निर्देशन मिलेंगे।

मेरी वर्तमान धारणा यह है कि मेरी पुरानी सेवा में निम्नलिखित संरचना होगी:

• डेटाबेस डेटा (एसक्यूएल)।
• एक ORM (मैं CPO नामक एक अपेक्षाकृत अलोकप्रिय ORM का उपयोग कर रहा हूं, लेकिन इसे सिर्फ हाइबरनेट के साथ अन्य लोगों के साथ बदल दिया जाएगा)।
• डेटा प्राप्त करने के लिए ORM से बात करने वाले तरीकों के साथ एक जावा प्रबंधक वर्ग
• एक जावा कंट्रोलर क्लास / क्लासेस जो अनुरोध मैपिंग को हैंडल करता @ResponseBodyहै और URL को डायरेक्ट / हैंडल करने के लिए उपयोग करता है और डेटा को HTTP वर्ब्स ( http://mysite.com/GET कंप्यूटर्स/dell) के माध्यम से कैसे हैंडल किया जाता है , "dell" शब्द के साथ अनुरोध किया जा सकता है। URL में एक पैरामीटर है जो डेल कंप्यूटर के बारे में जानकारी का JSON सरणी लौटाएगा)।
• इस सेवा को स्प्रिंग बूट के साथ बनाया जाना चाहिए, या किसी भी तरह अकेले खड़े होने और किसी अन्य अनुप्रयोग से स्वतंत्र होने में सक्षम होना चाहिए।

अब यह मानते हुए कि उपरोक्त सही है, तो मेरे पास (बहुत ही बुनियादी स्तर पर) एक RESTful सेवा होगी, जिसका उपयोग कोई भी अनुप्रयोग डेटा का उपभोग और उपयोग करने के लिए कर सकता है।

तो कहते हैं कि मैं अपने वेब अनुप्रयोग है। मान लीजिए कि मैं कंप्यूटर हार्डवेयर जानकारी के बारे में एक वेब ऐप बना रहा हूं, और मैं इस वेब ऐप को बनाने के लिए स्प्रिंग का उपयोग कर रहा हूं। यहाँ मेरी धारणाएं हैं:

• मेरे पास JSP के रूप में विचारों का एक समूह होगा, जिसमें JSP के साथ HTML, CSS और जावास्क्रिप्ट शामिल हैं। जावास्क्रिप्ट आवश्यकतानुसार (नीचे) इस एप्लिकेशन के कंट्रोलर को AJAX कॉल को हैंडल करेगा।
• इस वेब ऐप में एप्लिकेशन के URL अनुरोधों और रूटिंग को संभालने के लिए स्वयं नियंत्रक भी होगा, और नियंत्रक तब ModelAndViewउन पंक्तियों के साथ ऑब्जेक्ट, या कुछ और का उपयोग करेगा, जो कि "Restful सेवा के नियंत्रक से बात" करते हैं, जो भी डेटा पास हो रहा है उसे प्राप्त करें। प्रदर्शन के लिए उस डेटा को वापस देखें (जावास्क्रिप्ट, JSP, आदि ...)।

क्या मैं यहां सही दिशा में चल रहा हूं? मैं समझता हूं कि रेस्टफुल सेवाओं के लिए एक प्रमाणीकरण पहलू भी है, लेकिन मैं अभी तक वैचारिक रूप से नहीं हूं (और मेरी परियोजना एक निजी नेटवर्क में उपयोग होने जा रही है, इसलिए इस बिंदु पर सुरक्षा प्राथमिकता नहीं है)।

किसी भी अंतर्दृष्टि, आलोचना, ज्ञान, प्रतिक्रिया, या स्पष्टीकरण की बहुत सराहना की जाती है।

Answer 1

यहां आपके स्प्रिंग रेस्ट ऐप के लिए संरचना के मेरे पसंदीदा किक-ऑफ उदाहरण हैं।

1. परतों का पृथक्करण, प्रत्येक परत एक व्यक्तिगत मॉड्यूल / परियोजना है

• बाकी एपीआई
  • युद्ध के रूप में पैक किया जा सकता है ( यदि आप एम्बेडेड सर्वर के साथ स्प्रिंग बूट का उपयोग कर रहे हैं तो जार हो सकता है। स्प्रिंग बूट डॉक स्पष्ट रूप से बताता है कि तथाकथित कॉल uber जार को कैसे तैनात किया जाए । यह घातक सरल है।)
  • इसमें बाकी नियंत्रक हैं जो अनुरोध / प्रतिक्रियाओं को संभालते हैं
  • नीचे दिए गए सेवा मॉड्यूल पर निर्भर करता है
• सेवा
  • जार के रूप में पैक किया गया
  • व्यावसायिक तर्क सार, इस परत को पता नहीं है कि डेटा स्रोत के साथ कैसे संवाद किया जाए।
  • बाकी कंट्रोलर्स में इसे ऑटो किया जाएगा
  • नीचे DAO / रिपोजिटरी मॉड्यूल पर निर्भर करता है
• डीएओ / भंडार
  • जार के रूप में पैक किया गया
  • डेटा स्रोत से सीधे बात करता है, जिसे आमतौर पर सीआरयूडी के रूप में जाना जाता है। यह साधारण jdbc, JPA या फ़ाइल एक्सेस भी हो सकता है।
  • नीचे डोमेन मॉड्यूल पर निर्भर करता है
• डोमेन
  • जार के रूप में पैक किया गया
  • यह आपके डोमेन मॉडल, आम तौर पर POJO कक्षाएं हैं। यदि आप ORM का उपयोग कर रहे हैं, तो वे ORM निकाय हैं।
  • इसमें डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) भी हो सकता है, जो अभी भी गर्म बहस के अधीन हैं। इसका उपयोग करें या न करें आपका कॉल है।
• आप अधिक मॉड्यूल जैसे कि यूटिलिटी, थर्ड पार्टी इंटीग्रेशन इत्यादि जोड़ सकते हैं। लेकिन उपरोक्त की अत्यधिक अनुशंसा की जाती है।

2. निर्माण / निर्भरता प्रबंधन उपकरण (बहुत आवश्यक IMHO)

उनमें से बहुत सारे हैं, Google खोज आपको दिखाएगी। मुझे व्यक्तिगत रूप से वसंत के साथ मावेन पसंद है । यह बस उपरोक्त परियोजना संरचना के लिए काम करता है।
यह भी ध्यान दें कि यदि आप मावेन का उपयोग कर रहे हैं, तो एक मूल मॉड्यूल है जो खंड 1 में चर्चा किए गए सभी मॉड्यूल को एकत्र करता है। सभी बुलेट बिंदु मॉड्यूल भी मावेन मॉड्यूल से मेल खाते हैं।

3. आपके विशेष प्रोजेक्ट पर विचार

चूंकि आप REST का उपयोग कर रहे हैं, इसलिए मैं अत्यधिक अनुशंसा करूंगा कि आप JSP का उपयोग अपने विचार के रूप में न करें। आप अपने दृष्टिकोण के रूप में सादे HTML5 + जावास्क्रिप्ट या AngularJS जैसे कुछ लोकप्रिय ढांचे का उपयोग कर सकते हैं।
यदि आप JSP का उपयोग करने पर जोर देते हैं, तो आपको एक और युद्ध (वेब ऐप) की आवश्यकता होगी जिसमें नियंत्रक और JSP हों । नियंत्रक को डेटा (सामान्य रूप से Json / xml प्रारूप) मिलेगा और फिर उन्हें आपके मॉडल (POJO) पर पार्स करेगा ताकि आपका JSP उन्हें आपके नियंत्रक से प्राप्त कर सके और प्रदर्शन कर सके। JSP से डेटा पोस्ट करना उल्टा है, मैं यहाँ छोड़ दिया गया।

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

Comments

डोमेन आमतौर पर व्यावसायिक तर्क युक्त परत है। डोमेन को आमतौर पर सेवाओं वाली परत के रूप में भी संदर्भित किया जाता है। डोमेन ऑब्जेक्ट सादा POJO नहीं हैं, डोमेन ऑब्जेक्ट में व्यावसायिक तर्क जैसे तर्क सत्यापन और जैसे होना चाहिए। परत को किसी और चीज़ में बदलना शायद बेहतर होगा। रिपॉजिटरी लेयर का उपयोग अक्सर कई स्रोतों से आपके डोमेन ऑब्जेक्ट में डेटा स्थानांतरित करने के लिए किया जाता है।

— एंडी

क्या सेवा और रिपोजिटरी मॉड्यूल स्प्रिंग प्रोजेक्ट भी होंगे?

— ग्लेन वान शील

@GlennVanSchil नहीं, इसके लिए स्प्रिंग प्रोजेक्ट्स b / c होना जरूरी नहीं है जब पूरा प्रोजेक्ट बनाया जाएगा, तो रेपो / सर्विस लेयर को क्लासपाथ में शामिल किया जाएगा। @Autowireएक परिणाम के रूप में काम करेंगे।

— मिनजुन यू

@MinjunYu स्पष्ट उत्तर के लिए धन्यवाद! लेकिन आपकी रेपो / सेवा को सेवा, रिपोजिटरी या कंपोनेंट एनोटेशन के लिए मैवेन डिपेंडेंसी के रूप में स्प्रिंग की आवश्यकता है क्या मैं सही हूं?

— ग्लेन वान शील

@GlennVanSchil यदि आप मूल मॉड्यूल के सभी वसंत मावेन निर्भरता pom.xml में डालते हैं, तो बाल मॉड्यूल (रेपो / सेवा मॉड्यूल) में वसंत से संबंधित किसी भी निर्भरता को जोड़ने की आवश्यकता नहीं है। यह वसंत में मल्टी मॉड्यूल परियोजनाओं को लेआउट करने का सिर्फ एक तरीका है। उद्देश्य अपने कोड को व्यवस्थित करना है। यदि आपकी परियोजना इतनी बड़ी नहीं है और भविष्य के निकट भविष्य में नहीं बदलेगी, तो आप "कोर" नामक एक ही मॉड्यूल में डोमेन, रेपो, सेवा को जोड़ सकते हैं। यह साफ भी दिखता है।

— मिनजोन यू

Answer 2

@ Minjun.Y के अधिकांश उत्तर से सहमत होते हुए, मुझे लगता है कि मैं REST और वेब पेज लेयर के लिए थोड़ा अलग तरीका अपनाऊंगा। आपके प्रश्न के मेरे पढ़ने से, मुझे लगता है कि आप बाहरी दुनिया के लिए एक वेब इंटरफ़ेस और एक REST इंटरफ़ेस दोनों को उजागर करना चाहते हैं। डेटाबेस से POJOs को पढ़कर, JSON में डेटा को बदलकर, फिर JSP द्वारा खपत के लिए POJO में वापस लाने के लिए बहुत कम है।

मैं सेवा लेयर को सभी वास्तविक कार्य करने का पक्ष लूंगा, और वेब ऐप (JSP) और REST कंट्रोलर के लिए अलग-अलग "प्रेजेंटेशन" लेयर जोड़ूंगा। ये अलग नियंत्रक होंगे, जिसमें सेवा इंजेक्ट की जाएगी। वैकल्पिक रूप से, केवल एक REST सेवा के साथ जाएं और पिछले उत्तर के अनुसार क्लाइंट पक्ष पर सभी प्रस्तुति तर्क का निर्माण करें।

इसके अलावा, मैं मावेन मॉड्यूल का बहुत बड़ा प्रशंसक नहीं हूं। जिस तरह से हमारी जावा दुकान आपकी परियोजना को लागू करेगी वह सेवा परत की नियमित रिलीज करने के लिए होगी, फिर प्रस्तुति परतों को नवीनतम रिलीज पर निर्भर करेगी। इस पर चर्चा के लिए जगह है, लेकिन यह निश्चित रूप से हमारे लिए काम करता है। हमारे पास अलग-अलग मावेन परियोजनाओं के रूप में वेब इंटरफ़ेस और REST इंटरफेस होगा, क्योंकि वे आम तौर पर अलग-अलग .war फ़ाइलों में रहते हैं और इसलिए अलग तैनाती की आवश्यकता होती है।

BTW, मैं निर्माण और निर्भरता प्रबंधन उपकरणों के साथ गति के लिए उठने की आवश्यकता को सुदृढ़ करूंगा। एक बार जब आपका प्रोजेक्ट किसी भी उचित आकार में बढ़ता है, तो आपको उनकी आवश्यकता होती है। मावेन, जेनकिंस और नेक्सस जैसे मुफ्त उपकरण रिलीज प्रबंधन को एक समस्या से कम करते हैं।