ASP.Net MVC बनाम वेब रूपों का उपयोग करने के लिए सबसे बड़ा लाभ


164

एक के बाद एक का उपयोग करने के कुछ फायदे क्या हैं?

जवाबों:


165

ASP.net MVC के मुख्य लाभ हैं:

  1. प्रदान किए गए HTML पर पूर्ण नियंत्रण सक्षम करता है।

  2. चिंताओं (SoC) की साफ जुदाई प्रदान करता है।

  3. टेस्ट ड्रिवेन डेवलपमेंट (TDD) सक्षम करता है ।

  4. जावास्क्रिप्ट चौखटे के साथ आसान एकीकरण।

  5. वेब के स्टेटलेस प्रकृति के डिजाइन का अनुसरण करना।

  6. Restful urls जो SEO को सक्षम करता है।

  7. कोई ViewState और पोस्टबैक इवेंट नहीं

ASP.net वेब फॉर्म का मुख्य लाभ हैं:

  1. यह आरएडी विकास प्रदान करता है

  2. विजेता विकास से आने वाले डेवलपर्स के लिए आसान विकास मॉडल।


32
SoC के बारे में, लोग इसे वैसे ही गड़बड़ कर सकते हैं, जैसे वे वेबफॉर्म पर उपयोग करते हैं, बहुत सारे व्यापारिक तर्क के साथ "वसा" नियंत्रक लिखकर या इसमें डेटा एक्सेस कोड भी। तो मैं कहूंगा कि SoC कुछ ऐसा है जो कोडर द्वारा प्रदान किया जाना चाहिए, fw मदद नहीं कर सकता है।
rodbv

7
@ rodbv: बहुत सही है, लेकिन MVC आपको सही दिशा में धकेलता है, या कम से कम आपको ऐसा करने के लिए हुप्स के माध्यम से नहीं कूदता है। तो शायद उस बिंदु को कुछ ऐसा पढ़ना चाहिए जैसे 'SoC को लागू करना आसान बनाता है'
Erik van Brakel

4
यह किसी भी अन्य विधि पर "टेस्ट ड्रिवेन डेवलपमेंट सक्षम करें" कैसे करता है? मुझे यह भी भ्रम है कि HttpContext.RewritePath मेथड (स्ट्रिंग) के बाद Restful urls कैसे अनुमति देता है।
मार्क ब्रॉडहर्स्ट

2
हालांकि ये बिंदु ज्यादातर एमवीसी पक्ष के लिए सटीक हैं, उनमें से बहुत से अब WebForms में एकीकृत किए जा रहे हैं।
rtpHarry

अधिक विवरण के साथ इस उत्तर के स्रोत से लिंक करें: weblogs.asp.net/shijuvarghese/archive/2008/07/09/…
DK।

91

ASP.NET वेब फॉर्म और MVC Microsoft द्वारा विकसित दो वेब फ्रेमवर्क हैं - वे दोनों अच्छे विकल्प हैं। न तो वेब फ्रेमवर्क को दूसरे द्वारा प्रतिस्थापित किया जाना है और न ही उन्हें एक फ्रेमवर्क में 'मर्ज' करने की योजना है। निरंतर समर्थन और विकास Microsoft द्वारा समानांतर रूप से किया जाता है और न ही 'दूर जा रहा' होगा।

इनमें से प्रत्येक वेब फ्रेमवर्क लाभ / हानि प्रदान करता है - जिनमें से कुछ को वेब एप्लिकेशन विकसित करते समय विचार करने की आवश्यकता होती है। एक वेब एप्लिकेशन को या तो प्रौद्योगिकी का उपयोग करके विकसित किया जा सकता है - यह एक विशेष एप्लिकेशन के लिए विकास को आसान बना सकता है एक प्रौद्योगिकी का चयन दूसरे के विपरीत और इसके विपरीत।

