MVC पर ASP.NET WebForms का पक्ष कब लें

Question

मुझे पता है कि Microsoft ने कहा है

ASP.NET MVC WebForms के लिए एक प्रतिस्थापन नहीं है।

और कुछ डेवलपर्स का कहना है कि WebForms MVC की तुलना में विकसित होने के लिए तेज़ है। लेकिन मेरा मानना ​​है कि कोडिंग की गति तकनीक के साथ आराम के स्तर तक आ जाती है इसलिए मुझे उस नस में कोई जवाब नहीं चाहिए।

यह देखते हुए कि ASP.NET MVC एक डेवलपर को उनके आवेदन पर अधिक नियंत्रण देता है, WebForms को अप्रचलित क्यों नहीं माना जाता है? वैकल्पिक रूप से, मुझे नए विकास के लिए MVC पर WebForms का पक्ष कब लेना चाहिए?

Comments

@ रात: \ _ यह बहुत पक्षपाती और गलत है। MVC सरल CRUD ऐप्स के लिए नहीं है। मेरा तर्क है कि WebForms सामान्य CRUD ऐप (यानी डेटाबेस -> कुछ चमकदार ग्रिड नियंत्रण) के लिए है।

— रेयानोस

@Darknight जो भी आपको खुश करता है -> अगर आपको WebForms पसंद है तो उसके साथ पागल हो जाओ;)

— Raynos

@Darknight आपको स्पष्ट रूप से एमवीसी की एक खराब समझ है अगर यह आपकी राय है ... कुछ विशाल साइटें हैं जो एमवीसी के साथ बनाई गई हैं ... क्या आप कोई शोध नहीं करते हैं।

— रोबोट्सुशी

जब आप MVC का उपयोग कर सकते हैं तो IMO, कभी भी वेबफॉर्म का उपयोग न करें।

— स्कॉचशूलथेस

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

— 14

Answer 1

वेबफॉर्म बनाम एमवीसी अभी एक गर्म विषय लगता है। हर कोई जानता है कि मैं एमवीसी को अगले महान चीज के रूप में देखता हूं। इसमें मेरी थोड़ी-सी भी दबंगई से यह ठीक लगता है, लेकिन नहीं, मुझे नहीं लगता कि यह वेबफॉर्म का अंत होगा।

मेरा तर्क, और यह तर्क कि वेबफॉर्म को MVC के ऊपर क्यों चुना जाएगा, का व्यवसाय के नजरिए से अधिक होता है बजाय इसके कि कोई दूसरे से बेहतर हो।

समय / धन सबसे बड़ा कारण है कि वेबफॉर्म को एमवीसी पर चुना जाएगा।

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

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

मैं यह नहीं कह रहा हूँ कि यह सब कुछ है या यहाँ कुछ भी नहीं है, लेकिन यह दोनों को विभाजित करने के लिए आपके कोड को कठिन बना देता है, खासकर अगर टीम के सभी लोग MVC से परिचित नहीं हैं।

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

हमें इन पृष्ठों के लिए एक पूरी नई फ़ोल्डर संरचना बनाने की आवश्यकता थी ताकि यह उचित एमवीसी पृथक्करण का पालन करे।

मुझे लगा कि 3 पृष्ठों के लिए बहुत सारी फाइलें थीं, लेकिन यह मेरी निजी राय है।

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

Comments

यह एक अच्छा जवाब है। मैंने आपको +1 दिया क्योंकि आपके व्यक्तिगत अनुभवों की सराहना की जाती है। लेकिन, यह डेवलपर्स के अनुभव / कौशल-सेट की कमी के कारण विफलता है, जिसे मैंने बचने के लिए कहा था। मुझे विश्वास नहीं हो रहा है कि Microsoft केवल MVC के लिए सीखने की अवस्था के डर के कारण अप्रचलित प्रौद्योगिकी को चिह्नित नहीं करना पसंद करेगा। यह मामला हो सकता है, लेकिन मैं अभी तक आश्वस्त नहीं हूं।

— पी। ब्रायन। मैके जूल 22'11

@ P.Brian.Mackey - मैंने यह नहीं कहा कि MVC की तुलना में फ़ॉर्म का विकास तेज़ है। आपने उस तर्क को छोड़ने को कहा। अपने कर्मचारियों को प्रशिक्षित करने के लिए समय और पैसा देना एक अलग तर्क है। MS वेबफ़ॉर्म को एक बड़े कारण के लिए अप्रचलित नहीं करेगा: एंटरप्राइज़ क्लाइंट ने वेबफ़ॉर्म में वेब क्लाइंट विकसित करने में वर्षों बिताए हैं और अपडेट करने के लिए समय और धन का निवेश करने के लिए विनम्र नहीं दिखेंगे।

— त्यान्ना

@ रेयानोस - अगर टीम में हर कोई एमवीसी में निपुण था, और आपकी कंपनी एक नई परियोजना शुरू कर रही थी, तो इसका एकमात्र कारण मैं किसी को वेबफॉर्म चुनना पसंद कर सकता हूं।

— तियाना

मैं दोनों तकनीकों को गहनता से जानता हूं। मेरी सभी वेब परियोजनाएं mvc के साथ की जाती हैं और एक ऐसी कंपनी में काम करती हैं जहाँ मेरा सबसे अच्छा तरीका है जो करने के लिए स्वतंत्र शासन है। मैं हमेशा एमवीसी को चुनता हूं।

