जावा वेब एप्लिकेशन फ़ोल्डर संरचना

Question

J2EE के लिए एक शुरुआत के रूप में, मैंने हाल ही में J2EE के कोर का उपयोग करके अपने स्वयं के प्रोजेक्ट को विकसित करना शुरू किया है: सर्वलेट्स & एसएसपीएस।

मैं मूल्यांकन नहीं कर सका कि मेरी परियोजना फ़ोल्डर संरचना सही है या नहीं। यहाँ मेरा प्रोजेक्ट फोल्डर स्ट्रक्चर है।

सवाल पूछने से पहले, मैं स्वीकार करता हूं कि मैं जवाब नहीं दे सकता था और न ही यह औचित्य दे सकता था कि अगर कोई मुझसे पूछता है, तो इस प्रकार की फ़ोल्डर संरचना क्यों। प्रश्न: क्या वेब-इन-के बाहर अपने jsps को रखना एक अच्छा संकेत है। यदि नहीं, तो ऐसा क्यों है? यदि हाँ तो क्यों?

क्या जे 2 ईई वेब एप्लिकेशन के लिए कोई मानक फ़ोल्डर संरचना सम्मेलन है, मुझे पता है कि मावेन ने कुछ मानकों को लाया है लेकिन फिर भी, मुझे विश्वास है कि हम आवश्यकता के अनुसार अनुकूलित कर सकते हैं।

मैंने थोड़ी गुगली की है और दो संदर्भ 1 2 पाया है

जहाँ उत्तर उसी पृष्ठ पर नहीं हैं, जहाँ से मैं कोई निष्कर्ष नहीं निकाल सका।

जे 2 ईई वेब एप्लिकेशन के लिए फ़ोल्डर संरचना को बिछाने के दौरान किन बिंदुओं पर विचार किया जाना चाहिए, महत्वपूर्ण बात यह है कि जेएसपीएस, स्थिर सामग्री को कहां और क्यों जाना चाहिए?

Comments

पढ़ने की सिफारिश की: क्यों "सबसे अच्छा अभ्यास" एक बुरी बात पर एक सवाल पूछ रहा है?

— gnat

मैं आपको एमवीसी सिद्धांत पर शोध करने की सलाह देता हूं - विकिपीडिया लेख में इस पर कुछ उत्कृष्ट संसाधन हैं। यदि आप एमवीसी के साथ जावा वेबप में प्रयोग करना चाहते हैं, तो स्ट्राइप्स एक उत्कृष्ट हल्का ढांचा है जो आपको वास्तुकला का अवलोकन दे सकता है।

— माइकल के

यहाँ एक और अधिक विशिष्ट उपचार है कि MVC वेबएप में कैसे काम करता है।

— माइकल के

: एक अतिरिक्त पढ़ने के रूप में का webapp फ़ाइल संगठन सम्मेलन (विकास संरचना)

— informatik01

Answer 1

WAR फ़ाइल के लिए मानक संरचना है:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

मावेन -वेब-प्लगइन में अपने src / main / java, Resources, webapp और आपकी निर्भरता (उन्हें / lib में रखकर) का उपयोग करके मावेन आपके लिए इसे उत्पन्न करता है , लेकिन यह कार्यान्वयन है। एहसास करने के लिए महत्वपूर्ण बात यह है कि WEB-INF में आपके द्वारा डाली गई कोई भी चीज बाहरी रूप से सुलभ नहीं है , जबकि WAR की मूल निर्देशिका में सब कुछ सार्वजनिक है।

आम तौर पर आप रूट में ज्यादा कुछ नहीं डालना चाहते हैं, क्योंकि आप चाहते हैं कि आपका आवेदन वेबलेट .xml में परिभाषित सर्वलेट्स और फिल्टर्स का उपयोग करके सभी एक्सेस को हैंडल करे। यह एक सामान्य। Html (या .jsp) को रूट में देखने के लिए आम है जो एक सर्वलेट के लिए रीडायरेक्ट करता है, उदाहरण के लिए स्ट्रट्स एक्शन।

विशिष्ट MVC कार्यान्वयन जैसे कि स्ट्राइप्स या स्ट्रट्स उपयोगकर्ता की JSP को सीधे एक्सेस करने के खिलाफ सलाह देते हैं, यह पसंद करते हुए कि JSP केवल-दृश्य हो। वे नियंत्रक बनाने की सलाह देते हैं जो अनुरोध को संसाधित करने के बाद जेएसपी को अग्रेषित करते हैं, और जेएसपी केवल परिणाम प्रस्तुत करते हैं। उदाहरण के लिए, एक फॉर्म सबमिट करने /loginसे एक्शन चलेगा जो लॉगिन अनुरोध को संसाधित करता है, उपयोगकर्ता का सत्र बनाता है, और होम पेज जेएसपी के लिए लॉग-इन के लिए उपयोगकर्ता को आगे करता है।

