आप एक नए एप्लिकेशन को कैसे डिज़ाइन करते हैं जिसे प्रत्येक नए क्लाइंट के लिए अनुकूलित करने की आवश्यकता है?

Question

मुझे एक कंपनी के लिए काफी बड़े वेब एप्लिकेशन को पुनः लिखने के साथ काम सौंपा गया है। यह एप्लिकेशन वर्तमान में हमारे पास 3 क्लाइंट के लिए कुछ वित्तीय/जोखिम विश्लेषण प्रदान करता है।

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

• HackmansHardware
• LowesHardware
• FranksHardware

हैकमैन के हार्डवेयर थोड़ा अलग विश्लेषण की जरूरत हो सकता है या अनुरोध हमारी रिपोर्ट में विशेष कॉलम certains:

हमारे ग्राहकों 3 हार्डवेयर कंपनियां हैं कहो। इसी प्रकार, लोवेस हार्डवेयर अपने पृष्ठों पर थोड़ा अलग सुरक्षा पहुंच लेना चाहता है, फिर अपने उपयोगकर्ताओं के आधार पर एक अलग कंपनी।

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

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

हम इस पुनर्लेखन के लिए एएसपी.नेट एमवीसी का उपयोग कर रहे हैं, लेकिन मुझे यकीन नहीं है कि सवाल के लिए कितना प्रासंगिक है।

Answer 1

आप कितने संभावित ग्राहकों की अपेक्षा करते हैं? यदि उत्तर सालाना 2 नए होते हैं, तो आपका समाधान सालाना 200 नए क्लाइंट कहने से अलग होगा।

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

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

Answer 2

आपको "वेब पोर्टल" की आवश्यकता है।

एएसपी.नेट में वेब पोर्टल बनाने के तरीके पर अच्छी जानकारी उपलब्ध है जो आपको एमवीसी के साथ ऐसा करने के बारे में कुछ विचार दे सकती है। विशेष रूप से DropThings portal है, और इसकी साथी पुस्तक, Building a Web 2.0 Portal with ASP.NET 3.5 है। आप एएसपी.नेट एमवीसी को अपने विचारों के अधिकांश, या सभी को अनुकूलित करने में सक्षम हो सकते हैं।

Answer 3

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

स्कीमा का वर्णन करने के लिए एक्सएमएल का उपयोग करें प्रत्येक दुकान के लिए। एक उपकरण बनाएं जो एक्सएमएल के आधार पर डीबी स्कीमा उत्पन्न करता है। कॉलम को प्रदर्शित करने के लिए यह निर्धारित करने के लिए एक्सएमएल को देखने के लिए अपनी रिपोर्ट को कोड करें। विज्ञापन मतली जारी रखें।

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

Answer 4

एक मास्टर पेज बनाएं जिसमें सभी क्लाइंट के लिए समान जानकारी हो। फिर, प्रत्येक क्लाइंट के लिए अद्वितीय दृश्य और/या नियंत्रक जोड़ें।

निम्न लिंक पर एक नज़र डालें। यह बताता है कि "एप्लिकेशन कंट्रोलर" कैसे बनाएं, एक अमूर्त वर्ग जिसे आपके अन्य नियंत्रकों द्वारा विरासत में प्राप्त किया जा सकता है, ताकि आपको केवल उस कोड को लिखना पड़े जो आपके आवश्यक मास्टर पेज डेटा को दृश्य में धक्का दे।

डाटा पासिंग मास्टर पेज देखने के लिए:

में आंशिक अनुरोध:
http://www.asp.net/learn/MVC/tutorial-13-cs.aspx

इसके अलावा, नीचे दिए गए लिंक पर एक नज़र है, जो कैसे आंशिक दृश्य और ASP.NET MVC में Subcontrollers लागू करने के लिए बताते है एएसपी.नेट एमवीसी
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/

Answer 5

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

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

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

Answer 6

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

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

ध्यान दें कि मैं सी # और आयरनपीथन का उदाहरण यहां उदाहरण के रूप में उपयोग कर रहा हूं - आप दो भाषाओं के किसी भी संयोजन का उपयोग कर सकते हैं। मुझे लगता है कि सीमाओं को स्पष्ट रखने के लिए दोनों के बीच वाक्यविन्यास में एक महत्वपूर्ण भिन्न होना चाहिए।

Answer 7

"बहु किरायेदार" एप्लिकेशन की तलाश करें। यहाँ multi tenant on so

या यहाँ Bart blog

Answer 8

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

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

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

उम्मीद है कि इससे मदद मिलती है।