— रोबोट्सुशी

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

— मफिन मैन

Answer 2

मैंने 3 साल के लिए ASP .Net WebForms अनुप्रयोगों का विकास किया, और एक MVC ट्यूटोरियल करने के एक दिन बाद मुझे बेचा गया। MVC लगभग बेहतर समाधान है। क्यों?

• पृष्ठ का जीवनचक्र सरल और अधिक कुशल है
• Html नियंत्रण के अलावा नियंत्रण जैसी कोई चीज नहीं है। आपको अपने आउटपुट को डीबग करने की आवश्यकता नहीं है कि एएसपी .नेट क्या पैदा कर रहा है।
• ViewModels आपको अपार शक्ति देता है और मैनुअल कंट्रोल बाइंडिंग करने की आवश्यकता को कम करता है और यह बाइंडिंग से संबंधित कई त्रुटियों को समाप्त करता है।
• आपके पास एक पृष्ठ पर कई रूप हो सकते हैं। यह WebForms की एक गंभीर सीमा थी।
• वेब स्टेटलेस है और एमवीसी वेब की वास्तुकला से अधिक निकटता से मेल खाता है। वेबफॉर्म राज्य और आपके द्वारा देखे जाने वाले बग्स को व्यूस्टेट की शुरुआत करके प्रस्तुत करता है। ViewState स्वचालित है और पृष्ठभूमि में काम करता है, इसलिए यह हमेशा उस तरह से व्यवहार नहीं करता है जैसा आप इसे चाहते हैं।
• वेब एप्लिकेशन को इन दिनों अजाक्स के साथ काम करने की आवश्यकता होती है। यह पूर्ण पृष्ठ लोड करने के लिए स्वीकार्य नहीं है। MVC अजाक्स को JQuery के साथ इतना बेहतर, आसान और अधिक कुशल बनाता है।
• चूँकि आपके पास एक पृष्ठ पर कई रूप हो सकते हैं, और क्योंकि आर्किटेक्चर उरेल के लिए कॉल द्वारा संचालित होता है, अजाक्स की तरह आप फंकी चीजें कर सकते हैं, एक अलग रूप लोड करते हैं, जैसे JQuery का उपयोग करके अपने वर्तमान पृष्ठ में एक संपादित रूप। एक बार जब आप महसूस करते हैं कि इससे आप क्या कर सकते हैं तो आप आश्चर्यजनक चीजें आसानी से कर सकते हैं।
• ASP .Net WebForms केवल html पर अमूर्त नहीं है, यह एक अत्यंत जटिल है। कभी-कभी आपको एक अजीब बग मिलता है और ज़रूरत से ज़्यादा लंबे समय तक इसके साथ संघर्ष करना पड़ता है। कई मामलों में आप वास्तव में देख सकते हैं कि यह क्या गलत कर रहा था लेकिन आप इसके बारे में कुछ भी करने में असमर्थ हैं। आप अजीब तरह के वर्कअराउंड करते हैं।
• WebForms डिजाइनरों के लिए एक अच्छी तकनीक नहीं बनाते हैं। डिजाइनर अक्सर सीधे html के साथ काम करना पसंद करते हैं। एमवीसी में, यह वेबफॉर्म्स में, काम का आधा दिन है।
• के रूप में वेब मंच तेजी से विकसित हो रहा है WebForms अभ्यस्त रखना। यह HTML5 के नए टैग या विशेषताओं के बारे में पता नहीं है, यह तब भी उसी सामान को प्रस्तुत करेगा जब तक कि आपको (अक्सर) महंगे 3 पार्टी नियंत्रण नहीं मिलते या Microsoft को अपडेट जारी करने के लिए इंतजार न करें।
• WebForms में नियंत्रण आपको इतने तरीकों से सीमित करता है। MVC में आप सिर्फ JQuery लाइब्रेरी को पकड़ सकते हैं और इसे अपने टेम्प्लेट में एकीकृत कर सकते हैं।

मुझे पता है कि ऊपर दिए गए कुछ मुद्दों को कुछ हद तक संबोधित किया गया है क्योंकि WebForms विकसित होते हैं, लेकिन यह मेरा मूल अनुभव था। सभी में मुझे WebForms के लिए एक व्यावसायिक मामला खोजने में बहुत मुश्किल होगा जब तक कि कोई परियोजना पहले से ही इसका उपयोग नहीं कर रही है।

Comments

कई रूपों को इंगित करने के लिए +1। प्लस तथ्य यह है कि HTML webforms उत्पन्न ज्यादातर समय एसईओ के अनुकूल नहीं है (जैसा कि: पृष्ठ के शीर्ष पर देखने का बड़ा हिस्सा)

— jao

मुझे इस उत्तर के साथ 100% सहमत होना होगा। दिन के अंत में, WebForms ग्राहक पक्ष (html / ब्राउज़र) पर बहुत कठिन काम करता है। आपको सचमुच कुछ काम करने के लिए रूपरेखा से लड़ना होगा। एक aspx पेज आमतौर पर करता है एक cshtml पेज की तुलना में सर्वर नियंत्रण के कारण बहुत अधिक कोड के साथ समाप्त होता है। @ šljaker यदि आप ViewState को बंद करना शुरू करते हैं और सर्वर नियंत्रण से बचते हैं, तो आपने उस बिंदु पर बहुत सारे WebForms छोड़ दिए हैं। मैं उस तर्क को विशेष रूप से आश्वस्त नहीं देखता।

