2009-11-06 9 views
16

वर्तमान में हमारे पास तेजी से बढ़ रहे सी # कोडबेस हैं। वर्तमान में हमारे पास सामान्य श्रेणियों में विभाजित 10 परियोजनाएं हैं, सामान्य/उपयोग सामग्री, नेटवर्क परत, डेटाबेस, यूई घटक/नियंत्रण इत्यादि.NET समाधान - कई परियोजनाओं बनाम एक परियोजना

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

क्या किसी के पास कोई पूर्व अनुभव है कि एक परियोजना कई परियोजनाओं से बेहतर/बदतर क्यों है और सर्वोत्तम दृष्टिकोण का सुझाव दे सकती है? और परिपत्र निर्भरताओं के साथ भी कोई भी समस्या उपयोगी होगा।

किसी भी इनपुट की सराहना की।

+0

मुझे लगता है कि एक आर्किटेक्ट की आपकी ज़रूरत की तरह मुझे काफी स्पष्ट होना चाहिए। कुछ लोग वास्तव में समझते हैं कि "कहां से संबंधित है" और "एक सतत वास्तुकला रखने के लिए क्यों महत्वपूर्ण है"। परिपत्र निर्भरता = कुछ गलत हो गया। सामान्य पुस्तकालय = किसी ने छोड़ दिया। यदि आप मुझसे पूछें तो कुछ भी सामान्य नहीं है, सही अलगाव के लिए एक विरोधी पैटर्न की तरह है। –

उत्तर

16

मेरे अनुभव में, कोड जो एक एकलमें निष्पादन योग्य कई परियोजनाओं विभिन्न भागों में

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

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

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

आपके आवेदन के सटीक डिज़ाइन को जानने के बिना, अधिक ठोस सलाह देना मुश्किल है।

+0

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

+0

परिपत्र निर्भरता को हल करने के लिए इंटरफेस का उपयोग करने के विचार के लिए उपरोक्त। –

22

यदि आपके पास परिपत्र निर्भरताओं के साथ परियोजनाएं हैं, जो कोड के डिज़ाइन के साथ समस्या का संकेत देती हैं, समाधान/परियोजना मॉडल के साथ नहीं।

+37

इतने सारे वोट क्यों हैं। वास्तविक प्रश्न पूछने वाले किसी को यह कहने के अलावा "आप नहीं जानते कि आप क्या कर रहे हैं" यह वास्तव में सहायक नहीं है। – Owen

+4

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

+2

System.Xml.dll और System.Configuration.dll –

0

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

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

15

जब परियोजनाओं के बीच निर्भरता बनाने, यह हमेशा के रूप में "लोअर" और "उच्च"

एक उच्च स्तर परियोजना के रूप में एक दूसरे के बारे में सोचना (जैसे एक वेब इंटरफेस के रूप में) में मदद करता है केवल कम परियोजनाओं पर निर्भर होना चाहिए। एक निचली परियोजना (जैसे उपयोगिता) किसी भी वेब इंटरफेस जैसे कभी उच्च पर निर्भर नहीं होना चाहिए। यदि ऐसा होता है, तो इसका मतलब है कि आपके उच्च स्तरीय प्रोजेक्ट में कुछ ऐसा है जो वास्तव में निचले प्रोजेक्ट में होना चाहिए, या इसके विपरीत।

-1

एकल प्रोजेक्ट के साथ प्रारंभ करें। अपने कोडबेस को और अधिक परियोजनाओं में विभाजित करने का एकमात्र लाभ बस निर्माण समय में सुधार करना है।

जब मेरे पास कुछ पुन: प्रयोज्य कार्यक्षमता है जो मैं वास्तव में मुख्य परियोजना से अलग करना चाहता हूं, तो मैं इसके लिए ब्रांड नया समाधान शुरू करूंगा।

+1

-1 जबकि आप सच कह रहे हैं कि यह पूरी तस्वीर नहीं है। –

+1

मुझे उपयोगी समाधान के भीतर परियोजनाओं की अवधारणा नहीं मिलती है, अलग-अलग परतों में अलग-अलग परतों को रखना मेरे लिए और लाखों अन्य लोगों के लिए काम कर रहा है जो खुशी से अन्य प्रोग्रामिंग भाषाओं का उपयोग कर रहे हैं। –

7

हमने देखा है कि विजुअल स्टूडियो का प्रदर्शन महत्वपूर्ण रूप से घटता है क्योंकि परियोजनाओं की संख्या बढ़ती है। 'डीबग' से 'रिलीज' कॉन्फ़िगरेशन में स्विच करने जितना आसान कुछ भी उनमें से लगभग एक दर्जन सी # परियोजनाओं के समाधान के लिए 15 सेकंड तक का समय ले सकता है।

साथ ही, बिल्ड समय के बारे में रीड की टिप्पणी के प्रतिबिंब के रूप में, मैंने देखा है कि बिल्ड समय बढ़ता है क्योंकि विजुअल स्टूडियो प्रोजेक्ट ओवरहेड पर काफी समय व्यतीत कर रहा है। वास्तविक संकलन समय तेजी से प्रतीत होता है, लेकिन चलाने में सक्षम होने के लिए निर्माण को मारने का कुल समय महत्वपूर्ण है।

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

+0

बिल्ड समय पर दिलचस्प बिंदु। हालांकि बहुत महत्वपूर्ण नहीं है, निर्माण के लिए इंतजार करना सबसे महत्वपूर्ण समय पर विकास को रोकता है, जब मैं नाली में हूं :) तो यह जानने के लिए उपयोगी है। –