ASP.NET वेब फ़ॉर्म:

  • विकास राज्य का समर्थन करता है • यह भ्रम देता है कि एक वेब एप्लिकेशन इस बात से अवगत है कि उपयोगकर्ता विंडोज अनुप्रयोगों के समान क्या कर रहा है। यानी 'विज़ार्ड' की कार्यक्षमता को लागू करने के लिए थोड़ा आसान है। डेवलपर से उस जटिलता के बहुत से छिपाने पर वेब फॉर्म एक बहुत अच्छा काम करता है।
  • रैपिड एप्लीकेशन डेवलपमेंट (आरएडी) • सिर्फ 'जंप इन' करने की क्षमता और वेब फॉर्म पहुंचाना शुरू करना। यह MVC समुदाय के कुछ लोगों द्वारा विवादित है, लेकिन Microsoft द्वारा धकेल दिया गया है। अंत में, यह डेवलपर की विशेषज्ञता के स्तर पर आ जाता है और वे किस चीज के साथ सहज होते हैं। वेब फॉर्म मॉडल में संभवतः कम सीखने वाले डेवलपर्स के लिए सीखने की अवस्था कम है।
  • बड़ा नियंत्रण टूलबॉक्स • ASP.NET वेब फॉर्म बहुत अधिक और अधिक मजबूत टूलबॉक्स (वेब ​​नियंत्रण) प्रदान करता है जबकि MVC एक अधिक आदिम नियंत्रण सेट प्रदान करता है जो jQuery (जावास्क्रिप्ट) के माध्यम से समृद्ध क्लाइंट-साइड नियंत्रणों पर अधिक निर्भर करता है।
  • परिपक्व • यह 2002 के बाद से आसपास है और सवालों, समस्याओं, आदि के संबंध में जानकारी की एक बहुतायत है, अधिक तृतीय-पक्ष नियंत्रण प्रदान करता है - अपने मौजूदा टूलकिट पर विचार करने की आवश्यकता है।

ASP.NET MVC:

  • चिंताओं को अलग करना (SoC) • एक तकनीकी दृष्टिकोण से, MVC के भीतर कोड का संगठन बहुत साफ, व्यवस्थित और दानेदार है, जिससे वेब एप्लिकेशन के लिए कार्यक्षमता के मामले में बड़े पैमाने पर आसानी (उम्मीद) हो जाती है। एक विकास के दृष्टिकोण से महान डिजाइन को बढ़ावा देता है।
  • क्लाइंट साइड टूल (समृद्ध उपयोगकर्ता इंटरफ़ेस टूल) के साथ आसान एकीकरण • पहले से कहीं अधिक, वेब एप्लिकेशन तेजी से समृद्ध होते जा रहे हैं, जितना आपके डेस्कटॉप पर दिखाई देने वाले एप्लिकेशन। एमवीसी के साथ, यह आपको ऐसे टूलकिट (जैसे कि jQuery) के साथ एकीकृत करने की क्षमता देता है, जो वेब फॉर्म की तुलना में अधिक सहज और अधिक सहज है।
  • सर्च इंजन ऑप्टिमाइजेशन (SEO) फ्रेंडली / स्टेटलेस • URL सर्च इंजन (यानी mywebapplication.com/users/ 1 ) के लिए अधिक अनुकूल हैं - 1 बनाम mywebapplication / users / getuser .aspx (सेशन में पारित आईडी) के साथ उपयोगकर्ता को पुनः प्राप्त करते हैं। इसी तरह, चूंकि MVC स्टेटलेस है, इसलिए यह उन उपयोगकर्ताओं के सिरदर्द को दूर करता है जो एक ही विंडो (सत्र टकराव) से कई वेब ब्राउज़र को स्पॉन करते हैं। उन्हीं पंक्तियों के साथ, MVC इसके खिलाफ 'जूझ रहे' के बजाय स्टेटलेस वेब प्रोटोकॉल का पालन करता है।
  • उन डेवलपर्स के साथ अच्छी तरह से काम करता है जिन्हें उच्च स्तर के नियंत्रण की आवश्यकता होती है । ASP.NET वेब रूपों में कई नियंत्रण स्वचालित रूप से आपके द्वारा देखे गए कच्चे एचटीएमएल का बहुत कुछ उत्पन्न करते हैं जब एक पृष्ठ प्रदान किया जाता है। यह डेवलपर्स के लिए सिरदर्द पैदा कर सकता है। एमवीसी के साथ, यह अपने आप को बेहतर प्रदान करता है कि जो प्रदान किया गया है उसके साथ पूर्ण नियंत्रण है और कोई आश्चर्य नहीं है। इससे भी अधिक महत्वपूर्ण, यह है कि HTML रूप आमतौर पर वेब प्रपत्रों की तुलना में बहुत छोटे होते हैं जो एक प्रदर्शन को बढ़ावा दे सकते हैं - कुछ गंभीरता से विचार करने के लिए।
  • टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) • एमवीसी के साथ, आप चीजों के वेब पक्ष के लिए अधिक आसानी से परीक्षण बना सकते हैं। परीक्षण की एक अतिरिक्त परत अप्रत्याशित व्यवहार के खिलाफ रक्षा की एक और परत प्रदान करेगी।

प्रमाणीकरण, प्राधिकरण, कॉन्फ़िगरेशन, संकलन और परिनियोजन सभी सुविधाएँ हैं जो दो वेब फ्रेमवर्क के बीच साझा की जाती हैं ।


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