— एंडी १

आप WebForms में सादे HTML नियंत्रण रख सकते हैं, कोई भी आपको सर्वर नियंत्रण का उपयोग करने के लिए मजबूर नहीं करता है। आपके पास पूर्ण स्टेटलेस वेबफॉर्म हो सकता है, कोई भी आपको ViewState का उपयोग करने के लिए मजबूर नहीं करेगा। आप Webjs में पूर्ण ajax और jQuery का उपयोग कर सकते हैं, कोई भी आपको jQuery के उपयोग से प्रतिबंधित नहीं कर रहा है। आप URL रूटिंग को लागू कर सकते हैं, कोई भी आपको स्थिर फ़ाइल बेस URL का उपयोग करने के लिए बाध्य नहीं करता है। मैन्युअल रूप से सीएसएस के साथ एक पृष्ठ खींचना उस समय का उपभोग करता है जितना कि एमवीसी की आवश्यकता होती है। आप HTML पेज को सीधे वेबफॉर्म पर डिजाइन कर सकते हैं।

— mjb

@ एमजेबी: यदि आप सर्वर नियंत्रण, व्यूस्टेट और इतने पर उपयोग नहीं करते हैं, तो एमवीसी जब आप कर रहे हैं, तब वेबफार्म का उपयोग क्यों करें? यह काम करने के लिए ट्रैक्टर चलाने जैसा है, लेकिन किसी भी तरह की गड़बड़ी या फावड़ा / कुदाल या स्टेबलाइजर बार का उपयोग नहीं करना। उस बिंदु पर क्यों न सिर्फ एक कार का उपयोग करें?

— नेल्सन रॉदरमेल

@ टैजार्ट यह सही नहीं है कि आपके पास ASPNET पेज पर कई रूप हैं। आपके पास ASPNET पेज में जितने चाहें उतने फॉर्म हो सकते हैं लेकिन आपके पास केवल एक सर्वर फॉर्म हो सकता है - रनैट = "सर्वर" विशेषता के साथ।

— कुंसविक

Answer 3

मैंने स्कॉट गुथरी को ईमेल किया , जो माइक्रोसॉफ्ट में एमवीसी विशेषज्ञ हैं । और शायद इस सवाल का जवाब देने के लिए सबसे योग्य आदमी। वह उत्तर देने के लिए पर्याप्त था:

"विभिन्न ग्राहक अलग-अलग प्रोग्रामिंग दृष्टिकोणों की तलाश करते हैं, और बहुत सारे वेबफोर्म पसंद करते हैं और सोचते हैं कि यह बहुत अच्छा है। अन्य लोग एमवीसी को पसंद करते हैं और सोचते हैं कि यह बहुत अच्छा है। इस कारण हम दोनों में निवेश कर रहे हैं।"

इसलिए, मेरा यह कहना है कि इसका तकनीकी मुद्दा नहीं है। यदि आप करेंगे, तो यह एक "नरम मुद्दा" है। व्यक्तिगत पसंद में से एक। यह आपके द्वारा कही गई बातों के अनुरूप है।

सारे सवालों के जवाब देने के लिए धन्यवाद।

Comments

स्कॉट गुथरी ने ASP.NET के लिए MVC फ्रेमवर्क का आविष्कार किया, जबकि 2006/7 में लंदन से सिएटल के लिए उड़ान भरी। यह सोचने के लिए आओ, उन्होंने बहुत ज्यादा .NET का आविष्कार किया ( en.wikipedia.org/wiki/Scott_Guthrie )। उसे "विशेषज्ञ" कहना भारी समझ है;;

— बेंजामिन हावर्थ

यह स्कॉट गुथरी का एक अच्छा राजनीतिक जवाब है। यदि वह स्वयं अपना वेब एप्लिकेशन निवेश कर रहा था, तो आपको एक एमवीसी प्रोजेक्ट दिखाई देगा और एमवीसी में ऐसा कुछ भी नहीं किया जा सकता है, सिल्वरलाइट गिरावट होगी। WebForms के प्रति नकारात्मक टिप्पणी के रूप में इसे न लें, मुझे लगता है कि WebForms छोटे स्कॉप्ड आंतरिक अनुप्रयोगों के लिए महान हैं जो कि 3 पार्टी घटकों जैसे कि Telerik द्वारा बनाए गए लोगों से लाभ उठा सकते हैं। मुझे खुशी है कि Microsoft दोनों तकनीकों के साथ आगे बढ़ रहा है।

— सीन चेस

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

— जॉन मैकइंटायर

"यही कारण है कि हम दोनों में निवेश कर रहे हैं।" और जब हम देखते हैं कि वेब फॉर्म में गिरावट शुरू हो रही है, तो हम इसे निर्दयता से छोड़ देंगे क्योंकि अंततः एक मृत उत्पाद में निवेश करना हमारे व्यावसायिक हित में नहीं है।

— क्वैन्ड्री

जब तक यह स्कूलों में नहीं पढ़ाया जाता है, तब तक कई वर्षों तक यह हमेशा व्यापार की दुनिया में लागू रहेगा। कॉलेज और हाई स्कूल vb.net में इंट्रो और उन्नत पाठ्यक्रम प्रदान करते हैं। कहीं भी नहीं जा रहा है !!!

— htm11h

Answer 4

यह बहुत सारे सवालों के साथ एक बासी सवाल है लेकिन किसी के पास ऐसा कोई जवाब नहीं था जिसकी मुझे उम्मीद थी कि मैं सूचीबद्ध होऊंगा।