2

वहाँ विभिन्न परियोजनाओं (और इस प्रकार विधानसभाओं) में एक समाधान अलग करने के लिए कई कारण हैं, और यह मुख्य रूप से फिर से usabilit y और जिम्मेदारियों की जुदाई के लिए नीचे आता है।

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

वास्तव में, यह सामान्य इंटरफेस के खिलाफ प्रोग्रामिंग पर आता है।

हालांकि नोट:

जब मैं कहता हूँ "अन्यथा आप के साथ-साथ कम विधानसभाओं में सब कुछ हो सकता है", मैं जरूरी सुझाव दे नहीं कर रहा था यह करने के लिए गलत बात है। चिंताओं के वास्तविक अलगाव को प्राप्त करने के लिए आप बहुत अधिक कोड लिखने जा रहे हैं और अपने डिजाइन के बारे में सोचना बहुत अधिक है। यह सब अतिरिक्त काम आपके लिए बहुत फायदेमंद नहीं हो सकता है, इसलिए सावधानी से इसके बारे में सोचें।

+0

आप एक परियोजना और एक उचित फ़ोल्डर संरचना के साथ जिम्मेदारियों की पुन: उपयोगिता और अलगाव कर सकते हैं, यह कि अन्य सभी ढांचे कैसे काम करते हैं। प्रत्येक अतिरिक्त असेंबली में अधिक रखरखाव का काम होता है (ज्यादातर समय अनावश्यक)। –

8

सामान्य शब्दों में, कई वी.एस. परियोजनाओं होने (एक वी.एस. समाधान के अंदर) के सिर्फ इन मामलों में मतलब है

  • आप संभवतः एक अन्य परियोजना में उत्पादन DLL का पुन: उपयोग कर सकते हैं (एक वर्ग पुस्तकालय)
  • आप चाहते हैं एक स्तरित वास्तुकला की तरह चीजों को अलग करने के लिए जहां आप डीएओ डीएल छोड़ सकते हैं और इसे
  • के साथ बदल सकते हैं, अलग-अलग फ्रंट-एंड प्रोजेक्ट्स (यानी एएसपीनेट एमवीसी ऐप्स) हैं जिन्हें विभिन्न भौतिक स्थानों में तैनात करने की आवश्यकता है लेकिन उपयोग वही बीएल, डीएएल।

यदि आपकी कहानियां आपको परिपत्र निर्भरताओं की समस्या हो रही है, तो आपको अपने कोड डिज़ाइन में कोई समस्या हो रही है। शायद आप उस तर्क को डाल सकते हैं जिसका उपयोग कई परियोजनाओं में कई परियोजनाओं द्वारा किया जाता है जिसे कई पुस्तकालयों में पुन: उपयोग करने के लिए डिज़ाइन किया गया है।

आम तौर पर मैं कहूंगा कि आपको अधिक परियोजनाएं नहीं जोड़नी चाहिए यदि आपको वास्तव में इसकी आवश्यकता नहीं है। परियोजनाओं में विभाजन का मतलब अधिक जटिलता जोड़ना है, इसलिए जब आप ऐसा कर रहे हैं, तो आपको इससे उचित लाभ प्राप्त करना चाहिए।

+1

परतें परीक्षण के लिए भी अच्छी हैं। – reinierpost

+1

दरअसल, अगर वे ठीक तरह से संरचित होते हैं: http://goo.gl/TMDd – Juri

1

आपको निम्न मार्टिन आलेख सार्थक मिल सकता है: Design Principles and Design Patterns (PDF)(Java)

सी # में एक संशोधित संस्करण विशेष रूप से में माइलिन द्वारा सी # में Agile सिद्धांतों, पैटर्न, और प्रथाओं में उपलब्ध है।

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

+0

हालांकि यह चपलता से असंबंधित है। – reinierpost

0

जहां मैं काम करता हूं, हमने एक दृष्टिकोण का चयन किया जहां लक्ष्य प्रति समाधान एक एकल परियोजना है। सभी कोड लाइब्रेरी प्रोजेक्ट्स में टेस्ट हार्नेस एप्लिकेशन और/या यूनिट टेस्ट ऐप भी होता है।

जब तक कोड लाइब्रेरी परीक्षण पास करते हैं, रिलीज संस्करण (पाठ्यक्रम की एक्सएमएल दस्तावेज़ीकरण फ़ाइल के साथ) को "लाइव" फ़ोल्डर में स्थानांतरित कर दिया जाता है।

ऐसी कोई भी परियोजना जिसके लिए इन अन्य परियोजनाओं से कार्यक्षमता की आवश्यकता है उन्हें "लाइव" फ़ोल्डर से संदर्भित करना होगा।

फायदे स्पष्ट हैं। कोई भी परियोजना हमेशा ज्ञात कामकाजी कोड तक पहुंचती है। प्रगति असेंबली में एक काम का संदर्भ देने का कभी मौका नहीं है। संहिता प्रति असेंबली का परीक्षण करती है, जिससे यह समझना कहीं आसान हो जाता है कि बग कहां उत्पन्न होता है। प्रबंधन के लिए छोटे समाधान आसान हैं।

आशा है कि इससे मदद मिलती है!

शैड

+1

इस उद्देश्य के लिए संस्करण नियंत्रण प्रणाली के उपयोग पर जाने पर विचार करें। – reinierpost