अक्सर कई एप्लिकेशन पुस्तकालयों का एक बड़ा कोडबेस साझा करते हैं जो अक्सर विकास में बदलते हैं। इन मामलों में, मैं सूट के नाम पर एक समाधान बनाना पसंद करता हूं, और प्रत्येक एप्लिकेशन और साझा पुस्तकालयों के लिए अलग-अलग परियोजनाएं शामिल करता हूं।समाधान: प्रति आवेदन, या प्रति आवेदन सूट
क्या यह एक अच्छा दृष्टिकोण है? अन्य अनुप्रयोगों के सूट जैसी चीजों के लिए अपने कोड बेस कैसे बनाते हैं?
यह वास्तव में आपके संगठन की विशेष आवश्यकताओं पर निर्भर करता है। MSDN एक good page कि विभिन्न सिफारिश समाधान लेआउट के माध्यम से चला जाता है, सहित: (पसंदीदा)
MSDN page प्रत्येक मॉडल के पेशेवरों और विपक्षों पर अधिक विस्तार से चर्चा करता है ताकि आप यह तय कर सकें कि कौन सा आपके लिए समझ में आता है। :)
सामान्य रूप से, आपके द्वारा वर्णित एक एप्लिकेशन सूट के लिए, मैं विभाजित, एकल समाधान मॉडल पर विचार करता हूं। एक एकल मास्टर समाधान है जो सबकुछ बनाता है, और सुइट के भीतर प्रत्येक व्यक्तिगत एप्लिकेशन के लिए कई अलग-अलग समाधान (मानते हैं कि एप्लिकेशन सराहनीय आकार के हैं)।
यदि सूट में एप्लिकेशन छोटे हैं और जल्दी से निर्माण (उदा।, कमांड लाइन टूल्स का एक सूट), तो मैं अलग-अलग समाधान फ़ाइलों को भी उत्पन्न नहीं कर सकता हूं। यह वास्तव में एक निर्णय कॉल है जिसे हम आपके लिए नहीं बना सकते हैं। :)
आपके समाधान की वास्तविक संरचना वास्तव में आंतरिक वर्कफ़्लो पर निर्भर करती है। बहुत ही चुस्त, हर कोई-रिफैक्टर-सब कुछ दृष्टिकोण एक समाधान कई परियोजनाओं के साथ इंगित करेगा। यदि आपकी दुकान में एक समर्पित लाइब्रेरी टीम और विभिन्न आंतरिक टीमों, जो नियमित आंतरिक रिलीज करते हैं, तो अलग-अलग समाधान मजबूत decoupling के माध्यम से मदद कर सकते हैं, और कम बिल्डिंग समय।
या दोनों का थोड़ा सा करें ... केवल एक मास्टर में जांचें। स्रोत नियंत्रण के लिए एसएलएन (अपने बिल्ड सर्वर और आपके डेवलपर्स के लिए नियमित रूप से बाहर खींचने और लगातार निर्माण करने के लिए) और फिर प्रत्येक डेवलपर स्वयं का निर्माण करने के लिए स्वतंत्र है (संभावित रूप से क्षणिक/डिस्पोजेबल कार्य-उन्मुख समाधान? – rohancragg
@rohancragg: "या दोनों का थोड़ा सा" के लिए +1। यह परस्पर अनन्य प्रस्ताव नहीं है। – J0e3gan