संक्षिप्त उत्तर है:

• यदि आप ASP.NET प्लेटफॉर्म के लिए आधुनिक प्रोग्रामिंग कन्वेंशन और उद्योग से जुड़े पैटर्न के साथ वेब एप्लिकेशन बनाने का इरादा रखते हैं, तो ASP.NET MVC का उपयोग करें। नीचे की ओर आपको यह जानने की उम्मीद होगी कि HTML और क्लाइंट-साइड संसाधन (जावास्क्रिप्ट, सीएसएस) कैसे काम करते हैं और साथ ही साथ एमवीसी प्रोग्रामिंग मानसिकता पर रैंप अप करते हैं, जिसमें एक सीखने की अवस्था होती है, लेकिन एक बार अचानक पहुंच जाता है।
• ASP.NET वेब फॉर्म का उपयोग करें यदि आप GUI -centric, RAD (रैपिड एप्लिकेशन डेवलपमेंट) का उपयोग करना चाहते हैं , तो किसी चीज़ को बहुत तेज़ी से प्रोटोटाइप करने के लिए ड्रैग-एंड-ड्रॉप दृष्टिकोण, यानी पुश-बटन / डेटा ग्रिड व्यवहार के भीतर वायर्ड 15 मिनट, और समाधान डेवलपर्स द्वारा समर्थित कुछ होने का इरादा नहीं है। या, उपयोग ASP.NET वेब प्रपत्र आप में एक पृष्ठभूमि है, तो जीयूआई या Windows Forms विकास और आप वेब के लिए अपने ज्ञान का हस्तांतरण करने के लिए इच्छा।

लेकिन इसे ठीक से देखने के लिए, आपको प्रत्येक के इतिहास को समझना होगा।

ASP.NET वेब फॉर्म उन लोगों के लिए Microsoft का जवाब था, जो विजुअल बेसिक 6 एक्टिवएक्स कंट्रोल, सर्वर पर VB6 DLLs और ASP क्लासिक का उपयोग करके डायनामिक वेब एप्लिकेशन का निर्माण कर रहे थे। उस समय, इन Microsoft उपकरणों का उपयोग करके वेब विकास एक वास्तविक गड़बड़ था। .NET फ्रेमवर्क की संपूर्णता के साथ, जो कि Microsoft का उत्पादन अनिवार्य रूप से ड्रॉइंग बोर्ड पर वापस जा रहा था कि विंडोज स्टैक पर उत्पादक व्यावसायिक प्रोग्रामिंग कैसे करें, ASP.NET वेब फॉर्म अपने दिन में अद्भुत और सुंदर था।

संपूर्ण दृष्टिकोण डेवलपर्स को विंडोज़ एप्लिकेशन के विकास के समान कुछ के दोनों दुनिया के सर्वश्रेष्ठ देने के लिए था, लेकिन इंटरनेट सेवाओं की शक्ति के साथ। विचार यह था कि, जैसे कि VB6 / WinForms "फ़ॉर्म" (एक विंडो) के साथ, वैसे ही एक वेब पेज एक रूप है (बस एक खिड़की की तरह, देखें) , और उस रूप में आप लेबल, ड्रॉप-डाउन ड्रॉप कर सकते हैं। डेटा ग्रिड, बटन और अन्य चीजें जो VB / WinForms GUI डेवलपर्स के आदी थे।

एक बटन बनाने के लिए कुछ करें, इसे खींचने और छोड़ने के बाद, आप इसे सिर्फ डिजाइनर पर डबल-क्लिक करें और बूम में आप कोड संपादक में हैं, उस फॉर्म को बताते हुए कि क्या करना है जब "क्लिक" इवेंट होता है। यह बिल्कुल वैसा ही था जैसे विंडोज GUI डेवलपर्स ने VB6 के GUI टूलिंग और प्रतिस्पर्धी टूल का उपयोग करके सॉफ्टवेयर बनाया था , सिवाय अब कोड सर्वर पर निष्पादित हो रहा है! वाह!

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

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

बैक अप लें। अपने हाथ धो लो। आइए व्यवसाय की समस्या पर फिर से गौर करें। हमारे व्यावसायिक उद्देश्य क्या हैं?

