विजुअल स्टूडियो सॉल्यूशंस पर अच्छा अभ्यास [बंद]


10

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

डेटाबेस को दूर से एक वेबसर्वर पर संग्रहीत किया जाता है, और इसे वेब एपीआई (JSON आउटपुट) के माध्यम से एक्सेस किया जाएगा और OAuth के साथ संरक्षित किया जाएगा। WPF में फ्रंट एंड GUI किया जा रहा है, और C # में बिजनेस कोड।

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

क्या किसी एकल परियोजना में इसे बनाना या उन्हें अलग-अलग परियोजनाओं में विभाजित करना सबसे अच्छा है?

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


1
मैं उन्हें इस परियोजना के लिए समझ में आता है।
रामहाउंड

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

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

जवाबों:


8

यह परियोजना के आकार पर निर्भर करता है

यहां मैं दिशानिर्देशों का उपयोग करता हूं

  • एक छोटा प्रोजेक्ट, मुट्ठी भर पृष्ठों या उससे कम के साथ, मैं लगभग हमेशा एक ही प्रोजेक्ट के लिए रहता हूं।

  • यदि छोटे प्रोजेक्ट की डेटा एक्सेस लेयर बड़ी या जटिल है, तो मैं इसे अलग कर सकता हूं, क्योंकि यह स्वयं की परत है, लेकिन अन्यथा यह केवल अपने ही फ़ोल्डर में बैठता है।

  • यदि परियोजना बड़ी है, तो मुझे लगभग हमेशा डीएएल के लिए एक अलग परियोजना होगी, और किसी भी आगे के विभाजन पर निर्भर करता है कि आवेदन की कार्यक्षमता के बीच की सीमाएं कहां हैं।

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

  • अगर मेरे पास कई परियोजनाएं हैं जिन्हें वस्तुओं के एक ही सेट ( ViewModelBaseऔर RelayCommand, आदि) को संदर्भित करने की आवश्यकता है , तो मैं केवल साझा बुनियादी ढांचे की वस्तुओं के लिए एक परियोजना बनाऊंगा।

  • यदि मेरे पास साझा कस्टम शैली / टेम्प्लेट / संसाधन की एक बड़ी मात्रा है, तो मैं सिर्फ उन लोगों के लिए एक परियोजना बनाऊंगा।

एक साइड नोट के रूप में, मैंने अपने पहले बड़े WPF प्रोजेक्ट के साथ एक गलती की और उन्हें एक प्रोजेक्ट में मॉडल, दूसरे में व्यूज़ और एक तीसरे में ViewModels डालकर अलग कर दिया। मैं अब आपको बता सकता हूं कि यह रास्ता नहीं है, क्योंकि रखरखाव एक बुरा सपना बन गया है :)


उत्सुक, परतों को अलग करके आपके पास क्या रखरखाव के मुद्दे थे?
इयान

@ राचेल, मैं WPF का उपयोग करूंगा। तो यह जानने में दिलचस्पी होगी कि आपने उस समय में परियोजना का आयोजन कैसे किया था। मुझे लगता है कि मैं याद कर सकता हूं कि एक छोटा एमवीसी प्रोजेक्ट एक दर्द था जब 3 भागों को 3 डीएल में अलग किया गया था। WPF के लिए, मेरा दृश्य GUI, परिवर्तन के लिए इकाई / व्यावसायिक ऑब्जेक्ट होगा, और ViewModel उन दोनों के बीच की सहभागिता को प्रदर्शित करेगा। ViewModel रिपॉजिटरी को रिपेयर लोड / सेव करने के लिए कॉल करने के तर्क से निपटेगा (जिसके बदले में कारखानों / वेब एपिस इत्यादि हैं)।
जॉनविलिस

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

@ अगर मैं निर्भरता के मुद्दों को याद करता हूं और परिपत्र संदर्भों में चल रहा हूं, क्योंकि मेरे सर्वोत्तम प्रयासों के बावजूद कुछ परतों को दूसरों को संदर्भित करने की आवश्यकता है, लेकिन यह परत उन्हें संदर्भित कर रही थी, इसलिए मेरे द्वारा मना किए जाने तक मेरे पास कुछ बदसूरत वर्कअराउंड थे
राहेल

