1. घर
  2. सवाल और जवाब
  3. जावा वेब प्रोजेक्ट स्ट्रक्चर बेस्ट प्रैक्टिस

जावा वेब प्रोजेक्ट स्ट्रक्चर बेस्ट प्रैक्टिस

2009-01-31 10 views
7

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

तो क्या मुझे पता है उत्सुक हूँ

  • एक जावा वेब परियोजना के लेआउट के लिए किसी को भी किसी भी सबसे अच्छा अभ्यास के दिशा-निर्देशों के बारे में पता है क्या है?
  • क्या किसी के पास कठोर नियमों का एक विशेष सेट है जो वे हमेशा विभिन्न प्रकार के प्रोजेक्ट के लिए अनुसरण करते हैं?
  • क्या लोग प्रेजेंटेशन, व्यवसाय और एप्लिकेशन जैसी विभिन्न परतों द्वारा संकुल विभाजित करते हैं?

स्रोत

2009-01-31 Mark Davidson

उत्तर

3

मेरा पिछला उत्तर जारी रखने के लिए, मेरे पास कई वेब प्रोजेक्ट हैं। उनमें से सभी में स्रोत के तहत संरचना उतनी ही कम है। पैकेज मोटे तौर पर 3 तार्किक परतों से अलग हो जाते हैं।

सर्विलेट्स, ऐप श्रोताओं और सहायकों के लिए, जैसा कि आपने कहा था, प्रस्तुति परत सबसे पहले है।

दूसरा, हाइबरनेट मॉडल/डीबी एक्सेस परत के लिए एक परत है। व्यापार तर्क के लिए तीसरी परत। हालांकि, कभी-कभी इन परतों के बीच की सीमा स्पष्ट नहीं होती है। यदि आप डीबी एक्सेस के लिए हाइबरनेट का उपयोग कर रहे हैं तो मॉडल हाइबरनेट कक्षाओं द्वारा परिभाषित किया गया है, इसलिए मैंने उन्हें दाओ ऑब्जेक्ट्स के समान क्षेत्र में रखा है। जैसे com.sample.model हाइबरनेट डेटा ऑब्जेक्ट्स रखता है और com.sample.model.dao दाओ ऑब्जेक्ट्स को पकड़ता है।

यदि सीधे जेडीबीसी (आमतौर पर वसंत के साथ) का उपयोग करते हैं, तो कभी-कभी मुझे डेटा ऑब्जेक्ट्स को डीबी एक्सेस लेयर के बजाय व्यापार तर्क परत के करीब रखने के लिए और अधिक सुविधाजनक लगता है।

(शेष सामान आमतौर पर व्यापार परत के अंतर्गत आता है)।

स्रोत

2009-01-31 17:33:53 Yoni

2

सबसे पहले, एक लोकप्रिय आईडीई, आला ग्रहण, Netbeans, आदि ग्रहण में, उदाहरण के लिए, सब कुछ पहले से ही एक वेब-INF और META-INF फ़ोल्डर के साथ व्यवस्थित किया जाता है की पारंपरिक संरचना का पालन करने के लिए है, इसलिए पैकेजिंग और तैनाती आसान है। कक्षा स्रोत कोड (आमतौर पर src के तहत) स्वचालित रूप से WEB-INF/कक्षाओं में प्रतिलिपि बनाई जाती है। कुछ अन्य कारणों के होते हैं:

  1. आप MVC का उपयोग कर रहे हैं, तो यह है कि आप सीधे अपने JSPs का उपयोग करने की जरूरत नहीं है संभव है। यदि ऐसा है, तो सुरक्षा कारणों से WEB-INF/jsp के तहत जेएसपी स्रोत कोड रखें।
  2. इसी तरह, वेब-आईएनएफ/टैग के तहत कस्टम टैग फाइलें रखें।
  3. जेएस फ़ोल्डर में जावास्क्रिप्ट फ़ाइलों को रखें, स्टाइल फ़ोल्डर में सीएसएस फाइलें इत्यादि। सभी फ़ोल्डरों को वास्तविक तैनाती की नकल करने के लिए वेब-आईएनएफ के समान स्तर पर होना चाहिए।
  4. परतों के अनुसार अपने कोड को पैकेज में अलग करना अच्छा है। जाहिर है कि आपके हाइबरनेट डाओस को आपके सर्वलेट के समान पैकेज पर होने की आवश्यकता नहीं है।
  5. यदि आप एक ही पैकेज में बहुत से सर्वलेट्स के साथ समाप्त होते हैं, तो उन्हें कार्यक्षमता के अनुसार उप-पैकेजिंग पर विचार करें, लेकिन यह अच्छा है कि उनके पास एक सामान्य पूर्वज पैकेज है - यह पठनीयता के साथ मदद करता है।