हमें वेब एप्लिकेशन बनाने और प्रबंधित करने की आवश्यकता है । हमारी अड़चन यह है कि हमारे पास वर्ल्ड वाइड वेब है, जो HTTP, HTML, Javascript, और CSS पर बैठता है, और सर्वर पर हमारे पास व्यापार नियम, डेटाबेस और कुछ बड़ी प्रोग्रामिंग भाषाएं (जैसे C #) हैं। क्या वास्तव में हमें अपनी विकास पद्धति को चलाने के लिए इस विंडोज GUI रूपक की आवश्यकता है? हम सिर्फ आवेदन की समस्याओं पर ध्यान केंद्रित क्यों नहीं कर सकते हैं और जीयूआई रूपकों के साथ दूर क्यों कर सकते हैं?

यह वह जगह है जहाँ ASP.NET MVC आता है। यह उन डेवलपर्स के विद्रोह से शुरू हुआ था, जिन्होंने खुद को "Alt.Net" कहा था, जो उचित और शुद्ध सॉफ्टवेयर विकास सिद्धांतों पर वापस जाना चाहते थे। कोई और अधिक उपद्रव और उपद्रव नहीं है, बस व्यावसायिक उद्देश्यों और सॉफ्टवेयर सर्वोत्तम प्रथाओं पर ध्यान केंद्रित करें।

इस मामले में वास्तव में इसका क्या अनुवाद है:

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

ध्यान दें कि HTML पहले से ही एक उच्च-स्तरीय मार्कअप भाषा है, जैसा कि जावास्क्रिप्ट एक उच्च-स्तरीय प्रोग्रामिंग भाषा है। पूरी कहानी अलग होती अगर हम विधानसभा की भाषा और सी के साथ काम कर रहे होते।

# 2 पर विस्तार करते हुए, ASP.NET MVC का एक अन्य उद्देश्य डेवलपर्स को उनके समाधानों के 'दृश्य' भाग के सामने के अंत के विवरण को व्यवस्थित करने में सक्षम बनाना और उस समृद्ध नींव का लाभ उठाना है जो बाकी उद्योग ने बनाया है। फ्रंट-एंड क्लाइंट प्लेटफ़ॉर्म।

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

Comments

यह एक अच्छा उत्तर है, लेकिन # 1 और # 2 गलत हैं (WF को यह जानने के लिए एक घटक की आवश्यकता नहीं है कि इसका डेटा कहां से आता है, यह एक विकल्प है और आपने हमेशा अपने ASPX फ़ाइलों में HTML को अपने द्वारा टैग किए गए एस्प का समर्थन करने के लिए जोड़ा है प्रतिपादन। आपको कभी भी गहरी खुदाई करने और नियंत्रण से लड़ने की आवश्यकता नहीं होती है जब तक कि आप एएसपी सुविधा का उपयोग करने की कोशिश नहीं कर रहे हैं जो डेवलपर बातचीत के लिए अभिप्रेत नहीं है। बड़े बिंदु परीक्षण क्षमता और डिजाइन पैटर्न हैं।)

— 23:16 बजे ट्रिस्टेड

Answer 5

मैं ASP.NET MVC में एक पूर्ण और कुल रूपांतरित हूं और पीछे मुड़कर नहीं देखा, कहा कि मुझे अभी भी कई बड़े WebForms ऐप बनाए रखने हैं। यहाँ मेरा उस पर ले लो:

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

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

अंत में, मेरे लिए, यह ग्रिड और ग्रिड के लिए आता है। :)

Comments

अच्छी तस्वीर के लिए +1 "निफ्टी कोड-पीछे फ़ाइल से बाड़ के दोनों किनारों को चलाने" के साथ दिया गया।

— मार्सेल

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

— शीतदंश

Answer 6

मेरा अनुभव:

• एक साल के लिए CakePHP परियोजनाओं को लिखा।
• छह महीने में एक मध्यम आकार की वेबफॉर्म परियोजना पूरी की।
• तीन साल के लिए विंडोज फॉर्म प्रोजेक्ट पर काम किया।

उस अनुभव के बाद, मैंने वेबफॉर्म का उपयोग करते हुए एक और ऐप लिखने की कोशिश की, और एक दिन के लिए संघर्ष करने के बाद निराश हो गया कि कैसे वेबफार्मर डेवलपर को वास्तविकता से ढालने का प्रयास करता है कि वे एक एप्लिकेशन विकसित कर रहे हैं जो HTML, जावास्क्रिप्ट और सीएसएस का उपयोग करता है।

मैंने तब MVC को बाहर करने की कोशिश की, और आउटपुट पर अधिक प्रत्यक्ष नियंत्रण रहा (और CakePHP से MVC प्रतिमान के साथ कुछ अनुभव) मैं उस सरल ऐप को ठीक उसी तरह पूरा करने में सक्षम था जिस तरह से मैं लगभग 1/2 दिन में चाहता था।

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

Comments

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

— मूटिनेटर

वह दिन का 1/4 है।

— मूटिनेटर

लेकिन अगर आवश्यकताओं को "मुझे दो भूमिकाओं के साथ एक ऐप की आवश्यकता है, तो कुछ जानकारी रिकॉर्ड करने के लिए, दूसरा इसे देखने के लिए, और मुझे वास्तव में परवाह नहीं है कि यह कैसा दिखता है।" तब, हाँ, यह काफी उल्लेखनीय है।

— मूटिनेटर

im क्षमा करें, लेकिन डेटा दर्ज करने और डेटा देखने के लिए एक वेबफ़ॉर्म ऐप विकसित करना इतना सरल है, कि यह कुछ घंटों में किया जा सकता है। MVC ऐप की संरचना बनाने से, नियंत्रकों, दृश्यों और क्रियाओं में समान समय लगेगा, लेकिन आपको एक तैयार उत्पाद नहीं मिलेगा।

— दैविक

@ आम तौर पर एक साधारण MVC ऐप के लिए मॉडल एक मॉडल बनाता है, फिर नियंत्रक और दृश्य मचान और / या पाड़ नियंत्रक / विचार उत्पन्न करता है। कुछ भी नहीं वास्तव में समय लेने वाली है।

— मूटिनेटर

Answer 7

मैं वेबफ़ॉर्म पसंद करता हूं क्योंकि मेरी पृष्ठभूमि विंडोज़ विकास है।

विकास की गति एक प्रमुख मुद्दा है, और मैं भारत में किसी को आसानी से फॉर्म के साथ रात भर ठीक करने के लिए एक समस्या पारित कर सकता हूं, साथ ही, अगर मेरे पास एक पृष्ठ पर गति का मुद्दा है, तो asp.net गति के बारे में एक बहुत अच्छी पुस्तक काम है (रिक कीसिग है यार)।

