क्लासिक ASP से ASP.net या ASP.net MVC

Question

हमारे पास एक वेब एप्लिकेशन है जिसे क्लासिक एएसपी में विकसित किया गया है और यह 5 वर्षों में अपने वर्तमान स्वरूप में विकसित हुआ है जिसमें 100 पेज, विशाल डेटाबेस और 10000 से अधिक सक्रिय उपयोगकर्ता रोजाना कम से कम 10 पृष्ठों से अधिक चल रहे हैं।

अब, हम इसे .net के नवीनतम संस्करण में अपग्रेड करना चाहते हैं। शुरू में हमने सोचा था कि पूरे ऐप को फिर से लिखा जाए, लेकिन परिदृश्य का विश्लेषण करने के बाद हमने पाया कि यह एक व्यवहार्य विकल्प नहीं है और कई विशेषज्ञों द्वारा भी सुझाया नहीं गया है। हमने अभी तक यह तय नहीं किया है कि इसे दूसरे तरीके से कैसे किया जाए, लेकिन चेहरे पर पुनर्लेखन को कैसे प्राप्त किया जाए, इस पर कुछ विचार मिले।

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

विकल्प 2: फिलहाल हमने एक साधारण मॉड्यूल का उपयोग किया है और एक IFrame के माध्यम से क्लासिक ASP पृष्ठ में इसका उपयोग किया है, हालाँकि यह IFrame में क्लासिक ASP और नए पृष्ठ के बीच डेटा भेजने में काफी परेशानीजनक था।

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

मैं अन्य प्रोग्रामर के विचार, राय और सुझाव प्राप्त करना चाहता हूं, क्या हमें ऐसे परिदृश्य में संपर्क करना चाहिए? अगर किसी ने इस तरह के परिदृश्य का सामना किया है तो कृपया अपनी राय भी साझा करें।

यह भी जानना चाहेंगे कि ASP.net MVC के उपयोग से मुझे इसमें मदद मिलेगी?

अद्यतन : अपने विचार रखने के लिए दोनों उत्तरों के लिए धन्यवाद। क्लासिक एस्प से asp.net या asp.net mvc के लिए एप्लिकेशन को माइग्रेट करने में उपरोक्त दोनों विकल्पों पर अधिक जानकारी प्राप्त करना चाहते हैं। यह मेरे लिए बहुत मददगार होगा, यदि आप सभी asp.net या asp.net mvc चुनने के बिंदु के बजाय माइग्रेशन पार्ट पर अपने विचार, बिंदु और विचार के माध्यम से कर सकते हैं।

Comments

+1 यह एक बहुत अच्छा सवाल है जेपीआरडी। मैंने अपनी किसी भी परियोजना पर इतना लंबा समय व्यतीत नहीं किया है इसलिए मैं आपकी समस्या की कल्पना भी नहीं कर सकता।

— रॉबर्ट कोरिटनिक

मुझे एहसास है कि यह "तथ्य के बाद अच्छी तरह से" टिप्पणी है, लेकिन आपको जरूरी नहीं है कि सभी WebForms या MVC पर जाएं - एक MVC प्रोजेक्ट WebForms पृष्ठों की मेजबानी कर सकता है, और इसके विपरीत। मैं SSRS और ReportViewer नियंत्रण के लिए समर्थन पाने के लिए MVC एप्लिकेशन में ऐसा करता हूं ...

— Tieson T.

Answer 1