3
@ मूल - मुझे नहीं पता कि मैं व्यक्तिगत रूप से नीचा दिखाऊंगा, लेकिन मैं बाकी बातों से सहमत हूं कि आपने क्या कहा।
पीटर

4
@masty - नाइटपैकिंग द्वारा स्टैकऑवरफ्लो दुनिया को बचाने के लिए धन्यवाद और यह पूछने पर कि इस प्रश्न को अस्वीकृत कर दिया जाएगा। मैंने अपना उत्तर सिर्फ आपके लिए संपादित किया है - इसलिए उम्मीद है कि मुझे आपका वोट सबके साथ वापस मिल जाएगा, जिसे आपने इसे कम करने के लिए कहा था। धन्यवाद!
जेसी

6
@ मूल मैं आंशिक रूप से सहमत हूं, लेकिन जब शाब्दिक, प्लेसहोल्डर्स और रिपीटर्स का उपयोग कर रहे हैं, तो आप अधिक से अधिक html को कोडबाइंड में स्थानांतरित कर रहे हैं। जो कि .aspx पढ़ने वाले डिजाइनरों के लिए भ्रम पैदा कर सकता है, और .aspx.cs पढ़ने वाले कोडर्स के लिए। तो हाँ यह संभव है, लेकिन हाँ, यह ASP.Net WebForms के उद्देश्य को भी हरा देता है। मैं कहूंगा कि ControlAdapters उस मामले में एक क्लीनर समाधान हैं। नियंत्रणों को बदलने के बजाय, आप उनके द्वारा प्रदान किए गए तरीके को प्रतिस्थापित करते हैं।
एदियाकापी

2
बयान "एमवीसी के साथ, आपको जो प्रदान किया गया है उस पर पूरा नियंत्रण है" भ्रमित है। मुझे लगता है कि बेहतर बयान होगा, "MVC फ्रेमवर्क कम प्रतिपादन करता है और जो प्रदान किया जाता है वह अधिक दुबला होता है। आपको प्रदान किए गए विशिष्ट HTML / CSS पर अधिक नियंत्रण प्राप्त होता है, लेकिन आपको उस नियंत्रण को प्राप्त करने के लिए कार्य करना होगा।"
किंगिंगैंगो

17

क्लासिक एएसपी को याद करने के लिए कोई भी पुराना हो, उसे html और जावास्क्रिप्ट के साथ मिश्रित कोड वाला पृष्ठ खोलने का दुःस्वप्न याद होगा - यहां तक ​​कि सबसे छोटे पृष्ठ को यह पता लगाने के लिए दर्द था कि यह क्या कर रहा था। मैं गलत हो सकता हूं, और मुझे आशा है कि मैं हूं, लेकिन एमवीसी उन बुरे पुराने दिनों में वापस जाने की तरह दिखता है।

जब ASP.Net इसके साथ आया था तो उद्धारकर्ता के रूप में इसका स्वागत किया गया था, सामग्री से कोड को अलग करने और हमें वेब डिज़ाइनर बनाने की अनुमति देकर html और कोडर्स को पीछे के कोड पर काम करते हैं। अगर हम ViewState का उपयोग नहीं करना चाहते थे, तो हमने इसे बंद कर दिया। यदि हम किसी कारण से कोड का उपयोग नहीं करना चाहते हैं, तो हम अपने कोड को क्लासिक एएसपी की तरह ही html के अंदर रख सकते हैं। यदि हम PostBack का उपयोग नहीं करना चाहते हैं, तो हम प्रसंस्करण के लिए किसी अन्य पृष्ठ पर पुनर्निर्देशित कर देते हैं। यदि हम ASP.Net नियंत्रणों का उपयोग नहीं करना चाहते हैं तो हम मानक html नियंत्रणों का उपयोग करते हैं। यदि हम ASP.Net रनैट = "सर्वर" का उपयोग अपने नियंत्रण पर नहीं करना चाहते हैं, तो हम रिस्पांस ऑब्जेक्ट से भी पूछताछ कर सकते हैं।

अब किसी ने अपने महान ज्ञान में (शायद कोई व्यक्ति जिसने कभी एएसपी को प्रोग्राम नहीं किया था) ने निर्णय लिया है कि सामग्री के साथ कोड मिश्रण करने के दिनों में वापस जाएं और इसे "चिंताओं को अलग करना" कहें। ज़रूर, आप क्लीनर html बना सकते हैं, लेकिन आप क्लासिक एएसपी के साथ कर सकते हैं। यह कहने के लिए कि "आप सही ढंग से प्रोग्रामिंग नहीं कर रहे हैं यदि आपके पास अपने दृश्य के अंदर बहुत अधिक कोड है" तो यह कहना "जैसा है कि यदि आपने क्लासिक एएसपी में अच्छी तरह से संरचित और टिप्पणी की गई कोड लिखा है तो यह ASP.NET से कहीं अधिक साफ और बेहतर है"