Answer 2

"सही तरीका क्या है?" या "क्या यह सही तरीका है?" है ..... यह निर्भर करता है ।

सभी मैं आपको विशिष्ट विचारों के लिए पेशेवरों और विपक्षों को बता सकता हूं। इस प्रकार मेरी राय 100% है। मैं किसी विशिष्ट आवश्यकताओं या नियमों के बारे में नहीं जानता। मुझे यकीन है कि कोई मुझसे असहमत होगा।

JSP के

चलो JSP की WEB-INF में डालते हैं या नहीं, इस पर काम करते हैं।

WEB-INF में JSP लगाने के पेशेवरों:

• आप नियंत्रित करते हैं कि जेएसपी को कैसे निष्पादित किया जाता है। यदि आप चाहते हैं कि एक JSP को परिचालित किया जाए और फिर से प्रयोग करने योग्य हो (जो कि वैसे भी JSP के साथ बहुत कठिन है), तो आप उन्हें WEB-INF में डाल सकते हैं और प्री-प्रोसेसिंग करने के लिए एक सर्वलेट या स्ट्रट्स एक्शन कंट्रोलर या किसी अन्य फ्रंट कंट्रोलर का उपयोग कर सकते हैं। और फिर JSP के लिए सही वातावरण संदर्भ (जैसे अनुरोध विशेषताएँ, कोई सुरक्षा जांच, पैरामीटर स्वच्छता, आदि) में पासिंग नियंत्रण।
• आप किसी फ़ायरवॉल या IDS स्तर ब्लॉक HTTP HTTP प्रोग्राम पर * .jsp से वेब रूट पर किसी JSP को अपलोड करने और फिर वेब सर्वर के रूप में कोड निष्पादित करने में सक्षम होने की संभावना को कम करने के लिए। उन्हें एक मौजूदा JSP को लिखना होगा। भारी सुरक्षा लाभ नहीं है, लेकिन यह थोड़ा कठिन समझौता करता है।
• अच्छी आदतों को लागू करता है, जैसे कि एमवीसी, फ्रंट कंट्रोलर, सर्वलेट फिल्टर, निर्भरता इंजेक्शन, आदि एक बड़े राक्षसी जेएसपी के विपरीत है जो सभी काम खुद करता है और पढ़ने / बनाए रखने में मुश्किल है।

वेब-इन्फो में जेएसपी लगाने का विपक्ष:

• आप सीधे पृष्ठ तक नहीं पहुँच सकते, भले ही यह एक साधारण स्टैंडअलोन पृष्ठ हो, जिसे अपफ्रंट प्रोसेसिंग की आवश्यकता न हो। ऐसा इसलिए है क्योंकि / WEB-INF के तहत फाइलें एक सर्वलेट कंटेनर द्वारा सेवित नहीं हैं।

स्थिर फाइलें

HTML, छवि, स्टाइलशीट, जावास्क्रिप्ट आदि जैसी विशुद्ध रूप से स्थिर फ़ाइलों के संदर्भ में, वेब रूट (my_app आपके मामले में) के तहत डालते हैं, लेकिन NOT / WEB-INF (क्योंकि यह सुलभ नहीं है)।

कुल मिलाकर लेआउट

समग्र निर्देशिका लेआउट के लिए, यह आपकी निर्माण प्रक्रिया पर कुछ हद तक निर्भर करता है। मुझे "src" या "स्रोत" के तहत सब कुछ संग्रहीत करना पसंद है क्योंकि यह स्पष्ट करता है कि कौन सी फाइलें इमारत से उत्पन्न होती हैं और कौन सी शुद्ध स्रोत फाइलें हैं। mainआपको अपने मुख्य स्रोत कोड से जूनियर कक्षाओं की तरह अलग-अलग टेस्ट कोड देता है, जो अच्छा भी है। लेकिन अगर आपके पास कोई इकाई परीक्षण नहीं है (ओह नहीं!), तो यह एक अर्थहीन अंतर है।