"मुझे आपका दर्द, क्रूरता महसूस हो रही है" कहकर मुझे टाल देना शुरू करें। मैं इस 3 साल पहले गया था, और मुझे लगता है कि MVC उस बिंदु पर परिपक्व हो गया था क्योंकि WebForms समाधान मैं काफी अच्छी तरह से डिज़ाइन किया गया था MVC मॉडल वास्तव में मेरे लिए बनाया Microsoft पुस्तकालयों के बिना जैसा है (निश्चित रूप से, वहाँ कई झलकियाँ थीं - नर्क क्यों क्या मैंने ऐसा किया "मतभेद"।

मैं भी iFrames का उपयोग कर समाप्त हो गया। माता-पिता के आवेदन के रूप में .Net और दास के रूप में क्लासिक एस्प का उपयोग करके सामग्री अंतर का प्रबंधन करने के लिए। मैंने .Net में फ्रेमवर्क आर्किटेक्चर विकसित किया और उस पर अमल किया। क्लासिक एस्प पेज तब अनावश्यक प्रस्तुति टुकड़ों (शामिल और whatnot) के "culled" थे और iFrames में लोड किए गए थे। कस्टम एन्क्रिप्शन का उपयोग करके डेटा तब url के माध्यम से पारित किया गया था। यह सुनिश्चित करने के लिए कि प्रमाणीकरण को आसानी से खराब नहीं किया जा सकता है और क्वेरी स्ट्रिंग को क्रैक करके एक्सेस किया गया पृष्ठ हमने IIS में वाइल्डकार्ड हैंडलर को भी नियोजित किया है।

यह देखते हुए, मेरी सिफारिश सीधे एमवीसी के पास जाएगी।

1. एमवीसी आपको वैश्विक स्तर पर रूटिंग तक पहुंच प्रदान करेगा। एक नियंत्रक के चतुर हेरफेर के साथ, आप अपने मॉडल को उचित तरीके से विकसित कर सकते हैं और एक सामान्य नियंत्रक हो सकता है जो सभी क्लासिक एस्प अनुरोधों को आवश्यक रूप से संभालता है।
2. MVC परीक्षण परियोजना को जोड़ने के लिए आपको बहुत सरल बना देगा और आपको नए मॉडल संरचना के आधार पर अलग-अलग एप्लिकेशन टुकड़ों को रिफलेक्टर करने की अनुमति देगा, जबकि यह सुनिश्चित करने के लिए पर्याप्त परीक्षण कवरेज प्रदान करेगा कि आप यह सब ठीक कर रहे हैं। इसका मूल्य बिल्कुल असाध्य है क्योंकि किसी भी रिफ्लेक्टर कोड में कवरेज बहुत बड़ी चिंता है।
3. MVC WebForms की तुलना में प्रस्तुति के लिए अधिक स्क्रिप्टेड दृष्टिकोण का अनुसरण करता है। WebForms इसे सभी में मिलाने की कोशिश करता है जैसे यह किसी प्रकार का स्टेटफुल एप्लिकेशन है (जो कि ऐसा नहीं है), और यह क्लासिक एस्प के आदी लोगों के लिए काफी कल्चर शॉक हो सकता है। मुझे गलत मत समझो, आपके डेवलपर्स को संस्कृति को कोई फर्क नहीं पड़ता कि आप किस रास्ते पर जा रहे हैं, लेकिन अगर आप उस झटके में से कुछ को प्रस्तुति की परत से निकाल सकते हैं तो आपको अधिक सफलता मिल सकती है।

मुझे WebForms और MVC दोनों पसंद हैं (हालांकि मैं रेजर के परिचय के साथ मानता हूं कि मैं MVC के प्रति थोड़ा पक्षपाती हूं)। उन दोनों के पास अपने स्थान हैं, और मुझे लगता है कि आपके द्वारा वर्णित एक एप्लिकेशन जैसे कि एक एमवीसी कार्यान्वयन के लिए आदर्श रूप से अनुकूल हो सकता है, विशेष रूप से "कंपित" प्रकृति को देखते हुए आपको रिफ्लेक्ट किए गए एप्लिकेशन टुकड़ों को अपनाने की आवश्यकता होगी।

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

Comments

एमवीसी को फिर से लाने के लिए +1। यह निश्चित रूप से बहुत आसान संक्रमण होगा।

— रॉबर्ट कोरिटनिक

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

— जोएल एथरटन

वेबफार्म में राज्य-पूर्ण-नेस कार्यान्वयन और आंतरिक कामकाज की तुलना में रूटिंग अधिक स्वाभाविक और आसान है। WebForms बहुत अधिक सार। Asp.net WebForms वेब एप्लिकेशन लिखना शुरू करने के लिए मुख्य रूप से डेस्कटॉप डेवलपर्स का एक चिकनी संक्रमण बनाने के लिए विकसित किए गए थे। वे एक ही घटना संचालित मॉडल और पेज की पूर्ण स्थिति के संपर्क में थे। दूसरी ओर Asp.net MVC वेब डेवलपर को ध्यान में रखकर लिखा गया था (क्लासिक एएसपी देव पूर्ण वेब देव हैं)। कोई बदलाव नहीं (ठीक है) एक ... परीक्षण करने योग्य था, लेकिन ऐप आर्किटेक्चर के साथ ऐसा करने के लिए इतना नहीं है)।