अगर मैं सामग्री के साथ मिश्रण कोड पर वापस जाना चाहता था, तो मैं PHP का उपयोग करके विकास करूँगा जो उस तरह के विकास के लिए कहीं अधिक परिपक्व वातावरण है। अगर ASP.NET के साथ बहुत सारी समस्याएं हैं तो उन मुद्दों को ठीक क्यों नहीं किया जाए?

अंतिम लेकिन कम से कम नया रेजर इंजन का मतलब यह नहीं है कि HTML और कोड के बीच अंतर करना और भी कठिन है। कम से कम हम एएसपी में </%> टैग खोलने और बंद करने के लिए देख सकते थे, लेकिन अब केवल संकेत @ प्रतीक होगा।

यह समय हो सकता है कि PHP में स्थानांतरित हो और किसी और को कोड को एक बार फिर से सामग्री से अलग करने के लिए एक और 10 वर्षों तक इंतजार करना पड़े।


7
+1 स्पॉट पर। एमवीसी पर मेरी पहली प्रतिक्रिया थी कि मैं क्लासिक एएसपी को फिर से कर रहा था; केवल C # में इस बार VBScript की जगह।
डांसवाथबामो

3
मैं इस बात से हैरान हूँ कि इस उत्तर को यह बहुत सारे कारण मिले। सबसे पहले, ASP.NET MVC में निर्मित MVC का पृथक्करण है। बेशक, आपके लिए एएसपी में ऐसा करना संभव है। दूसरे, ASP.NET MVC क्लासिक ASP से बहुत अधिक है। यह बहुत उपयोगी सहायकों के साथ .NET की शक्ति के साथ मिलकर HTML पर ठीक-ठीक नियंत्रण प्रदान करता है। तीसरा, @ एक ठीक संकेतन है, जैसा कि <%%> है। आपके रेजर विचारों के लिए कोई भी सभ्य संपादक @ -नोटेशन का समर्थन करेगा। अंत में, PHP परिपक्व? me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design ASP.NET MVC एक बेहतरीन मंच है। इसे कुछ और ध्यान दें।
जेपी टेन बर्ज

क्या आप मेरे साथ मजाक कर रहे हैं? मैं अपने "<? ...?" संकेतन के साथ PHP का उपयोग कर रहा हूं और पाया है कि यह पूरी तरह से क्रिया है। मैं यह नहीं देखता कि "@" प्रतीक "<% ...%>" टैग की तुलना में कैसे पहचाना जाए। इसके अलावा आप शायद ही कभी HTML टेम्पलेट में "@" प्रतीक का उपयोग करते हैं।
निर्गमन

मेरी आँखें "<%%>" प्रतीकों के नरक की तुलना में एक रेजर पृष्ठ पर वास्तव में बेहतर आराम कर सकती हैं। .Aspx पेज पढ़ने से मुझे सिरदर्द होता है। मैं यह भी देखना पसंद करता हूं कि क्या प्रस्तुत किया जा रहा है। A @foreach (..) {<tr> ... </ tr>} ब्लॉक मुझे एक <abc: MyViewControl ID = "..." runat = "सर्वर" DatasourceID = "... की तुलना में अधिक आरामदायक महसूस कराता है। ”> मैं बहुत सारे क्लाइंट साइड हेरफेर करता हूं और मुझे यह जानना आवश्यक है कि कहां, और किस आईडी, शैली और कक्षाओं के साथ क्या प्रस्तुत किया जाएगा। मैं इसे उड़ने पर नियंत्रण करने की तुलना में खुद करना पसंद करता हूं। खासकर जब कुछ नियंत्रण अलग-अलग रूप से उनकी सेटिंग्स के आधार पर प्रदान किए जाते हैं।
थानिस इयोनिडिस

मुझे आश्चर्य है कि इसमें बदलाव है, यह एमवीसी ढांचे की पूरी गलतफहमी है। यदि आप MVC में सामग्री के साथ खुद को मिक्सिंग कोड पाते हैं, तो आप इसे गलत कर रहे हैं। आपके विचारों में सामग्री है, आपके नियंत्रक (और उनके द्वारा उपयोग की जाने वाली कक्षाएं) कोड हैं। यह एमवीसी के प्राथमिक सिद्धांतों में से एक है।
जोश नू

14

