आर्किटेक्चर (संरचना) -ऑर्डिनेटेड बनाम फीचर-ओरिएंटेड प्रोजेक्ट स्ट्रक्चर

Question

प्रोजेक्ट, जिसमें मैंने शामिल किया है, एक आर्किटेक्चर-ओरिएंटेड प्रोजेक्ट की फ़ाइल / फ़ोल्डर संरचना है:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

यह सिस्टम के दृष्टिकोण से स्पष्ट है (विकास टीम द्वारा प्रस्तावित किया गया है)।

यह डिजाइनर टीम द्वारा प्रस्तावित एक सुविधा-उन्मुख संरचना है:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

यह संस्करण डिजाइनरों के करीब है और यह स्पष्ट रूप से लागू होने वाली एक विशेषता का वर्णन करता है।

हमारी टीमों ने एक पवित्र युद्ध शुरू किया है: सबसे अच्छा तरीका क्या है। क्या कोई हमारी मदद कर सकता है और पहले और दूसरे को बुरा समझ सकता है। हो सकता है कि कोई तीसरा हो जो हम दोनों के लिए अधिक उपयोगी और लाभदायक हो।

धन्यवाद।

Comments

मुझे या तो संरचना समझ में नहीं आ रही है - घटनाओं और अनुरोधों (और इस प्रकार इवेंट हैंडलर और रिक्वेस्ट हैंडलर्स) में क्या अंतर है?

— पीटर बॉटन

बहुत स्पष्ट प्रश्न - और तटस्थ भी!

— माइकल के

स्केलेबिलिटी के नजरिए से, दूसरे दृष्टिकोण को क्षैतिज रूप से स्केल करना काफी आसान होना चाहिए।

— कोडार्ट

Answer 1

मैं दूसरे के लिए वोट करूंगा। पहली संरचना में, इवेंट हैंडलर के लिए इवेंट हैंडलर के लिए FeatureAपूरी तरह से असंबंधित हैं FeatureB। ऐसा लगता है कि डेवलपर्स एक समय में एक सुविधा पर काम कर रहे होंगे, और यदि आप एक FeatureXअनुरोध पर काम कर रहे हैं, तो यह अधिक संभावना है कि आपको FeatureXअनुरोध करने वाले हैंडलर को एक अनुरोध करने की आवश्यकता होगी FeatureZ।

वैसे, मैं प्यार करता हूं कि आपने तटस्थ दृष्टिकोण से यह सवाल कैसे पूछा।

Comments

एक चेतावनी के साथ +1: छोटी परियोजनाओं के लिए, दूसरी बड़ी फ़ाइल संरचना में परिणाम होगा, जहां इसे डालने के लिए फाइलें हैं। मैं उन लोगों के लिए पहले का उपयोग करूंगा।

— माइकल के

@ मीकल मैं सहमत हूं, लेकिन इस मामले में यह एक बड़ी परियोजना है।

— जज

+1: और यदि आपको कभी किसी उपयोगकर्ता / ग्राहक के साथ बातचीत करनी है, तो शब्दावली काफी सुसंगत हो सकती है।

— स्टीवन एवर्स

Answer 2

मैं हमेशा दूसरे दृष्टिकोण के साथ अधिक सहज रहा हूं, लेकिन मेरे पास वास्तव में साझा / आधार वर्गों के लिए सामान्य या सामान्य नामक एक "सुविधा" है।

दृष्टिकोण दो वास्तव में अलग चीजों को अलग रखता है, लेकिन "सामान्य" क्षेत्र के बिना यह कभी-कभी उन क्षेत्रों में चीजों को अलग करता है जो वे अच्छी तरह से फिट नहीं होते हैं।

Comments

आम और सामान्य के लिए +1 (प्रत्येक परियोजना में सामान्य उपयोगिताओं, उपकरण हैं ...)

— ज़ज़

Answer 3

कार्यान्वयन के विवरण के बारे में फीचर-आविष्कारक क्यों ध्यान रखते हैं? यदि वह तर्क के पक्षों के बीच अलगाव है, तो मुझे लगता है कि उत्तर स्पष्ट है। विचारों / सुविधाओं का आविष्कार करने वाले लोग फ़ाइल संरचना को निर्धारित नहीं करते हैं जो कार्यान्वयनकर्ताओं द्वारा आवश्यक हैं।

यह एक विशेष रूप से महत्वपूर्ण मुद्दा है जब एक सुविधा के कार्यान्वयन में कई dll, exes, डेटाबेस या अन्य सॉफ़्टवेयर टुकड़े होते हैं।

Comments

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

— रॉबर्ट हार्वे

@ रोबर्ट हार्वे: यदि आप परियोजना के विचारशील संगठन के बारे में बात कर रहे हैं, तो मुझे एक नए उत्तर पर विचार करने की आवश्यकता होगी। हालांकि, ऐसा लगता है कि वे कोड युक्त फाइलों के बारे में बात कर रहे हैं ...

— जॉन फिशर

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

— रॉबर्ट हार्वे

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

— जॉन फिशर

Answer 4

दो विकल्पों को देखते हुए, दूसरे दृष्टिकोण से सहमत होना होगा। पहले वाला सिर्फ एक अनाकार बूँद की तरह दिखता है। कम से कम दूसरे के पास कुछ आकार है।

यह वास्तव में इस बात पर निर्भर करता है कि परियोजना कितनी बड़ी है। यदि "सुविधाएँ" बड़ी हैं, तो प्रत्येक को अपनी अलग बाल्टी की आवश्यकता होती है।

Answer 5

मुझे समझ नहीं आ रहा है कि आप जिस शब्दावली का उपयोग कर रहे हैं, लेकिन वैसे भी जवाब देने की कोशिश करेंगे, क्योंकि दोनों संरचनाएं गलत दृष्टिकोण हैं।

जब तक आपको केवल एक मुट्ठी भर सुविधाएँ नहीं मिलतीं, तब तक आपको उन्हें श्रेणियों में समूहित करने की ज़रूरत होती है - और यह किसी भी डिज़ाइन में कैटरिंग के लिए नहीं दिखाई देता है (जब तक कि Node1 जैसा इरादा न हो, लेकिन "प्रोजेक्ट के सभी एक्स" से पता चलता है) अन्यथा, और मुझे आश्चर्य है कि डब्ल्यूटीएफ यह है - क्या एक नोड 2 है?)

मैं कुछ इस तरह से विचार कर सकता हूं:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

या यह:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

लेकिन वे दोनों धारणाएं बना रहे हैं जो पूरी तरह से बंद हो सकती हैं - यदि आप अपने प्रश्न को अधिक विवरण के साथ अपडेट कर सकते हैं तो मैं अपना दिमाग बदल सकता हूं। :)