2008-11-12 12 views
11

हमारी टीम एक बड़ी बड़ी एएसपी.NET वेब प्रोजेक्ट विकसित कर रही है जो शुरू में एएसपी.नेट 1.0 में शुरू हुई थी और इसे .NET के सभी नए संस्करणों में कई बार पोर्ट किया गया था।एएसपी.नेट एएसएक्स बनाम एएसपीएक्स - क्या आप उपयोगकर्ता नियंत्रण का पुन: उपयोग करते हैं?

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

पुन: प्रयोज्य, छोटे और विशेष नियंत्रणों के लिए हम सर्वर नियंत्रण (वेबकंट्रोल क्लास से विरासत में) का उपयोग करते हैं, जो बहुत अच्छा काम करता है।

तो मेरा प्रश्न: एक नई परियोजना शुरू करना, क्या यह ठीक है एसीएक्स से छुटकारा पाएं और पृष्ठों में सभी को लागू करें (एएसपीएक्स)? हो सकता है कि आप उपयोगकर्ता नियंत्रण के बहुत से गतिशील लोडिंग (हम नहीं) को छोड़कर छोड़ दें? आपका अनुभव क्या है और आप क्या सलाह देंगे?

उत्तर

16

हमारे पास कुछ परियोजनाएं हैं जो एएससीएक्स नियंत्रणों का व्यापक रूप से उपयोग करती हैं, और अन्य जो नहीं करते हैं। मेरे अनुभव में आपको मामले के आधार पर किसी मामले पर निर्णय लेना होगा।

मेरे दो ASCX नियंत्रण का उपयोग के लिए पसंदीदा कारण हैं:

  1. आप यूआई कार्यक्षमता का एक टुकड़ा है जो कई अलग अलग पृष्ठों (या एक ही पृष्ठ पर एक से अधिक बार) पर दिखाई देगा लागू कर रहे हैं।
  2. आप इसे कुछ पेजों से अलग रखने के लिए कुछ जटिल कार्यक्षमता को समाहित करना चाहते हैं, इस प्रकार आपके कोड को पढ़ने और अधिक रखरखाव करने में आसान बनाते हैं।

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

+1

यदि आप वास्तव में कुछ यूआई लागू कर रहे हैं जो अक्सर/encapsulate दिखाई देंगे, तो इसके बजाय * मास्टर पेज * का उपयोग क्यों न करें और आप कर रहे हैं? –

2

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

यह पृष्ठ पर चारों ओर नियंत्रण को स्थानांतरित करने के लिए थोड़ा आसान बनाता है, अगर आपको जगह पर कोड को काट/पेस्ट करना था।

2

यह पूरी तरह से वेब अनुप्रयोग के प्रकार पर आ गया है जिसे डिजाइन किया जा रहा है। काम पर हमारे अनुप्रयोगों में से एक बहुत विन्यास योग्य है इसलिए लॉग इन उपयोगकर्ता के लिए कॉन्फ़िगर किए जाने के तरीके के आधार पर एक पृष्ठ (default.aspx) पर काम करता है और नियंत्रण में लोड होता है।

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

मिश्रण में फेंकने का एक और विकल्प एएसपीनेट एमवीसी का उपयोग कर रहा है; पुन: उपयोग करने योग्य उपयोगकर्ता नियंत्रणों के साथ परस्पर निर्भर विचारों को भी मिश्रण में फेंक दिया गया :-)

6

सही ढंग से उपयोग किया जाता है, उपयोगकर्ता नियंत्रण रखरखाव और पुन: प्रयोज्यता में सुधार करता है, और अक्सर सर्वर नियंत्रणों से बनाने के लिए तेज़ होते हैं।

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

मुझे लगता है कि अंगूठे का एक अच्छा नियम आपके डिजाइन को देखना होगा और देखें कि आप बार-बार नियंत्रण के समान सेट का उपयोग कर रहे हैं, इस मामले में उपयोगकर्ता नियंत्रणों का उपयोग करने के लिए यह समझ में आता है।

+0

आपके उत्तर के लिए धन्यवाद। आप इसे खराब योजना कह सकते हैं, लेकिन यह एक तथ्य है कि हमारे विशिष्ट वेब एप्लिकेशन में उपयोगकर्ता नियंत्रण इतना विशिष्ट थे कि ज्यादातर मामलों में पुन: उपयोग करने की आवश्यकता नहीं होती है। हो सकता है कि अन्य स्थितियां हों (उदा। पोर्टल) जहां उपयोगकर्ता नियंत्रण अधिक समझ में आता है। – splattne

संबंधित मुद्दे