— रॉबर्ट कोरिटनिक

Answer 2

ASP.NET MVC के लिए जाना संक्रमण को किसी भी आवश्यक रूप से आसान बनाने वाला नहीं है, और यह वास्तव में इसे और अधिक कठिन बना सकता है। हालाँकि, जब आप पहले से ही इस भव्य उपक्रम के माध्यम से जाने के लिए चुने गए हैं, तो अपनी योजनाओं को सबसे अच्छी तरह से फिट करने वाले प्लेटफॉर्म पर आगे बढ़ने और आगे बढ़ने के लिए समय क्यों नहीं निकालें?

ASP.NET (sans MVC) में माइग्रेट करना इस अर्थ में "आसान" होगा कि आप आम तौर पर अपने मौजूदा लॉजिक के स्ट्रेट पोर्ट्स बिना किसी भव्य रिफैक्टिंग के कर सकते हैं, बशर्ते कि आप बहुत सारी एक्सक्लूसिव चीजें न कर रहे हों क्लासिक एएसपी। परिणाम संतोषजनक और अपेक्षाकृत उन लोगों से परिचित होंगे जो पहले से ही आवेदन से परिचित हैं। आप इस अर्थ में लाभ प्राप्त करेंगे कि क्लासिक ASP से ASP.NET तक पोर्ट किए गए प्रत्येक एप्लिकेशन को लाभ मिलेगा ।

ASP.NET MVC में माइग्रेट करना अधिक काम होने वाला है। यह संभवत: MVC पैटर्न के भीतर फिट होने के लिए आपके एप्लिकेशन मॉडल की खोज करने की आवश्यकता होगी । यह आम तौर पर एक अच्छा थिंग (tm) है क्योंकि यह चिंताओं को अलग करने जैसे अच्छे व्यवहार को प्रोत्साहित करता है। परिणामस्वरूप आवेदन की संभावना नहीं होगी कि आप अपने पास मौजूद कुछ चीज़ों को बारीकी से देख पाएँगे। आपको अन्य फायदे भी मिलेंगे । यह एक बड़ी संस्कृति पारी होगी और विकास टीम को "एमवीसी कैसे लिखें" को ठीक से समझने के लिए कुछ (पुनः) शिक्षा लेनी होगी।

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

Comments

मैं एमवीसी के बयान पर बहुत असहमत हूं। मुझे लगता है कि Asp.net MVC वेब रूपों की तुलना में बहुत बेहतर ट्रैन्स्टियन पथ होगा। यदि आप चाहते थे तो आप Asp.net MVC नियंत्रक क्रियाओं को वापस पोस्ट करने के लिए मौजूदा पृष्ठों का उपयोग कर सकते हैं। और मॉडल मजबूत प्रकारों के साथ बाँधता है (स्वचालित रूप से सर्वर सत्यापन प्राप्त करता है)। WebForms के उपयोग से इस तरह की चीज असंभव हो जाएगी। अच्छी बात यह है कि अगर वे क्लासिक एएसपी में पारंगत हैं, तो वेबफॉर्म की तुलना में एमवीसी तक कदम रखना ज्यादा आसान होगा । MVC HTTP प्रोटोकॉल के लिए अनुकूल है जिस तरह से पुराने ASP थे, दूसरी तरफ Webforms नहीं हैं। हर्गिज नहीं।

