भंडार लेआउट परियोजनाओं

Question

मैं एक बड़ी आवेदन (~ 50 मॉड्यूल) एक संरचना निम्न के समान का उपयोग कर:

• आवेदन
  • संचार मॉड्यूल
    • रंग संचार मॉड्यूल
    • एसएसएन संचार मॉड्यूल
    • आदि संचार मॉड्यूल
  • रूटर मॉड्यूल
  • सेवा मॉड्यूल
    • वोटिंग सेवा मॉड्यूल
      • वेब इंटरफेस submodule
      • आदि मतदान
    मतदान के लिए के लिए
    • वोट कलेक्टर submodule मतदान के लिए
    • प्रश्नोत्तरी सेवा मॉड्यूल
    • आदि मॉड्यूल

मैं Maven और सबवर्सन के लिए आवेदन आयात करना चाहते हैं। कुछ शोध के बाद मैंने पाया कि इसके लिए दो व्यावहारिक दृष्टिकोण मौजूद हैं।

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

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

आप किस अवधि में लंबी अवधि में चयन करेंगे और क्यों?

Answer 1

हमारे पास एक बड़े पैमाने पर आवेदन (160+ ओएसजीआई बंडल जहां प्रत्येक बंडल एक मेवेन मॉड्यूल है) और हमने जो सबक सीखा, और सीखना जारी रखा है, वह फ्लैट बेहतर है। आपके पदानुक्रम में एन्कोडिंग सेमेन्टिक्स के साथ समस्या यह है कि आप लचीलापन खो देते हैं। एक मॉड्यूल जो 100% है "संचार" आज आंशिक रूप से "सेवा" हो सकता है और फिर आपको अपने भंडार में चीजों को स्थानांतरित करने की आवश्यकता होगी और यह सभी प्रकार की स्क्रिप्ट, दस्तावेज, संदर्भ इत्यादि तोड़ देगा

तो मैं एक फ्लैट संरचना की सिफारिश करता हूं और अर्थशास्त्र को किसी अन्य स्थान पर एन्कोड करने के लिए कहूंगा (उदाहरण के लिए एक आईडीई वर्कस्पेस या दस्तावेज़ीकरण)।

मैंने कुछ विवरण with examples at another question में संस्करण नियंत्रण लेआउट के बारे में एक प्रश्न का उत्तर दिया है, यह आपकी स्थिति के लिए प्रासंगिक हो सकता है।

Answer 2

मुझे लगता है कि आप अपनी निर्देशिका संरचना को फ़्लैट करने से बेहतर हैं। शायद आप निर्देशिकाओं के लिए एक नामकरण सम्मेलन के साथ आना चाहते हैं जैसे कि वे सभी परियोजनाओं को देखते समय अच्छी तरह से क्रमबद्ध होते हैं, लेकिन आखिरकार मुझे नहीं लगता कि यह अतिरिक्त पदानुक्रम आवश्यक है।

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

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