1
@JonWillis मेरे जवाब में निर्दिष्ट अंकों के आधार पर मेरी अधिकांश WPF परियोजनाएं टूट गई हैं। आमतौर पर डीएएल अपनी खुद की परत होती है, और प्रत्येक मॉड्यूल, या परियोजना की धारा को एक साथ समूहीकृत किया जाता है (या तो यह स्वयं फ़ोल्डर, नामस्थान, या परियोजना के आकार के आधार पर परियोजना है)। उदाहरण के लिए, सभी खोज ऑब्जेक्ट Interfaceडेटा लेयर के लिए एक साथ होंगे , लेकिन खोज के लिए वास्तविक डेटा एक्सेस लेयर DAL लाइब्रेरी में होगी। अक्सर मेरे पास एक पुस्तकालय Infrastructureया Commonपुस्तकालय होता है जिसमें सामान्य आधार कक्षाएं, इंटरफेस और सहायक कक्षाएं होती हैं।
राहेल

14

मैंने प्रति परत एक परियोजना के साथ सर्वोत्तम परिणाम देखे हैं, साथ ही प्रति परत एक परीक्षण परियोजना। मैंने कुछ एप्लिकेशन देखे हैं जो समाधान में 10 या उससे कम परियोजनाओं में पूरा नहीं किया जा सकता है, जहां समाधान में सब कुछ शामिल है

उन परियोजनाओं के उपयोग के जाल में न पड़ें, जहाँ आप वास्तव में नाम-स्थान चाहते हैं। टोंस परियोजनाएं बिना किसी लाभ के ओवरहेड के अलावा कुछ भी नहीं जोड़ती हैं।


9

आईएमएचओ सेपरेट लगभग हमेशा बेहतर होता है। जब तक परियोजना 100% तुच्छ नहीं होती मैं लगभग हमेशा अपनी डेटा परत को अलग करता हूं। इसका कारण यह है क्योंकि डेटा लेयर सबसे अधिक बार पास हो जाती है। शायद ही आप एक जीयूआई को कई डेटा लेयर्स पर हुक करेंगे और यह अच्छी तरह से काम करने की उम्मीद करेंगे। अधिक सामान्य परिदृश्य यह है कि आपके पास एक एकल डेटा परत है, और आप इसे कई GUIs (ASP.Net, WPF और उदाहरण के लिए सिल्वरलाइट ऐप) में वितरित करना चाहते हैं। यह भयानक है जब आप सिर्फ डेटा लेयर प्रोजेक्ट का निर्माण कर सकते हैं और उस dll को अगले GUI में एक संदर्भ के रूप में डाल सकते हैं जिसे आप बनाते हैं।


+1 जब मैं नई परियोजनाएं शुरू कर रहा हूं तो मैं अक्सर एक सिम्युलेटेड डेटा लेयर बनाता हूं जो डेटा को मेमोरी में रखता है। मुझे पहले एप्लिकेशन के बाकी निर्माण के साथ प्राप्त करने की अनुमति देता है। फिर मैं इसे एक "वास्तविक" डेटा एक्सेस लेयर के लिए बाद में स्वैप कर सकता हूं ..
MattDavey

क्या आप वेब सर्वर से डेटा लेयर के सभी भाग के साथ संचार करने के लिए उपयोग की जाने वाली इकाइयाँ (DTO), फ़ैक्ट्रीज़ और वर्ग पर विचार करेंगे?
जॉनविलिस

@JonWillis - नहीं, शायद उन सभी को नहीं। मैं वेबसर्वर के लिए कारखानों और वर्गों को एक क्लास लाइब्रेरी प्रोजेक्ट के नाम स्थान पर रखूँगा। मेरी विशिष्ट डेटा परत में आवश्यक dbml फ़ाइलों और / या edmx फ़ाइलों के अलावा कुछ नहीं है। एक नियम के रूप में, हालांकि, मैं "लाइब्रेरी / फ्रेमवर्क" को अपनी खुद की परियोजना देता हूं। उन्हें निश्चित रूप से जीयूआई परियोजना के साथ फेंकने की आवश्यकता नहीं है, हालांकि मुझे लगता है कि लोग हर समय ऐसा करते हैं।
मॉर्गन हेरलॉकर