webforms पूर्व विंडोज़ लोगों के लिए है। mvc वेब लोगों के लिए है

लेकिन, आधुनिक दुनिया में, जहां रिक ने एक भयानक किताब लिखी है, जिसमें सर्वर दैनिक गति से बढ़ रहे हैं और भारत में सस्ते कोडर हैं, ठीक है, वेबफॉर्म में बढ़त है

Answer 8

यदि आपके पास विकल्प है तो मेरे 2 सेंट हमेशा नई परियोजनाओं के लिए ASP.NET MVC का उपयोग करना है। मेरी राय में, वेबफोर्म्स वेब ऐप्स, पीरियड को विकसित करने का एक अच्छा तरीका नहीं है।

मुझे लगता है कि मूल REST को दूर करना बुरा है, संपूर्ण पोस्टबैक मॉडल खराब है, जिस तरह से html / css को GUI संपादक पर निर्भरता के साथ सौंप दिया गया है, वह खराब है, सामान सेट करने के लिए जादूगरों और GUI जैसे सामानों पर जोर खराब है, URLs बुरे हैं।

Comments

क्या आप अधिक विवरण में बता सकते हैं कि आप ऐसा क्यों सोचते हैं?

— gnat

मुझे लगता है कि मूल REST को अमूर्त करना वापस आ गया है, संपूर्ण पोस्टबैक मॉडल वापस आ गया है, जिस तरह से html / css को GUI संपादक पर निर्भरता के साथ सौंप दिया गया है, वह खराब है, सामान सेट करने के लिए जादूगरों और GUI जैसे सामानों का जोर खराब है, URLs खराब हैं, वगैरह

— वगैरह

Answer 9

मैंने सभी उत्तर पढ़ लिए हैं और मुझे लगता है कि मेरा व्यक्तिगत अनुभव उपरोक्त उत्तरों में कुछ जोड़ देगा।

3-4 साल पहले, मैंने वेबफॉर्म का उपयोग करके 2-3 वेबसाइट प्रोजेक्ट विकसित किए। उस समय के आसपास, MVC आसपास नहीं था या मैंने इसके बारे में नहीं सुना था। विकास स्वाभाविक रूप से (मैं बिना किसी पूर्व वेब विकास अनुभव के विन-फॉर्म विकास से आ रहा था) मेरे लिए तेजी से, क्योंकि मुझे विवरण और वेब-नियंत्रण में HTML सीखने की आवश्यकता नहीं है, इससे बहुत मदद मिली (एक नरक बहुत, इसने जीवन को आसान बना दिया) ।

अब, उस समय के बाद, मैं हाल ही तक किसी भी वेब परियोजना पर काम नहीं कर रहा था और केवल WPF का उपयोग करके कुछ विंडोज़ अनुप्रयोग का निर्माण कर रहा था।

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

इसलिए, मैं जिन अंतरों को खोजता हूं, b / w दोनों निम्नलिखित हैं: -

• विंडोज़ के विकास से आने वाले किसी व्यक्ति के लिए, वेब फॉर्म हमेशा अनुकूल रहेंगे। एक विंडोज़ डेवलपर के लिए Asp.net सीखने की अवस्था थोड़ी खड़ी है

• किसी अन्य तकनीक में वेब विकास से आने वाले किसी व्यक्ति के लिए, एमवीसी का पक्ष लिया जाएगा क्योंकि यह उन सभी के नवीनतम की नकल करता है।

• यदि आप HTML और CSS के अच्छे ज्ञान से लैस हैं तो MVC में विकास आसान और साफ है

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

संक्षेप में, दोनों कुछ समय के लिए यहाँ रहेंगे।

Answer 10

मैंने इस थ्रेड के मौजूदा 15 उत्तरों के बीच इस विचार को आगे नहीं देखा है, लेकिन मुझे लगता है कि यह विचार करने लायक है।

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

जैसा कि अन्य जवाबों में कहा गया है, MVC फ्रेमवर्क पर विकास रूबी, पीएचपी, पायथन आदि में अपने Microsoft समकक्षों की तुलना में वेब विकास के समान है; इसलिए स्वाभाविक रूप से एमवीसी की पसंद उन क्षेत्रों में टीमों के अनुभव से प्रभावित हो सकती है, साथ ही अन्य उत्तरों में प्रस्तुत कारकों के साथ।

Comments

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

— पी। ब्रायन। मैके

Answer 11

कुछ साल पहले MVC में नहीं जाने का हमारा कारण यह Microsoft की अपरिपक्व तकनीक थी। पिछले कुछ वर्षों में हम अब अधिक परिपक्व संस्करण (4) पर हैं और एमएस ने लगता है कि वे इस पर काम कर रहे हैं। हालाँकि, हम अभी भी एमवीसी का उपयोग करते हुए प्रमुख LOB ऐप्स को विकसित करने में अनिच्छुक हैं, क्योंकि हम संस्करण 4 में जिन सुविधाओं का उपयोग करना चाहते हैं, उनके लिए विंडोज़ 2012 सर्वर (IIS8 के माध्यम से वेब सॉकेट्स) की आवश्यकता होती है। मुझे लगता है कि 1 वर्ष में हम एमवीसी को अधिक स्वीकार करेंगे क्योंकि उम्मीद है कि अधिक तीसरे पक्ष के नियंत्रण उपलब्ध होंगे, प्रौद्योगिकी व्यवस्थित हो जाएगी, और हमारे पास इसका समर्थन करने के लिए बुनियादी ढांचा होगा।

