एएसपीनेट एमवीसी पैटर्न प्रारूप

Question

पर मौजूदा एएसपीनेट एप्लिकेशन माइग्रेट करने के लिए कैसे मैं मौजूदा एएसपीनेट एप्लिकेशन को एएसपीएनटी एमवीसी पैटर्न प्रारूप में माइग्रेट करना चाहता हूं। मुझे किस प्रक्रिया का पालन करना चाहिए? कोई भी चरण-दर-चरण निर्देश बहुत उपयोगी होगा।

Answer 1

मुझे नहीं लगता कि एएसपी.नेट वेबफॉर्म से एएसपी.नेट एमवीसी तक "चरण-दर-चरण माइग्रेशन" जैसी चीज है। वे एक ही ढांचे पर बने दो पूरी तरह से अलग डिजाइन पैटर्न हैं, लेकिन कई मामलों में (बहुत से मामलों में) बहुत सी चीजें हैं जिन्हें न केवल स्थानांतरित करने की आवश्यकता होती है, बल्कि पूरी तरह से फिर से डिज़ाइन की जाती है, यदि आप केवल वेब बनाना नहीं चाहते हैं WebForms टेम्पलेट के बजाय एमवीसी टेम्पलेट प्रोजेक्ट पर ऐप।

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

Answer 2

मेरा उत्तर "आप नहीं" :) होगा। यदि आप वास्तव में ऐसा करना चाहते हैं, तो आप वर्तमान एएसपीनेट साइट को अपने अंतिम लक्ष्य के रूप में या एक आवश्यकता 'दस्तावेज़' के रूप में उपयोग कर सकते हैं। और शायद आप अपने मॉडल में डेटालियर का उपयोग कर सकते हैं, लेकिन आपको पूरी साइट को फिर से डिजाइन करना होगा।

जैसा कि टॉमस ने पहले ही बताया है, यह क्लासिक एएसपीनेट से बहुत अलग है।

Answer 3

क्लासिक एएसपी.Net वेबफॉर्म से एएसपी.NET एमवीसी में हमारे कदम के दौरान हमने अपनी कंपनी में किए गए कदमों के आधार पर यह चरण-दर-चरण मार्गदर्शिका है। यह सही नहीं है, और अभी भी चल रहा है क्योंकि हमें साइट के आकार के कारण चरणों में ऐसा करना है, लेकिन शायद किसी और को हमारे परिणामों के आधार पर एक बेहतर उत्तर मिलेगा और फाइल करेगा।

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

युक्तियाँ: - अपने वर्तमान साइटमैप को देखें, और एएसपी.NET एमवीसी अनुप्रयोग में उपयोग किए जाने वाले बेहतर साइटमैप/निर्देशिका संरचना को डिज़ाइन करें। अपनी वेबसाइट के लिए 'भाषा' को चित्रित करें, उदा। एएसपी.NET एमवीसी का डिफ़ॉल्ट व्यवहार http://sitename/ {नियंत्रक}/{action}/{id} व्यवहार होना है, लेकिन आप इसे ओवरराइड कर सकते हैं क्योंकि आपको अधिक अनुभव हैकिंग रूटिंग नियम प्राप्त होते हैं।

• डिफ़ॉल्ट रूप से याद रखें प्रत्येक नियंत्रक को आपके एप्लिकेशन की आभासी उपनिर्देशिका के माध्यम से भेजा जाएगा, उदा। http://sitename/X XController (और डिफ़ॉल्ट रूप से इसकी अनुक्रमणिका विधि) तक रूट करेगा, http://sitename/Y/Get वाईकंट्रोलर की Get() विधि के लिए रूट होगा। आप इसे कृपया बदल सकते हैं (रूटिंग वास्तव में शक्तिशाली), लेकिन यह इस उत्तर के दायरे से बाहर है।

• मौजूदा साइटमैप का उपयोग करके, निर्दिष्ट करें कि प्रत्येक वर्तमान में एमवीसी संरचना में कौन सा फ़ोल्डर गिरना चाहिए .aspx पृष्ठ गिरना चाहिए (बेशक, पहले पूछें कि यह बिल्कुल मौजूद होना चाहिए)।

• यदि लिपियों, छवियों आदि को एक साथ संग्रहीत नहीं किया जाता है, या प्रत्येक उपनिर्देशिका के भीतर कुछ 'आरक्षित नाम' फ़ोल्डर्स में, अब ऐसा करने पर विचार करें जैसे आप फिर से डिजाइन कर रहे हैं। यह है कि यह इन फ़ोल्डरों को रूट के रूप में प्रोसेस करने के लिए Global.aspx.cs फ़ाइल में Map.IgnoreRoute() रूटिंग नियम कमांड का उपयोग करने की अनुमति देकर आपके डिज़ाइन को बहुत सरल बना देगा।

हमारे मामले में हम वर्तमान साइट है, जहाँ प्रत्येक उपनिर्देशिका एक नियंत्रक बन गया के वास्तविक उपनिर्देशिका लेआउट नजर आता है, उदा/खाते में खाता नियंत्रक होगा,/एक्स XController होगा। वहां मौजूद सभी पेजों को प्रत्येक नियंत्रक के भीतर क्रियाओं द्वारा प्रतिस्थापित किया गया था। जैसे http://sitename/profile/about.aspx अब http://sitename/profile/about बन गया है और प्रोफ़ाइल नियंत्रक के अंदर "about" ActionResult विधि में मैप किया गया है। यह हमें पूरी साइट को एक लंबी अवधि में माइग्रेट करने के बजाय, एक या दो निर्देशिकाओं (या एक निर्देशिका के अंदर कई फाइलों) के आंशिक माइग्रेशन करके फुर्तीली रहने की इजाजत देता है।