यदि आप अन्य डेवलपर्स के साथ काम कर रहे हैं, जैसे कि PHP या JSP (और मैं अनुमान लगाता हूं) - तो आप पृष्ठों पर रूपांतरण या सहयोग करने में बहुत आसान समय पाएंगे क्योंकि आपके पास उन सभी 'गंदा' ASP.NET नहीं हैं घटनाओं और नियंत्रण हर जगह।


"बहुत आसान समय" जो एक का उपयोग कर?
cregox

5
@cawas - MVC के साथ बहुत आसान है। ASP.NET MVC में कोई ईवेंट नहीं हैं। मूल रूप से आप मानक HTML और सीएसएस के साथ काम कर रहे हैं, न कि बहुत सी घटनाओं और नियंत्रणों को जो PHP / JSP डेवलपर्स को सीखने की आवश्यकता होगी
Simon_Weaver

ASP.NET WebForms और MVC दोनों का आधार है। लोग ASP.NET के साथ WebForms को भ्रमित करते हैं। कोई "MVC बनाम ASP.NET" नहीं है। "ASP.NET MVS" बनाम "ASP.NET WebForms" है। और वास्तव में वे एक-दूसरे से जूझ नहीं रहे हैं। वे अलग-अलग पेशेवरों और विपक्षों के साथ अलग-अलग तरीके हैं, एक वेबसाइट बनाने के लिए
थानैसिस इओनिडिस

13

एमवीसी के साथ समस्या यह है कि "विशेषज्ञों" के लिए भी यह बहुत मूल्यवान समय खाता है और इसके लिए बहुत प्रयास की आवश्यकता होती है। व्यवसाय बुनियादी चीज "क्विक सॉल्यूशन जो काम करता है" द्वारा संचालित होते हैं, इसके पीछे तकनीक की परवाह किए बिना। WebForms एक RAD तकनीक है जो समय और धन की बचत करती है। कुछ भी जिसके लिए अधिक समय की आवश्यकता होती है वह व्यवसायों द्वारा स्वीकार्य नहीं है।


1
व्यवसाय के लिए +1 मूल चीज़ "त्वरित समाधान जो काम करता है" द्वारा संचालित होता है
ड्रैगोस डर्लुत

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

1
उसके बाद, हमने उनके भारी और अनावश्यक क्लाइंट-साइड स्क्रिप्टिंग से छुटकारा पाने के लिए सभी नियंत्रणों को हटा दिया, और बूटस्ट्रैप्ड डेटा और घटनाओं के साथ मैनुअल HTML नियंत्रणों का प्रतिपादन किया, और jQuery और BackBone.js के संयोजन को समाप्त किया। यह वास्तव में एक वेब पेज में होस्ट किया गया MVC दृष्टिकोण है। बेशक, हालांकि अच्छे और योजनाबद्ध वेबफार्म और एमवीसी, दोनों ही वास्तव में अच्छा प्रदर्शन कर सकते हैं, लेकिन वेबफोर्म आपको अपने पेज पर नियंत्रण को टॉस करने के लिए सिर्फ अपनी स्क्रीन पर चलते हुए देखने के लिए टेंपर्ड करता है, और फिर आप इसे हटाने में अधिक समय लगाते हैं, यदि इसे हटा नहीं रहे हैं बिल्कुल भी।
थानिस इयोनिडिस

11
  1. उचित AJAX, जैसे JSONResults कोई आंशिक पृष्ठ पोस्टबैक बकवास नहीं है।
  2. कोई दृश्य नहीं +1
  3. HTML ID का कोई नाम नहीं।
  4. स्वच्छ HTML = कोई ब्लोट नहीं है और XHTML या मानकों के अनुरूप पृष्ठों को प्रस्तुत करने में एक अच्छा शॉट है।
  5. कोई और अधिक उत्पन्न AXD जावास्क्रिप्ट नहीं।

9

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


4
मैं मानता हूं कि यह एक प्रमुख विक्रय बिंदु है यदि आपने पहले कभी इस प्रकार के पैटर्न के साथ काम नहीं किया है, लेकिन आप WebForms में अपने MVC या MVP पैटर्न को लागू कर सकते हैं। लोगों को डेटासेट्स के साथ एक वेबफॉर्म को मोनोलिथ करने के बजाय एक पैटर्न पर ले जाने के लिए कुडोस, लेकिन वे उन लोगों के प्रकार को प्राप्त करते हैं जिन्हें मैं आमतौर पर किराए पर लेता हूं।
मार्क ब्रॉडहर्स्ट

9