स्रोत

2009-01-31 14:54:30 Yoni

+0

मैं वेब-आईएनएफ/सामग्री या वेब-आईएनएफ/व्यू पसंद करता हूं, जो जानता है कि प्रेजेंटेशन तकनीक क्या है या नहीं ... –

+0

सही, यह इंगित करने के लिए धन्यवाद। जब तक वे वेब-आईएनएफ के तहत संग्रहीत होते हैं ... – Yoni

+0

योनि के कुछ अच्छे अंक। हालांकि, मुझे अभी भी लोगों की राय में दिलचस्पी है कि विशेष रूप से स्रोत निर्देशिका को संकुल के साथ संरचित किया जाना चाहिए, उर्फ ​​प्रस्तुतियां प्रस्तुति नामक पैकेज में रखी जाएंगी क्योंकि वे मुख्य रूप से जेएसपी सामग्री को कॉल करते हैं। –

6

यह वास्तव में आपके वेब ढांचे पर निर्भर करता है।

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

तो अपने ढांचे (स्प्रिंग एमवीसी, स्ट्रूट्स, जेएसएफ e.t.c) के साथ आने वाले दस्तावेज को पढ़ें।

एक और अच्छा प्रस्ताव है कि आप अपने विशिष्ट ढांचे के लिए कंकाल उत्पन्न करने के लिए मेवेन आर्केटीप्स का उपयोग करें। कुछ वेब ढांचे (जैसे सीम) में भी अपना स्वयं का कोड जनरेशन टूल है जो आपके वेब प्रोजेक्ट के लिए नींव रखता है।

मेरी केवल अच्छा सुझाव (कि योनि से उल्लेख नहीं है) src निर्देशिका के लिए व्यावसायिक उद्देश्य के अनुसार और प्रकार के अनुसार नहीं/परत

  • के लिए संकुल इसका मतलब है कि संकुल बनाने के लिए है com.mycompany.myproject.customers
  • com.mycompany.myproject.departments
  • com.mycompany.myproject.billing
  • com.mycompany.myproject.reports
  • com.mycompany.myproject.admin

और नहीं

  • com.mycompany.myproject.entities
  • com.mycompany.myproject.tables
  • com.mycompany.myproject.graphs
  • com.mycompany.myproject.dialogs
  • com.mycompany.myproje ct.servlets

दूसरी संरचना बहुत सामान्य है, असंबद्ध सामान के साथ विशाल पैकेजों को हल करने के लिए प्रेरित है और इसे बनाए रखना मुश्किल है।

स्रोत

2009-01-31 20:33:44 kazanaki

+0

@ kazanaki दुर्भाग्यवश इस परियोजना में मैं केवल सादा एमवीसी का उपयोग कर रहा हूं, कोई ढांचा नहीं। मैवेन नियमों के अनुसार मेरे पास पहले से ही मेरी src निर्देशिका संरचित है। अपने पैकेज लेआउट के साथ आप उप पैकेज करते हैं कि अलग-अलग परतों में या बस उप उद्देश्यों में ड्रिल करें। –

+0

@ मार्क उपपृष्ठ परतें हैं। उदाहरण के लिए मैं ग्राहकों को ग्राहकों को देता हूं। प्रतिक्रियाएं, ग्राहक.servlets, customers.entities e.t.c. लेकिन जैसा कि आप कहते हैं, वास्तव में एक बड़ी परियोजना उप-पैकेज में उप-उद्देश्यों का उपयोग किया जा सकता है। IMHO पर कोई सही जवाब नहीं है – kazanaki

0

उपयोग Maven webapp archetype layout.

project 
|-- pom.xml 
`-- src 
    `-- main 
     |-- java 
     `-- webapp 
      |-- WEB-INF 
      | `-- web.xml 
      `-- index.jsp

मैं उदाहरण यहाँ java फ़ोल्डर को शामिल किया है, हो सकता है यह स्पष्ट था, लेकिन यह के लिए ऊपर दिए गए लिंक में बाहर छोड़ दिया गया था कुछ कारण।

स्रोत

2012-04-14 04:46:24

संबंधित मुद्दे

 संबंधित मुद्दे