वास्तविक रूप से, हालांकि, आपको कुछ नामस्थान लेने में कितना समय लगेगा, और उन्हें एक नई परियोजना में डाल दिया जाएगा। मुझे लगता है कि यह बहुत आसान काम है।
डिडियर ए।

4

मेरे लिए, 4 * मैजिक नंबर है। प्रत्येक परत के लिए एक परियोजना, और एक परियोजना जो उनके बीच संवाद करने के लिए सभी इंटरफेस / डीटीओ की आवश्यकता को परिभाषित करती है।

* 7 यदि आप इकाई परीक्षण गिनते हैं


2

अगर मैं उन विभिन्न परतों पर काम कर रहा हूँ, या यदि उनके साथ तंग युग्मन है तो मैंने हमेशा एक ही समाधान का उपयोग किया है। मैं F5 को हिट करना चाहता हूं और जरूरत पड़ने पर सभी परियोजनाओं को फिर से बनाना है। मुझे नहीं लगता कि ऐसा करने का कोई "सही" तरीका है।


2

इसका व्यक्तिगत स्वाद, सबसे महत्वपूर्ण बात सुसंगत होना है । मैं व्यक्तिगत रूप से आवेदन की प्रत्येक परत के लिए एक अलग परियोजना है ताकि जुदाई स्पष्ट है।


आप किन परतों को अलग करते हैं? क्या आपके पास अलग अनुप्रयोग / सेवाएँ परतें हैं, और यदि ऐसा है तो वे वास्तव में कैसे भिन्न हैं। क्या आपके व्यावसायिक तर्क एप्लिकेशन / सेवा में निहित हैं, या क्या वे वास्तविक व्यावसायिक वस्तुओं के तरीके हैं?
जोनलिस

1

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

जब मैं किसी एक असेंबली में सभी "कॉन्ट्रैक्ट्स", इंटरफेस, एब्स्ट्रैक्ट क्लासेस, डेटा ट्रांसफर ऑब्जेक्ट्स डालने के लिए किसी तरह की डिपेंडेंसी इन्वॉल्वमेंट कर रहा होता हूं तो यह काम करता है। एक और असेंबली में मैंने कुछ भी रखा जो डेटाबेस से बात करता है। यूनिट परीक्षणों को अपनी विधानसभा मिलती है। यदि UI मौलिक रूप से अस्थिर है (उदाहरण के लिए ASP.NET winforms), तो UI को परीक्षण योग्य कोड और अनस्टेबल कोड-- असेंबली प्रत्येक में विभाजित करने के लिए महत्वपूर्ण लाभ है। कभी-कभी कुछ कोड यह दिखाने लगते हैं कि डेटाबेस से कोई लेना-देना नहीं है, UI या कुछ भी जो मैंने अभी तक उल्लेख किया है - यह कोड है जो मैं चाहता था। .NET फ्रेमवर्क में था। वह कोड मैं एक यूटिलिटीज असेंबली में डालूंगा, या कम से कम इसे रूट असेंबली में डाल सकता हूं (शायद इंटरफेस वाला।

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

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


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

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

-2

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

यदि परियोजनाएँ केवल एक अनुप्रयोग द्वारा उपयोग की जाती हैं, तो उन्हें पहले स्थान पर नहीं बनाया जाना चाहिए था। इसके बजाय नेमस्पेस का उपयोग करें। फ़ाइलों की तलाश करते समय, परिपत्र संदर्भ, dll ओवरहेड और प्रोजेक्ट भ्रम की परेशानी से खुद को बचाएं।

इस लेख में गहराई से और अधिक जानकारी के लिए पढ़ें कि ऐसा क्यों है: http://lostechies.com/chadmyers/2008/07/16/project-ant-pattern-many-projects-in-a-visual-studio- समाधान फ़ाइल /

और जैसा कि लेख में कहा गया है, मैं किसी ऐसे व्यक्ति का स्वागत करूंगा, जिसके पास आवेदन करने के अलावा कोड साझा करने के अलावा कई परियोजनाएं होने का एक वैध कारण है, मुझे बताएं कि यह क्या है, क्योंकि मुझे संदेह है कि कोई भी है।


डाउनवोट पर काउंटर तर्क की सराहना की जाएगी।
डिडियर ए।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.