मैंने ASP.Net पर MVC में कोई लाभ नहीं देखा है। 10 साल पहले MVC के जवाब के रूप में Microsoft UIP (उपयोगकर्ता इंटरफ़ेस प्रक्रिया) के साथ आया था। यह एक फ्लॉप थी। हमने UIP के साथ एक बड़ा प्रोजेक्ट (4 डेवलपर्स, 2 डिज़ाइनर, 1 टेस्टर) किया और फिर यह एक सरासर बुरा सपना था।

केवल प्रचार के लिए बैंडवादन में कूद मत। ऊपर सूचीबद्ध सभी फायदे पहले से ही Asp.Net में उपलब्ध हैं ( Asp.Net 4 में नई सुविधाएँ [ Asp.Net 4 में नई सुविधाएँ ])।

यदि आपकी विकास टीम या Asp.Net के साथ एक एकल डेवलपर परिवार बस इससे चिपके रहते हैं और अपने ग्राहकों (जो आपके काम के घंटों का भुगतान करते हैं) को संतुष्ट करने के लिए जल्दी से सुंदर उत्पाद बनाते हैं। MVC आपका मूल्यवान समय खाएगा और Asp.Net :-) के समान परिणाम देगा


1
डिफ़ॉल्ट रूप से देखने को अक्षम करना, जबकि इसे कभी-कभार नियंत्रण पर सक्षम करना जो कि वास्तव में ASP.NET में बहुत अच्छा कदम था। 4.
पीटीटी

WebForms और MVC दोनों ASP.NET के ऊपर बने हैं।
थानीस इओनिडिस

8

फ्रांसिस शहनहान,

  1. आप आंशिक पोस्टबैक को "बकवास" क्यों कहते हैं? यह अजाक्स की मुख्य विशेषता है और इसका उपयोग एटलस ढांचे में बहुत अच्छी तरह से किया गया है और टेलरिक जैसे अद्भुत तीसरे पक्ष के नियंत्रण हैं

  2. मैं आपके दृष्टिकोण के संबंध में सहमत हूं। लेकिन अगर डेवलपर्स व्यूस्टेट को अक्षम करने के लिए सावधान हैं, तो यह HTML के आकार को बहुत कम कर सकता है जो प्रदान किया जाता है इस प्रकार पृष्ठ हल्का वजन बन जाता है।

  3. ASP.NET वेब फॉर्म मॉडल में केवल HTML सर्वर नियंत्रणों का नाम बदला गया है न कि शुद्ध HTML नियंत्रण। जो कुछ भी हो सकता है, अगर नाम बदला गया है तो आप क्यों चिंतित हैं? मुझे पता है कि आप ग्राहक की बहुत सारी जावास्क्रिप्ट घटनाओं से निपटना चाहते हैं लेकिन यदि आप अपने वेब पेजों को स्मार्ट तरीके से डिजाइन करते हैं, तो आप निश्चित रूप से सभी आईडी प्राप्त कर सकते हैं जो आप चाहते हैं

  4. यहां तक ​​कि ASP.NET वेब फॉर्म एक्सएचटीएमएल मानकों को पूरा करता है और मुझे कोई ब्लोटिंग नहीं दिखाई देती है। यह एक औचित्य नहीं है कि हमें एमवीसी पैटर्न की आवश्यकता क्यों है

  5. फिर, आप AXD जावास्क्रिप्ट के साथ क्यों परेशान हैं? इससे आपको तकलीफ क्यों होती है? यह फिर से वैध औचित्य नहीं है

अब तक, मैं क्लासिक ASP.NET वेब रूपों का उपयोग करके विकासशील अनुप्रयोगों का प्रशंसक हूं। उदाहरण के लिए: यदि आप एक ड्रॉपडेललिस्ट या ग्रिडव्यू को बांधना चाहते हैं, तो आपको अधिकतम 30 मिनट की आवश्यकता होगी और कोड की 20 से अधिक पंक्तियों (न्यूनतम पाठ्यक्रम) की आवश्यकता नहीं होगी। लेकिन एमवीसी के मामले में, डेवलपर्स से बात करें कि यह कितना दर्द है।

एमवीसी का सबसे बड़ा नकारात्मक पहलू यह है कि हम एएसपी के दिनों में वापस जा रहे हैं। सर्वर कोड और HTML को मिलाने के स्पेगेटी कोड को याद रखें ??? हे भगवान, जावास्क्रिप्ट, HTML, JQuery, सीएसएस, सर्वर टैग के साथ मिश्रित एक MVC aspx पृष्ठ को पढ़ने की कोशिश करो और क्या नहीं .... कोई भी शरीर इस प्रश्न का उत्तर दे सकता है?


6
आंशिक
वापसी