Comments

क्या आप इनमें से कुछ विशेषताओं को सूचीबद्ध करने का मन करेंगे जिनके लिए आपको Windows Server 2012 की आवश्यकता होगी?

— मिकीटेवी

Answer 12

यह निर्णय आपकी प्राथमिकताओं पर, आपके अनुरोधों पर या आपके ज्ञान और अनुभव पर भी निर्भर करता है।

प्रशिक्षण सीखने का समय एमवीसी या डिलीवरी पाने का समय। यह सब चीजें एक या दूसरे aproach को चुनने के लिए मायने रखती हैं।

क्या ऐसा नहीं है कि एक दूसरे से बेहतर है, बस aproach या चौखटे दोनों पेशेवरों और विपक्ष है।

Personaly मैं MVC 3 का पक्ष लेता हूं, मैं आपको अपना खुद का अनुभव प्राप्त करने की कोशिश करने की सलाह देता हूं, लेकिन मुझे यह कहने की आवश्यकता है कि MVC में प्रोग्राम एक स्वच्छ, मजेदार, लचीला, विस्तार योग्य, सुरक्षित और संरचित तरीका है।

सादर,

Answer 13

केवल यही कारण है कि मैं MVC के बजाय WebForms चुनूंगा क्योंकि आपके पास MVC की तुलना में WebForms के लिए बहुत अधिक तृतीय पक्ष UI नियंत्रण हैं। मैं MVC का चयन करता हूं क्योंकि मैंने WebForms के साथ बहुत अधिक काम किया है और मैं कुछ नए / नए काम करना चाहता हूं, लेकिन फिर भी MS की दुकान से :)

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

क्या यह WebForms या MVC कोड है:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

WebForms में केवल एक ही सीमा है कि यदि आप नियंत्रण के डिपेंडेंसी इंजेक्शन / व्युत्क्रम का उपयोग करते हैं, तो आपके पास कंस्ट्रक्टर इंजेक्शन नहीं हो सकता है क्योंकि WebForms पृष्ठों में पैरामीटर रहित कंस्ट्रक्टर होना चाहिए, इसलिए आपको प्रॉपर्टी इंजेक्शन का उपयोग करना होगा। क्या यह वाकई इतनी बड़ी बात है?

Answer 14

ASP.NET MVC वास्तव में रूबी का उत्तर है, और जितना संभव हो उतना नया, ट्रेंडी, और (IMO) सर्वर से ब्राउज़र (क्लाइंट) को डिकूप करने का बेहतर तरीका है।

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

ASP.NET MVC .aspx फ़ाइल और .aspx.cs फ़ाइल के तंग युग्मन को देखकर दृश्य और नियंत्रक को अलग करता है जो वेबफॉर्म में उनके साथ होता है।

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

Comments

तो क्या MVC पर वेबफॉर्म का पक्ष लिया जाना चाहिए? यह मूल पोस्टर प्रश्न का उत्तर नहीं देता है।

— स्टीवन स्ट्रिगा जूल 22'11

@WeekendWarrior - ऐसा होता है, जब आप क्लाइंट से अधिक सर्वर-साइड एक्सेस चाहते हैं, तो वेबफॉर्म चुनें। यदि आप अपने कोड में क्लाइंट / सर्वर का अधिक डिकोडिंग चाहते हैं, तो MVC चुनें। दिन के अंत में, वे दोनों एक ही काम करते हैं। Reroute फ़िल्टर MVC के url के समान ही काम करते हैं और आप इसे अलग करने के लिए एक अलग मध्य स्तरीय के पीछे webforms कोड को स्थानांतरित कर सकते हैं। weblogs.asp.net/scottgu/archive/2010/01/24/…

— रयान हेस

आपके तीसरे बिंदु के बारे में, व्यावसायिक तर्क .aspx.cs फ़ाइल में समाप्त होता है - मुझे लगता है कि यह डेवलपर्स की गलती है। यह होना / होना / होना नहीं है। Webforms में, .aspx "view" है, .aspx.cs "कंट्रोलर" समतुल्य है, जिसका अर्थ है उस कोड को संसाधित करना जो सीधे तौर पर केवल UI से संबंधित होता है, जो एक व्यवसायिक परत या मोटे अनाज वाले व्यापार मुखौटा परत का सर्वेक्षण करता है। तथ्य यह है कि लोगों ने .aspx.cs में व्यावसायिक तर्क रखा है, बस खराब प्रोग्रामिंग है। वे व्यावसायिक तर्क को MVC में देखने के अधिकार में रख सकते हैं! MVC इन चीजों को अलग करने के लिए बाध्य नहीं करता है।

— जेम्स

अनिवार्य रूप से वह अधिक सही है तो अन्य उत्तर यहां पोस्ट किए गए हैं। ASP.net Microsoft द्वारा बनाई गई एक मॉड्यूलर वेब प्रौद्योगिकी परिवार के पीछे मूल विचार है। ASP.net MVC मॉड्यूल एक अस्थायी प्रचार हो सकता है, लेकिन यह सुनिश्चित करने के लिए कि यह अंतिम नहीं है, यह सब ASP.net से शुरू होता है, इसलिए ASP.net का चयन करने के लिए, यदि आपको नहीं लगता कि MVC आपकी चीज नहीं है, तो शायद आपका कुछ और है। OWIN या ..., कुछ और अधिक उन्नत, या अपने कार्यों के लिए अपना खुद का ढांचा बनाया। आपको ASP.MVC की आवश्यकता भी नहीं हो सकती है और इसे छोड़ कर ओविन या कटाना जा सकते हैं, लेकिन अपने