— रॉबर्ट कोरिटनिक

Answer 3

मैं पूरी तरह सहमत हूं कि ASP.NET MVC जाने का रास्ता है। यह आसान नहीं होगा, यह आसान नहीं होगा, लेकिन यह निश्चित रूप से WebForms की तुलना में बहुत अधिक भविष्य का प्रमाण है। हालांकि WebForms को निश्चित रूप से नहीं छोड़ा गया है, अनुप्रयोगों के बड़े होने और बड़े होने के कारण उनका उपयोग करना तेजी से बोझिल हो जाता है।

मैं "बड़े" अनुप्रयोगों पर WebForms के उपयोग को दृढ़ता से हतोत्साहित करता हूं।

Comments

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

— एडम लेअर

हाय अन्ना, मैं इसे स्वचालित रूप से करता हूं, जैसे, मैं हमेशा संदेश के अंत में अपना नाम टाइप करता हूं। इसकी आदत पड़ने में अभी कुछ समय लगेगा।

— एंड्रिया रायमंडी

Answer 4

मुझे विकल्प 1 पसंद है) (एमवीसी के साथ) विकल्प 2 की तुलना में बहुत बेहतर है) क्योंकि यह आपको एप्लिकेशन को वृद्धिशील रूप से विकसित करने की अनुमति देता है, जबकि दो एप्स को जोड़े जाने की आवश्यकता नहीं है क्योंकि आप iFrames दृष्टिकोण के साथ हैं।

मुझे एएसपी.नेट के लिए एक पुराने ऐप को माइग्रेट करने के साथ कुछ अनुभव हुआ है और चुनौतियों में से कुछ संसाधनों को साझा करना था जैसे कि दो ऐप के बीच सत्र राज्य। उपयोगकर्ता के ब्राउज़र से कुकी जानकारी के माध्यम से सर्वर ऐप पर एक ऐप कॉल करने से इसे हल किया जा सकता है। ऐप्स के बीच अन्य जानकारी साझा करना भी निश्चित रूप से URL रूटिंग और क्वेरी स्ट्रिंग्स के माध्यम से किया जा सकता है जो MVC के साथ एक प्राकृतिक दृष्टिकोण है।

इसके अलावा, पहले माइग्रेट करने के लिए उपयुक्त मॉड्यूल की पहचान करना एक चुनौती हो सकती है, लेकिन आप एमवीसी पर विकसित की जा रही सभी नई कार्यक्षमता के साथ शुरू कर सकते हैं ताकि अधिक चीजों को पलायन करने के लिए समाप्त हो सके। फिर शायद उन वर्गों को चुनें जिनके पास एमवीसी ऐप के रूप में अगली बार किए जाने वाले रीवर्क या बग फिक्स का एक महत्वपूर्ण बैकलॉग है, फिर अपेक्षित परिणामों को स्थापित करने के लिए अपने पुराने सिस्टम का उपयोग करके, जैसा कि आप सुझाव देते हैं, रिफ्लेक्टिंग का एक रूप बन जाएगा। इस रीफैक्टरिंग के दौरान यूनिट टेस्ट और ऑटोमैटिक एक्सेप्टेंस टेस्ट (जैसे SpecFlow / Watin) जोड़कर MVC की टेस्टिबिलिटी का लाभ उठाना न भूलें। उत्तरार्द्ध प्रकार के परीक्षणों का एक फायदा यह है कि आप यह सत्यापित कर सकते हैं कि वे पुरानी प्रणाली से गुजरते हैं और फिर इसी परीक्षण को अपने नए कोड के लिए लागू करते हैं और भविष्य के रिफैक्टरिंग।