1. दृश्य स्टूडियो में एक नया ASP.Net MVC आवेदन बनाएँ और तुरंत Global.asax फ़ाइल में नियम है कि फ़ोल्डर जो वर्तमान साइट में मौजूद के लिए मार्ग नियमों की अनदेखी पैदा करते हैं।

2. एएसपी.Net वेब अनुप्रयोग से फ़ोल्डरों को एएसपी.NET एमवीसी अनुप्रयोग फ़ोल्डर में कॉपी करें। वेबसाइट चलाएं और सुनिश्चित करें कि यह ठीक से काम करता है (इसे अभी तक कोई रूटिंग नियमों का उपयोग नहीं किया जाना चाहिए)।

3. माइग्रेट करने के लिए उपनिर्देशिका के भीतर फ़ाइलों की उपनिर्देशिका या उप-समूह चुनें।

4. इस उपनिर्देशिका के अंदर प्रत्येक .aspx पृष्ठ के लिए:

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

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

   सी। नियंत्रक बनाएं यदि यह अभी तक नहीं बनाया गया है, और अपनी योजना के निर्धारण के लिए उचित क्रिया-प्रक्रिया विधि को इस दृश्य के मार्ग में जाना चाहिए। यदि आपको कुछ ऐसा एहसास है कि पुरानी साइट से किसी पृष्ठ पर मानचित्र नहीं है, तो नियंत्रक के लिए दृश्य बनाएं, और उपयुक्त // TODO: टैग शामिल करें ताकि आप इसे लागू करने के लिए इसका ट्रैक रख सकें आपने मौजूदा पृष्ठों को माइग्रेट कर दिया है।

   डी। अज्ञात कार्रवाइयों के लिए कुछ हैंडलिंग कोड डालने पर विचार करें, अगर आपके पास पहले से ही आपकी global.asax.cs फ़ाइल में {* catchall} रूटिंग नियम नहीं है।

   ई। मॉडल के लिए कन्स्ट्रक्टर क्लास बनाएं ताकि नियंत्रक के पास कुछ पैरामीटर दिए गए हों (आपके {id} के रूप में पास हो गए हों या संभवतः URL से एक Request.QueryString पैरामीटर, या HTTP हेडर या कुकी), मॉडल को पता चलेगा कि कैसे अपने मौजूदा व्यापार तर्क वर्ग तक पहुंचें और दृश्य द्वारा प्रतिपादन के लिए स्वयं को तैयार करें।

   एफ। सूची में अगले पृष्ठ पर जाएं और चरण ए से फिर से शुरू करें।

5. अंत में रूटिंग नियम बनाएं जो आपके नए नियंत्रक को कॉल करेगा और आपके द्वारा लिखे गए कार्यों को लागू करने की अनुमति देगा। डीबग, डीबग, डिबग ... एक बार जब आप खुश हैं तो सब ठीक है, मौजूदा फ़ोल्डर और फ़ाइलों को हटाएं जिन्हें आपने अपनी मुख्य साइट से माइग्रेट किया है, साथ ही वैश्विक.एएसएक्स सीएस में इग्नोर रूट नियम को हटा दें।

6. यदि आप पुरानी निर्देशिका और निरंतरता के लिए फ़ाइल नामों को संरक्षित करना चाहते हैं तो रीडायरेक्ट बनाएं (उदा। उपयोगकर्ता पहले से ही पुरानी साइट में कुछ पृष्ठों को बुकमार्क कर सकते हैं)।

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

युक्ति: गंभीर रूप से रूट डिबगिंग के लिए RouteDebug जैसे टूल का उपयोग करने पर विचार करें ताकि आप ऊपर की तरह अजीब चीज़ों को समझ सकें, या जब आपके पास कई रूटिंग नियम फायरिंग और अप्रत्याशित व्यवहार हो रहे हैं।

यह मेरा पहला मसौदा है, अगर मुझे कोई कदम याद आया है या आप गाइड में कोई छेद देखते हैं तो मुझे प्रतिक्रिया दें, और मैं उचित उत्तर को संशोधित करूंगा।

Answer 4

मई इन कुछ अतिरिक्त टिप

• बदलें <% मदद करेंगे - साथ @ टिप्पणी टैग *

• उपयोग @RenderSection @section पाद लेख के लिए ("पाद", झूठी) {} और इसलिए, यदि आपके पास कोई अतिरिक्त ContentPlaceHolder है जिसमें मुख्य शरीर को छोड़कर देखें रेंडरबॉडी()।

• सभी पुराने सामान्य runat = "सर्वर" टैग हानिरहित हैं और संकलन को नहीं रोकते हैं और बाद में साफ किया जा सकता

• सभी नियंत्रण दृश्यता जो आसानी से पीछे कोड और मार्कअप (दृष्टिगोचर में नियंत्रित किया गया था = " सच ") और में नियंत्रित नियंत्रण आईडी के उपयोग से व्यूबैग संग्रह और @if रेजर व्यू में ब्लॉक किया जाना चाहिए।

• आप भी Pluralsight के इस उत्कृष्ट बेशक यह विषय (3h 49m) के चारों ओर देख सकते हैं

  • Rebuilding Web Forms Applications in MVC