— अनप्लान का

Answer 15

मेरी राय में, वे पर्याप्त रूप से संबंधित हैं और उनकी लगभग समान क्षमताएं हैं कि उन्हें वरीयता में नीचे आना चाहिए।

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

वे पूरी तरह से अलग संस्था नहीं हैं, और जब तक Microsoft दोनों का समर्थन जारी रखता है, मेरा मानना ​​है कि आप प्रत्येक के लिए असाधारण डेवलपर्स का मिश्रित समूह जारी रखेंगे।

Answer 16

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

मैंने हाल ही में एक परियोजना को पूरा करने के लिए MVC का उपयोग किया है, और जब मैं अनुप्रयोग विकास के लिए डिज़ाइन दृष्टिकोण को पसंद करता हूं (जो आपको अधिक नियंत्रण, स्वच्छ यूआरएल, एसओसी, आदि) देता है, तो वास्तव में यह प्रदान नहीं करता है, जो कि WebForms नहीं कर सकता है। वास्तव में, jQuery के उद्भव और यह WebForms (साथ ही MVC) के साथ कामकाज है, इन तर्कों को एक मुद्दे से कम कर दिया है। और जब लोग एमवीसी पर एक लाभ के रूप में चिंताओं को अलग करने के बारे में बात करते हैं, तो मैं उनसे पूछता हूं कि वे ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के बारे में कितना जानते हैं और कितना अमूर्त और बहुरूपता के सिद्धांत का उपयोग करते हैं।

मैं वर्तमान में दोनों तकनीकों का उपयोग करके सहज हूं और मैं स्थिति के आधार पर चुनता हूं और चुनता हूं। सच कहूं, तो यह आपके ऊपर है, लेकिन सच्चाई यह है कि हर कोई यह जानने के लिए अपना समय नहीं लेता है कि एक विशेष तकनीक क्या है।

Comments

वेबफोर्स की विशाल क्षमताओं पर डिट्टो। अधिकांश लोग वेबफॉर्म के प्रशिक्षण पहियों को देख रहे हैं और इसकी तुलना एमवीसी से कर रहे हैं।

— TheLegendaryCopyCoder

इस दिन और उम्र (2013 में भी) HTML और जावास्क्रिप्ट के शीर्ष पर एक अमूर्त सीखने में बहुत कम समझ है। यह आप अपने भविष्य के अवसरों के लिए अच्छा नहीं करेंगे। HTML और जावास्क्रिप्ट बस ठीक है जिस तरह से यह है। इससे लड़ना एक हारी हुई लड़ाई है।

— user441521

Answer 17

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

Answer 18

खैर, WebForms के पास अधिक सीखने के संसाधन उपलब्ध हैं (केवल इस तथ्य के कारण कि यह पुराना है) और इस प्रकार नए प्रोग्रामर जो "जानने में नहीं हैं" इस पुरानी तकनीक के बारे में जानकारी प्राप्त करने की अधिक संभावना होगी क्योंकि MVC जैसे नए सामान के विपरीत। ।

वरिष्ठ / अनुभवी प्रोग्रामर पुराने हैं और इस तथ्य के कारण पुरानी तकनीक में अधिक प्रवीण होंगे कि वे नए लोगों की तुलना में लंबे समय तक इसमें क्रमादेशित हैं।

जब तक आप अपने दोस्तों को MVC में कुशल होने के लिए पैसा और प्रयास खर्च नहीं कर सकते क्योंकि वे WebForms अनुप्रयोगों में हैं, तो आप निस्संदेह कोशिश कर रहे हैं और जब तक संभव हो नए प्लेटफॉर्म पर अपग्रेड करना बंद कर दें।

इसलिए यह कई लॉजिस्टिक समस्याएं प्रस्तुत करता है: क्या एमवीसी के लाभ कम गुणवत्ता और तैनाती के समय की लागत से आगे निकल जाते हैं? अगर मेरे पास पूरी तरह से WebForms में लिखी गई साइट है, तो क्या यह MVC को इसमें एकीकृत करने के प्रयास और पैसे के लायक होगा?

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

Answer 19

मुझे लगता है कि इन दोनों तकनीकों के बीच का अंतर उतना व्यापक नहीं है जितना पहले हुआ करता था।

• वेब प्रपत्र राउटिंग इंजन का उपयोग कर सकते हैं जो एमवीसी (या कुछ समान) का उपयोग करता है।
• स्क्रिप्ट मैनेजर स्क्रिप्ट्स को जोड़ सकता है, सीडीएन से लोड कर सकता है, और स्क्रिप्ट्स को लोड करने में भी देरी कर सकता है।

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

Comments

Webforms और MVC डिफ़ॉल्ट रूप से एक भिन्न वेब विकास दृष्टिकोण की सलाह देते हैं, यह महत्वपूर्ण है , कुछ डेवलपर्स "डिफ़ॉल्ट" से विचलित होते हैं। दोनों का उपयोग एक ही चीज को प्राप्त करने के लिए किया जा सकता है।

— रेयानोस