3
अगर आपके विचार में बहुत सारे कोड हैं तो आप कुछ गलत कर रहे हैं। विचारों में कोड केवल चिंता का लेआउट होना चाहिए।
UpTheCreek

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

यदि आप एमवीसी का उपयोग करके स्पेगेटी कोड बना रहे हैं, तो आप चिंताओं को अलग करने का पालन नहीं कर रहे हैं और एक अच्छे वास्तुशिल्प मॉडल का उपयोग नहीं कर रहे हैं
jcvandan

1
दोनों का उपयोग करते हुए, मैं कह सकता हूं कि WebForms की तुलना में कुछ भी गड़बड़ नहीं है। एमवीसी सर्वर टैग को छोड़कर, साफ है, लेकिन इसके अलावा, सभी गड़बड़ खराब प्रोग्रामर का दोष है। MVC को डिज़ाइन से अलग तर्क के लिए कोर द्वारा डिज़ाइन किया गया है। इसके अलावा आप टेलरिक का उल्लेख करते हैं। ASP.Net AJAX के लिए Telerik इस तरह के एक गन्दा कोड का कारण बनता है। गति का उल्लेख नहीं है, (हलचल) एक टेलर ग्रिड को छांटना: ASP.Net WebForms में 4 पृष्ठों के लिए 500ms, MVC में 84 पृष्ठों के लिए 200ms लेता है। (क्रोम के लिए उनके डेमो और फायरबग का उपयोग करके परीक्षण किया गया।) जब प्रदर्शन और अलगाव की बात आती है, तो एमवीसी निश्चित रूप से जीतता है।
इदियाकापी

6

वेब फॉर्म भी अधिक परिपक्वता से लाभ प्राप्त करते हैं और टेलरिक जैसे तीसरे पक्ष के नियंत्रण प्रदाताओं से समर्थन प्राप्त करते हैं।


2
यह कहते हुए कि यह एमवीसी के साथ नहीं किया जा सकता है, क्योंकि मुझे यकीन है कि यह है, लेकिन अगर आप एक त्वरित और गंदे इंट्रानेट या एक्स्ट्रानेट ऐप को एक साथ मारना चाहते हैं, तो बहुत सारे ब्लिंग टेलरिक और वेबफोर्म को हराना मुश्किल है। ज्वाला दूर, ईमानदार सच्चाई tis।
infocyde

Telerik में MVC नियंत्रण भी है (कम, और कम विकल्पों के साथ, लेकिन फिर भी उनके पास यह है), और वे अपने वेबफ़ॉर्म वेरिएंट की तुलना में बहुत अधिक तेजी से हैं।
इदियाकापी

5

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

मैं कहूंगा कि MVC का सबसे बड़ा फायदा SPEED है!

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


क्या आपका मतलब विकास की गति या निष्पादन की गति है?
जूल्स

1
खासकर जब एमवीसी के साथ टेलरिक का उपयोग कर रहे हों। उनके डेमो से, एक ग्रिड की छँटाई होती है: 4 पेज (वेबफार्म) के लिए 500 ग्राम, 84 पेज (एमवीसी) के लिए 200 ग्राम। मेरे लिए MVC की प्राथमिकता क्या है (भले ही हम अपनी कंपनी में WebForms का उपयोग करते हैं, हमें लगा कि हम स्विच बनाने पर विचार कर रहे हैं), क्या यह क्लीनर है, आपके पास अपने विचार हैं, जहां आप अपना आउटपुट, अपना मॉडल, जहाँ आप गड़बड़ करते हैं, को अनुकूलित करते हैं डेटा अप करें: P, और आपके नियंत्रक जो इसे एक साथ रखते हैं
Aidiakapi

4

मेरे 2 सेंट:

  • रैपिड एप्लिकेशन डेवलपमेंट और व्यापार मूल्य को जल्दी जोड़ने के लिए ASP.net फ़ॉर्म महान हैं। मैं अभी भी ज्यादातर इंट्रानेट अनुप्रयोगों के लिए इसका उपयोग करता हूं।
  • MVC सर्च इंजन ऑप्टिमाइजेशन के लिए बहुत अच्छा है क्योंकि आप URL और HTML को अधिक हद तक नियंत्रित करते हैं
  • एमवीसी आम तौर पर एक बहुत अधिक दुबला पृष्ठ का उत्पादन करता है - कोई व्यूस्टेट और क्लीनर HTML = त्वरित लोडिंग समय नहीं
  • MVC पृष्ठ के भाग को कैश करना आसान है। -एमवीसी लिखने में मजेदार है: - व्यक्तिगत राय ;-)

3

