एक अलग विधानसभा / DLL में एक वर्ग या मॉड्यूल कब होना चाहिए?

Question

क्या यह तय करने के लिए कोई दिशा-निर्देश हैं कि एक वर्ग अपनी विधानसभा / DLL में कब होना चाहिए? मैं अक्सर विचार के दो स्कूलों को देखता हूं:

1) कक्षाओं का प्रत्येक "समूह" अपने स्वयं के DLL में होता है जैसे रिपॉजिटरी, सेवा, डीटीओ, इन्फ्रास्ट्रक्चर, आदि।

2) सब कुछ एक ही DLL में होना चाहिए लेकिन नामस्थान / फ़ोल्डर के माध्यम से अलग हो गया जैसे कि एक अतिरिक्त Corepaces के साथ "Core" DLL है जैसे Core.Repositories, Core.Services, Core.DTO, आदि।

काम पर हम एक ही असेंबली में "बिज़नेस" नामक एक चीज में सब कुछ लुटा देते हैं। कुछ फ़ोल्डर हैं, लेकिन कोई वास्तविक पृथक्करण नहीं है - व्यावसायिक ऑब्जेक्ट्स (तर्क के साथ, जिनमें से कुछ भी कक्षाएं नहीं होनी चाहिए) बिना देखभाल के "BusinessObjects" फ़ोल्डर में lumped हैं। एक से अधिक वर्ग में उपयोग की जाने वाली चीजें "कोर" फ़ोल्डर में हैं। उपयोगिताएँ "उपयोगिताएँ" फ़ोल्डर में हैं, डेटा एक्सेस इन्फ्रास्ट्रक्चर एक "डेटा" फ़ोल्डर है - आपको यह विचार मिलता है।

एक नए मॉड्यूल के लिए मैं जिस पर काम कर रहा हूं, उसके लिए एक अलग डेटा एक्सेस लेयर होना चाहिए (एक अल्पविकसित रिपॉजिटरी कार्यान्वयन के बारे में सोचें), लेकिन मैं इसे "BusinessObjects" फ़ोल्डर के तहत अन्य 160 (!) के साथ फेंकना नहीं चाहता। वहां कक्षाएं। उसी समय मैं एक नई क्लास लाइब्रेरी बनाने के बारे में चिंतित हूं, क्योंकि सभी का उपयोग एकल लाइब्रेरी में क्लास भरने के लिए किया जाता है; एक फ़ोल्डर / नाम स्थान हालांकि काम कर सकता है।

Answer 1

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

उदाहरण के लिए, आपने जो उल्लेख किया है, उसके आधार पर, मेरी निश्चित रूप से निम्नलिखित परियोजनाएँ होंगी:

• कोर
• डेटा
• डोमेन (या BusinessObjects)
• सेवाएं
• उपयोगिताएँ (या सहायक)

Comments

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

— एलेरो

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

— एलेरो

दोनों प्रस्तावित समाधानों का दुरुपयोग करना आसान है (यानी बहुत अधिक परियोजनाएं या बहुत कम)। एक अच्छा संतुलन खोजना जहां पुन: प्रयोज्य और कम युग्मन को ध्यान में रखा जाता है, कुछ और परीक्षण योग्य और बनाए रखने योग्य होना चाहिए।

— बर्नार्ड

Answer 2

क्लीन कोड के "अंकल बॉब", सोलिड प्रिंसिपल्स की ख्याति ने यहां तीन सिद्धांतों को रेखांकित किया है :

• रिलीज़ रीयूज़ इक्विवेलेंसी सिद्धांत: पुन: उपयोग का दाना रिलीज़ का दाना है।
• सामान्य बंद करने का सिद्धांत: कक्षाएं जो एक साथ बदलती हैं उन्हें एक साथ पैक किया जाता है।
• सामान्य पुन: उपयोग सिद्धांत: एक साथ उपयोग की जाने वाली कक्षाएं एक साथ पैक की जाती हैं।

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

Comments

+1 ये सिद्धांत अच्छे दिशानिर्देश हैं। अलग-अलग विधानसभाओं में अलग-अलग कक्षाएं अतिरिक्त डिज़ाइन विचार प्रस्तुत करती हैं (उदाहरण के लिए प्रत्येक विधानसभा के संस्करणों को एक साथ काम करने की अनुमति मिलती है) जिससे समग्र कोडबेस बढ़ जाता है और रखरखाव की लागत बढ़ जाती है।

— बेन

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

— बेन

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

— jammycakes

"केवल एक या अधिक विशिष्ट उपयोगकर्ता कहानियों को लागू करने के लिए यदि आपको ऐसा करने की आवश्यकता है, या केवल एक ही विधानसभा होने से औसत दर्जे का प्रदर्शन समस्याएँ पैदा हो रही हैं, (आमतौर पर एक बार वे आकार में कई मेगाबाइट तक पहुँच जाते हैं)।" - पूरी तरह से यादृच्छिक और वास्तविकता की सलाह पर आधारित नहीं है

— hyankov

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

— jammycakes

Answer 3

मेरे साथ काम करने वाले कुछ अन्य मार्गदर्शक सिद्धांत:

• क्या आपको लगता है कि आप अन्य प्रोजेक्ट में इस कोड का फिर से उपयोग करेंगे? संबंधित वेब अनुप्रयोगों के एक समूह के लिए, हमारे पास एक उपयोगकर्ता खाता-संबंधित मॉड्यूल था जो सभी अनुप्रयोगों का उपयोग करता था, क्योंकि वे सभी उपयोगकर्ता खातों और लॉगिन के लिए एक ही मॉडल का उपयोग करते थे। मैंने ज्यामिति और गणित पुस्तकालयों के साथ इसी तरह का काम किया है और डीएलएल को शामिल करके, उन्हें कई अनुप्रयोगों में पुन: उपयोग किया है।

• क्या आप इस कोड को पूरी परियोजना को फिर से तैयार / पुन: स्थापित किए बिना संशोधित / तैनात करने में सक्षम होना चाहते हैं? कभी-कभी वेब एप्लिकेशन को मॉड्यूल को फिर से बनाना, तैनात करना और फिर से शुरू करना उपयोगी होता है।

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

Comments

मुझे लगता है कि आपका दूसरा बिंदु वास्तव में उचित है। मॉड्यूल में विभाजित करना विकास / परीक्षण और संकलन समय की सहायता करना चाहिए।

— WM