2011-06-11 14 views
5

इस परिदृश्य पर विचार करें:एकाधिक ग्राहकों के लिए सी # WinForm एप्लिकेशन को अनुकूलित करें

मेरे पास एक सी # विंडोज़ फॉर्म एप्लिकेशन है। यह एप्लिकेशन मेरे सभी ग्राहकों के लिए समान था। अब उनमें से एक को नए टेक्स्टबॉक्स और नए तर्क जोड़ने वाले फॉर्म को संशोधित करने की आवश्यकता है।

मैं स्पष्ट रूप से अपने आवेदन को डुप्लिकेट नहीं करना चाहता हूं, और तर्क को नियंत्रित करने के लिए ग्राहक-आईडी के साथ IF कथन डालने के लिए आसानी से स्पेगेटी-शैली कोड पर ड्राइव कर सकते हैं।

मुझे लगता है कि इस स्थिति में मैं प्रत्येक ग्राहक के लिए एक अलग डीएलएल परियोजना बना सकता हूं; अंदर मैं कस्टम रूपों को डिफ़ॉल्ट रूप (और तर्क वर्गों के लिए समान) के रूप में समान इंटरफ़ेस लागू कर सकता हूं और मैं उन डीएल को कॉन्फ़िगरेशन फ़ाइल के माध्यम से स्विच करने या सही ग्राहक डीएल के साथ प्रोजेक्ट बनाने का प्रयास कर सकता हूं (उदाहरण के लिए, उदाहरण के लिए विंडसर कैसल)।

क्या यह एक वैध पैटर्न है? एक अलग तरीके से मौजूद है?

अद्यतन

मैं सूची करने की कोशिश:

+1

[MEF बनाम आईओसी/डीआई] (http://stackoverflow.com/questions/108116/mef-managed-extensibility-framework-vs-ioc-di) पर यह उत्तर देखें। मुझे लगता है कि एमईएफ या डी आपके लिए काम करेगा। निजी तौर पर, मैं ऑटोफैक का उपयोग करता हूं, लेकिन मैं पूर्वाग्रहित हूं। – bentayloruk

उत्तर

1

यदि आप multitenant एप्लिकेशन विकसित कर रहे हैं, तो Autofac जैसे डी फ्रेमवर्क हैं जो इस तरह के अनुकूलन का समर्थन करते हैं। this article

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

+0

मुझे लगता है कि विंडसर भी बहुमुखी का समर्थन करता है! क्या आप मुझे ऑटोफैक का सुझाव दे रहे हैं? – danyolgiax

+0

नहीं, वह आपको एक डी कंटेनर का उपयोग करने का सुझाव दे रहा है। कोई भी कंटेनर काम करेगा, लेकिन ऑटोफैक में एक बहुआयामी अनुप्रयोग के विकास के बारे में उपयोगी दस्तावेज़ीकरण है। – Steven

3

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

+0

कैसल विंडसर DI सक्षम बनाता है। हालांकि, यह व्यापार तर्क तक ही सीमित नहीं है और कॉन्फ़िगरेशन के बिना किया जा सकता है। Autofac के लिए भी यही सच है। इसलिए, इस उत्तर में एमईएफ की सिफारिश करने का आपका कारण भ्रामक प्रतीत होता है। साथ ही, मैं समझ नहीं पा रहा हूं कि जब आप कहते हैं कि "एकाधिक धागे या एक धागे में एक बड़ा ऑपरेशन" कहता है। क्या आपके द्वारा इसे विस्तार दिया जा सकता है? – bentayloruk

+0

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

+0

धागे के लिए ... मेरे पास ऐसी स्थिति थी जहां बीएलएल में एक प्रक्रिया को समानांतर करने के कारण कुछ अपवाद होते थे, जिनके पास मेरे पास हल करने का समय नहीं था।इसलिए मैंने एक ही कार्यक्षमता के 2 कार्यान्वयन लिखे, और एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल में घटक जीवन शैली को बदलने में कोई समस्या नहीं थी। – AlexanderMP