एमवीसी आपको एक पृष्ठ पर एक से अधिक फॉर्म देता है, एक छोटी सी सुविधा जिसे मैं जानता हूं लेकिन यह आसान है!

इसके अलावा एमवीसी पैटर्न मुझे लगता है कि कोड को बनाए रखना आसान है, एस्प। जब आप कुछ महीनों के बाद इसका पुनरीक्षण करेंगे।


2
ASP.NET वेबफ़ॉर्म आपको एक पृष्ठ पर जितने चाहें उतने रूप देता है। सीमा यह है कि केवल एक ही "रनैट =" सर्वर "विशेषता हो सकता है।
आंद्रेई रोनेया

1
@AndreiRinea मुझे लगता है कि उनका मतलब है कि: पी, runat="server"जब आप अभी भी वेबफ़ॉर्म का उपयोग करना चाहते हैं, तो नॉन फॉर्म टैग में बहुत अधिक उपयोग नहीं होता है , और जब से आप रूपों को नहीं कर सकते / नहीं चाहिए, मुझे लगता है कि यह थोड़े स्पष्ट है कि उनका क्या मतलब है :)
इदियाकापी

2

MVC नियंत्रक:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

MVC देखें:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

कितना कठिन है? कोई ViewState, कोई बीएस पेज जीवन-चक्र ... बस शुद्ध कुशल कोड।


1

मैं छोटी साइटों के लिए केवल दो फायदे देख सकता हूं: 6) एसईओ करने में सक्षम यूआरएल। 7) कोई ViewState और पोस्टबैक इवेंट (और सामान्य रूप से अधिक प्रदर्शन)

छोटी साइटों के लिए परीक्षण कोई समस्या नहीं है, न ही डिज़ाइन के फायदे हैं जब किसी साइट को वैसे भी ठीक से कोडित किया जाता है, एमवीसी कई मायनों में बाधा डालता है और बनाने के लिए परिवर्तनों को कठिन बनाता है। मैं अभी भी तय कर रहा हूं कि क्या ये फायदे इसके लायक हैं।

मैं बड़ी मल्टी-डेवलपर साइटों में एमवीसी का लाभ स्पष्ट रूप से देख सकता हूं।


1

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

Webforms और MVC दोनों व्यवहार्य उपकरण हैं, दोनों विभिन्न क्षेत्रों में उत्कृष्ट हैं।

मैं व्यक्तिगत रूप से वेब रूपों का उपयोग करता हूं क्योंकि हम मुख्य रूप से बी 2 बी / एलओबी ऐप विकसित करते हैं। लेकिन हम हमेशा इसे एमवीपी पैटर्न के साथ करते हैं, जिसमें हम अपनी यूनिट परीक्षणों के लिए 95 +% कोड कवरेज प्राप्त कर सकते हैं। यह भी वेबकंट्रोल की संपत्ति के गुणों पर परीक्षण को स्वचालित करने के लिए हमें बदल देता है संपत्ति मूल्य को उदाहरण के माध्यम से उजागर किया जाता है

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) मुझे नहीं लगता कि परीक्षण के इस स्तर को MVC में आसानी से प्राप्त किया जा सकता है, मेरे मॉडल को विचलित किए बिना।


0

अब आप 'नॉन-पोस्ट-बैक कंट्रोल' का उपयोग करने के बारे में बुरा महसूस नहीं करते हैं - और यह अनुमान लगाते हैं कि उन्हें पारंपरिक asp.net वातावरण में कैसे नष्ट किया जाए।

इसका मतलब है कि आधुनिक (उपयोग करने के लिए स्वतंत्र) जावास्क्रिप्ट नियंत्रण इस तरह के इस या इस या इस सब है कि एक वर्ग छेद महसूस में एक दौर खूंटी फिट करने की कोशिश के बिना इस्तेमाल किया जा सकता।


0

आधुनिक जावास्क्रिप्ट नियंत्रण के साथ-साथ JSON अनुरोधों को MVC का उपयोग करके बहुत आसानी से नियंत्रित किया जा सकता है। वहां हम एक एक्शन से दूसरी एक्शन तक डेटा पोस्ट करने के लिए कई अन्य तंत्रों का उपयोग कर सकते हैं। यही कारण है कि हम वेब रूपों पर MVC पसंद करते हैं। इसके अलावा, हम हल्के वजन पृष्ठों का निर्माण कर सकते हैं।


0

मेरी निजी राय है कि, ASP.Net MVC का उपयोग करने के लिए सबसे बड़ा डिस-बेनेफिट ... उन डेवलपर्स के लिए html नरक के CODE BLOCKSसाथ मिलाया जाता है, जो इसे बनाए रखते हैं ...HTML

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.