दूसरी ओर, यदि आप बिल्ड के दौरान वेब रूट में हेरफेर नहीं करते हैं (जैसे कि यदि यह सभी JSP और स्टैटिक फाइल्स हैं), तो शायद आप इसे शीर्ष स्तर पर रखें , जैसे आवश्यक हो, /webrootया /deployफ़ाइलों को कॉपी करें जैसे कि .class या .jar फाइलें। अति-संगठित करना मनुष्य (विशेष रूप से डेवलपर्स) की आदत है। अति-आयोजन का एक अच्छा संकेत केवल एक ही उप-फ़ोल्डर वाले बहुत सारे फ़ोल्डर हैं।

आपने क्या दिखाया है

आपने संकेत दिया है कि आप मावेन द्वारा निर्धारित एक सम्मेलन का अनुसरण कर रहे हैं, इसलिए यदि आप पहले से ही मावेन का उपयोग कर रहे हैं, तो बस उस लेआउट के साथ रहें। आपके द्वारा वर्णित लेआउट के साथ कुछ भी गलत नहीं है।

Answer 3

खैर, आपका src / main / webapp निश्चित रूप से मुझे मावेन प्रोजेक्ट की याद दिलाता है। कौन सा अच्छा है।

My_app / jsps के लिए, हालांकि मुझे यकीन नहीं है। डेवलपर आमतौर पर वेब japp फ़ोल्डर में अपनी jsp छोड़ देते हैं, या यदि आप किसी वेब-मैप / jsp डायरेक्टरी में url-mapping करना चाहते हैं।

! चेतावनी! : आपको वेब-इन में कभी भी jsp फाइल नहीं डालनी चाहिए। आपकी वेबसाइट को कॉन्फ़िगर करने के लिए आपके WEB-INF में केवल xml फाइलें होनी चाहिए। याद रखें, आपका jsp एक वेबपेज या वेबपेज का हिस्सा है।

आप टेम्पलेट, आंशिक जैसे फ़ोल्डर नाम का उपयोग कर सकते हैं ... जो भी आपके लिए ठीक लगता है। किसी अजनबी के लिए ढूंढना आसान होना चाहिए। फ़ुलपेज, टेम्प्लेट, आंशिक विचार जैसे अलग-अलग प्रकार की सामग्री ...

Comments

src / main / webapp में मानक WAR लेआउट फ़ाइल होती है और जावा वेबएप को संकलित करते समय maven-war-plugin द्वारा पढ़ा जाता है ।

— माइकल के

ऐसा कोई कारण नहीं है कि आपको JSP को WEB-INF में नहीं डालना चाहिए, जब तक कि आपने अपने web.xml में सर्वलेट्स को कॉन्फ़िगर नहीं किया है, जो अंततः उनके लिए आगे आएगा। यह एक स्ट्रट्स ऐप को लागू करने का मानक तरीका है - सभी अनुरोध स्ट्रट्स सर्वलेट के माध्यम से जाते हैं, जो उन्हें एक कार्रवाई के लिए और फिर एक जेएसपी के लिए मैप करता है।

— माइकल के

मैं इस तथ्य से सहमत हूं कि एक जेएसपी को सीधे एक्सेस नहीं किया जाना चाहिए और इसे रोकना अच्छा व्यवहार माना जाना चाहिए। लेकिन ऐसा करने के लिए अन्य साधन भी हैं।

— ब्रिस रुपेने

Answer 4

मैं ब्राइस से सहमत हूं । मैं J2EE में भी शुरुआत कर रहा हूं, लेकिन मुझे लगता है कि यह शुरुआत में आसान और स्पष्ट रूप से बेहतर काम कर रहा है।

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

Answer 5

वास्तव में WAR एप्लिकेशन का निर्माण बिना किया जा सकता है WEB-INF/web.xml। अंदर केवल जावा कक्षाओं के साथ डब्ल्यूएआर आवेदन करना संभव है।

स्रोत: एक web.xml परिनियोजन वर्णक तत्व

जावा ईई एनोटेशन के साथ, मानक web.xml परिनियोजन डिस्क्रिप्टर वैकल्पिक है। पर सर्वलेट 3.0 विनिर्देश के अनुसार http://jcp.org/en/jsr/detail?id=315 , एनोटेशन ऐसे servlets, फिल्टर, श्रोता और टैग संचालकों के रूप में कुछ वेब घटकों, पर परिभाषित किया जा सकता।

इसलिए आजकल WAR का निर्माण संभव है, .warएक्सटेंशन के साथ JAR जैसा दिखता है :)

आपके प्रश्न का उत्तर देते हुए, WAR संरचना आपकी आवश्यकताओं पर निर्भर करती है।

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)