क्या मेरे बगल में किसी को भी ASP.NET MVC नहीं मिलता है? [बन्द है]

Question

मैं सीटीपी के बाद से ASP.NET MVC के साथ फ़िडलिंग कर रहा हूं, और मुझे बहुत सारी चीज़ें पसंद हैं, लेकिन ऐसी चीज़ें हैं जो मुझे नहीं मिलतीं।

उदाहरण के लिए, मैंने बीटा 1 डाउनलोड किया, और मैं इसके साथ एक छोटी सी व्यक्तिगत साइट / फिर से शुरू / ब्लॉग लगा रहा हूँ। यहाँ ViewSinglePost दृश्य से एक स्निपेट है:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

घृणित! (यह भी ध्यान दें कि HTML अस्थायी प्लेसहोल्डर HTML है, मैं एक वास्तविक डिज़ाइन बनाऊँगा जब कार्यक्षमता काम कर रही होगी) ।

क्या मुझसे कुछ गलत हो रही है? क्योंकि मैंने क्लासिक एएसपी में कई अंधेरे दिन बिताए, और यह टैग सूप मुझे इसकी दृढ़ता से याद दिलाता है।

हर कोई प्रचार करता है कि आप HTML को कैसे साफ कर सकते हैं। अंदाज़ा लगाओ? सभी लोगों में से 1% आउटपुट किए गए HTML को देखते हैं। मेरे लिए, मुझे परवाह नहीं है अगर Webform मेरे HTML में मेरे इंडेंटेशन को गड़बड़ कर देता है, जब तक कि मेरे पास कोड है जिसे बनाए रखना आसान है ... यह नहीं है!

तो, मुझे परिवर्तित करें, एक डाई हार्ड वेबफॉर्म आदमी, मैं इसके लिए अपने अच्छी तरह से गठित एएसपीएक्स पृष्ठों को क्यों छोड़ दूं?

संपादित करें: "अस्थायी एचटीएमएल / सीएसएस" लाइन को बोल्ड किया गया ताकि लोग इसके बारे में सोच सकें।

Comments

आदमी है कि कुछ बदसूरत मार्कअप है!

— स्टीवन ए। लोव

आप अपने HTML के साथ CSS मार्कअप शामिल करते हैं?

— टॉड स्मिथ

आपका स्वरूपण बेकार है। यह MVC में निहित समस्या नहीं है, यह एक खराब HTML प्रोग्रामर का संकेत है। बहुत समय पर्यवेक्षक पैटर्न में बिताया, मुझे लगता है। यहां ड्रैग, ड्रॉप, क्लिक से थोड़ा अधिक आवश्यक है।

— क्रिस

एमवीसी को कभी भी बुरा न मानें, Winforms को "आसान बनाए रखना" मूर्खतापूर्ण है। जब तक आपको आउटपुट पर नियंत्रण की आवश्यकता नहीं होती, तब तक इसे बनाए रखना आसान है। इसका अर्थ है कि यह तब तक ठीक है जब तक आपके उपयोगकर्ता केवल MS-स्वीकृत वेब ब्राउज़र का उपयोग करते हैं।

— जलफ

क्या मुझसे कुछ गलत हो रही है? - हाँ। लेकिन यह आपकी गलती नहीं है। आपको कुछ अच्छा HTML लिखने की आवश्यकता है और फिर मॉडल से आउटपुट को इसमें जोड़ें। आपको रिस्पांस की आवश्यकता नहीं है। कभी भी! MVC फ्रेमवर्क के पीछे का विचार यह है कि यह .aspx की तुलना में चीजों को बहुत अधिक साफ करता है, जबकि आपका उदाहरण क्लासिक एएसपी की तरह दिखता है।

— फेंटन

Answer 1

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

वेब प्रपत्र

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

MVC

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

निर्देशिका और फ़ाइलों का लेआउट MVC में महत्वपूर्ण है। उदाहरण के लिए, ASP.NET MVC में, "बुक" ऑब्जेक्ट के लिए इंडेक्स विधि की संभावना सिर्फ एक पंक्ति होगी: "रिटर्न व्यू ()"; एमवीसी के जादू के माध्यम से, यह बुक मॉडल को "/View/Books/Index.aspx" पेज पर भेज देगा जहां आपको पुस्तकें प्रदर्शित करने के लिए कोड मिलेगा। रेल का दृष्टिकोण समान है हालांकि तर्क थोड़ा अधिक स्पष्ट और कम "जादू" है। MVC ऐप में एक दृश्य पृष्ठ आमतौर पर एक वेब फ़ॉर्म पृष्ठ की तुलना में सरल होता है क्योंकि उन्हें रूटिंग, व्यावसायिक तर्क या डेटा हैंडलिंग के बारे में अधिक चिंता करने की आवश्यकता नहीं होती है।

तुलना

एमवीसी के लाभ अपने उत्पादन के उत्पादन के लिए चिंताओं और स्वच्छ क्लीनर, अधिक HTML / CSS / AJAX / जावास्क्रिप्ट-केंद्रित मॉडल के चारों ओर घूमते हैं। यह परीक्षण क्षमता को बढ़ाता है, एक अधिक मानकीकृत डिजाइन प्रदान करता है और अधिक "वेब 2.0" प्रकार की वेब साइट के लिए दरवाजा खोलता है।

हालांकि, कुछ महत्वपूर्ण कमियां भी हैं।

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

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

तीसरा, यदि आप Linq की परवाह नहीं करते हैं (या तो क्योंकि आप डरते हैं कि Linq-to-SQL गायब होने जा रहा है या क्योंकि आपको Linq-to-Entities laughably अधिक उत्पादित और संचालित के तहत मिल गया है) तो आप भी नहीं चाहते हैं ASP.NET MVC मचान उपकरण Linq के आसपास का निर्माण कर रहे हैं (यह मेरे लिए हत्यारा था) के बाद से इस रास्ते पर चलने के लिए। यदि आप SQL में अनुभव कर रहे हैं (और खासकर यदि आप TSQL में अच्छी तरह से वाकिफ हैं और संग्रहीत कार्यविधियाँ हैं!) की तुलना में रेल का डेटा मॉडल भी काफी अनाड़ी है।

चौथा, एमवीसी के प्रस्तावक अक्सर बताते हैं कि एमवीसी विचार वेब के HTML / CSS / AJAX मॉडल की भावना के करीब हैं। उदाहरण के लिए, "HTML हेल्पर्स" - आपके vew पेज में थोड़ा कोड कॉल करता है जो सामग्री में स्वैप करता है और इसे HTML नियंत्रणों में रखता है - वेब फ़ॉर्म नियंत्रणों की तुलना में जावास्क्रिप्ट के साथ एकीकृत करना बहुत आसान है। हालाँकि, ASP.NET 4.0 आपके नियंत्रणों को नाम देने की क्षमता का परिचय देता है और इस प्रकार इस लाभ को समाप्त करता है।

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

निष्कर्ष

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

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

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

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

उन लोगों के रूप में जिन्होंने इसे एक धार्मिक लड़ाई के रूप में देखा और जिन्होंने लगातार बाढ़ को बढ़ावा दिया, मुझे समझ नहीं आता कि आप क्यों परेशान होते हैं (कई मौकों पर एक दूसरे के सेकंड के भीतर 20+ डाउन-वोट निश्चित रूप से सामान्य नहीं हैं)। यदि आप इस उत्तर को पढ़ रहे हैं और सोच रहे हैं कि क्या मेरे उत्तर के बारे में वास्तव में कुछ "गलत" है, तो दिए गए स्कोर में अन्य कुछ उत्तरों की तुलना में कहीं कम है, बाकी का आश्वासन दिया है कि यह कुछ लोगों के बारे में अधिक कहता है जो सामान्य ज्ञान की तुलना में असहमत हैं समुदाय (कुल मिलाकर, यह एक 100 से अधिक बार उत्कीर्ण किया गया है)।

तथ्य यह है कि कई डेवलपर्स MVC की परवाह नहीं करते हैं और, वास्तव में, यह अल्पसंख्यक दृष्टिकोण नहीं है (यहां तक ​​कि एमएस के भीतर भी जैसा कि ब्लॉग संकेत देते हैं)।

Comments

-1, मूल प्रश्न अच्छा है - यह कहते हुए कि आप यह नहीं समझते कि कुछ अच्छा क्यों है और अधिक जानकारी मांगना भयानक है। यह जवाब, हालांकि, बहुत अजीब है - आप मूल रूप से "मुझे या तो समझ में नहीं आता" बता रहे हैं, लेकिन इसे एक कहानी में लपेटते हैं।

— orip

मुझे यह दिलचस्प लगता है कि ASP.NET MVC की आपकी आलोचना यह है कि यह अमूर्त और ओवरहेड जोड़ता है। और इसलिए अधिक जटिल है। यह ठीक इसके विपरीत है। Webforms अमूर्तता की एक परत जोड़ता है और MVC कहीं अधिक सीधे आगे और निचले स्तर का होता है जो कि आप जो कर रहे हैं उससे आपको छिपाता नहीं है

— Trevor de Koekkoek

इसे "उत्तर" के रूप में चिह्नित क्यों किया जाता है जब पोस्टर को एमवीसी पैटर्न के बारे में कुछ भी पता नहीं था जब उसने उत्तर दिया था?

— स्कॉटकेन

स्कॉटकून - सहमत है, सुनिश्चित नहीं है कि यह क्यों स्वीकार किया गया था। लगता है कि वह सब किया था ओपी के साथ सहमत थे। -1

— जेरेड

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

— tvanfosson

Answer 2

MVC आपको अपने आउटपुट पर अधिक नियंत्रण देता है, और उस नियंत्रण के साथ खराब डिज़ाइन किए गए HTML, टैग सूप आदि लिखने का अधिक जोखिम आता है ...

लेकिन एक ही समय में, आपके पास कई नए विकल्प हैं जो आपके पास पहले नहीं थे ...

1. पृष्ठ पर और पृष्ठ के भीतर तत्वों पर अधिक नियंत्रण
2. अपने आउटपुट में कम "जंक", जैसे ViewState या तत्वों पर अत्यधिक लंबी IDs (मुझे गलत नहीं मिला, मुझे ViewState पसंद है)
3. जावास्क्रिप्ट के साथ क्लाइंट साइड प्रोग्रामिंग करने की बेहतर क्षमता (वेब ​​2.0 एप्लिकेशन किसी को भी?)
4. सिर्फ MVC नहीं, बल्कि JsonResult चालाक है ...

अब यह कहना नहीं है कि आप इनमें से कोई भी काम WebForms से नहीं कर सकते, लेकिन MVC इसे आसान बनाता है।

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

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

[अपडेट करें]

यदि यह कोई सांत्वना भी है, तो MVC Microsoft की एक नई, विकसित तकनीक है। ऐसे कई पोस्ट किए गए हैं जो WebForms न केवल बने रहेंगे, बल्कि इसके लिए विकसित किए जाते रहेंगे ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... और इसी तरह...

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

Comments

मुझे लगता है कि अंक 1 और 2 क्रूक्स हैं। एक अमूर्तता के रूप में वेबफॉर्म वास्तव में "काम" IMHO नहीं करता है क्योंकि यह एक अमूर्त नहीं है जो वास्तव में चल रहा है के शीर्ष पर अच्छी तरह से मैप करता है। मुझे लगता है कि ASP.NET MVC वेब फिटिंग की तुलना में एक बेहतर फिटिंग एब्सट्रैक्शन है जिसे MVC के साथ मेरा सीमित अनुभव दिया जाता है।

— डैनियल ऑगर

और बहुत से लोग MVC या Webforms को छुए बिना ASP.Net का उपयोग करते हैं। मैंने बहुत सारे। नेट एप्लिकेशन देखे हैं जो वेबफॉर्म मॉडल से पूरी तरह से बचते हैं और पेज के पीछे कोड में सब कुछ करते हैं। और स्पष्ट रूप से, मुझे लगता है कि यह बेहतर काम करता है।

— किबी डे 24:08

अद्यतन HBoss के लिए धन्यवाद! मैं उन पर काम करने के 7 साल बिताने के बाद MSF WebForms को देखना पसंद करूंगा।

— मार्क ब्रिटिंगम

डैनियल - आप कहते हैं कि वेबफॉर्म "काम" नहीं करता है क्योंकि यह वेब मॉडल के लिए अच्छा मैप नहीं करता है। मैं सम्मानपूर्वक असहमत हूं: http दस्तावेजों को प्राप्त करने के लिए एक मॉडल के रूप में उत्पन्न हुआ । वेबफॉर्म आर्किटेक्चर केवल दस्तावेजों के विचार का विस्तार करता है ताकि वे गतिशील हों। यह मेरे लिए काम करता है ...

— मार्क ब्रिटिंगम 14

@mdbritt। मैं आपकी राय का सम्मान करता हूं क्योंकि यह उच्च स्तर पर अमूर्तता (एक दस्तावेज को पुनः प्राप्त करना) पर सच है। हालांकि, मेरे लिए psuedo राज्य की रूपरेखा और पोस्टबैक मॉडल वह जगह है जहां यह टूटना शुरू होता है, खासकर अत्यधिक गतिशील परिदृश्यों में। यह सरल चीजों के लिए बहुत अच्छा काम करता है, लेकिन यह जल्दी से खोल देता है।

— डेनियल ऑगर

Answer 3

ASP.NET MVC में अधिकांश आपत्तियां विचारों के आसपास केंद्रित हैं, जो वास्तुकला में सबसे "वैकल्पिक" और मॉड्यूलर बिट्स में से एक हैं। NVelocity , NHaml , Spark , XSLT और अन्य व्यू इंजन को आसानी से स्वैप किया जा सकता है (और यह हर रिलीज़ के साथ आसान हो रहा है)। उनमें से कई के पास प्रेजेंटेशन लॉजिक और फॉर्मेट करने के लिए अधिक संक्षिप्त वाक्य-विन्यास है, जबकि अभी भी उत्सर्जित HTML पर पूरा नियंत्रण दे रहा है।

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

यहां तक ​​कि कोड-बेइंड्स को "गलत" किए बिना भी, आपके पास रिपीटर में ओनइटेमडॉटबाउंड जैसी चीजें हैं, जो कि "टैग सूप" की तुलना में, केवल एक अलग तरीके से सौंदर्यवादी रूप से बदसूरत है। एक फॉर्च्यूप लूप को पढ़ना आसान हो सकता है, यहां तक ​​कि उस लूप के आउटपुट में वेरिएबल एम्बेडिंग के साथ, खासकर यदि आप अन्य गैर-PP.NET तकनीकों से MVC में आते हैं। यह पता लगाने की तुलना में फॉर्च्यूप लूप को समझने में Google-फू को बहुत कम लगता है कि आपके पुनरावर्तक में एक फ़ील्ड को संशोधित करने का तरीका OnItemDataBound (और चूहे के घोंसले की जाँच करना है कि क्या यह बदलने के लिए सही तत्व है)।

ASP टैग-सूप-चालित "स्पेगेटी" के साथ सबसे बड़ी समस्या थी HTML के बीच डेटाबेस कनेक्शन जैसी चीजों को सही ढंग से दिखाना।

यह ऐसा करने के लिए हुआ <%%> केवल क्लासिक एएसपी के स्पेगेटी प्रकृति के साथ सहसंबंध है, कार्य-कारण नहीं। यदि आप HTML / CSS / जावास्क्रिप्ट के लिए अपना व्यू लॉजिक रखते हैं और प्रेजेंटेशन करने के लिए आवश्यक न्यूनतम लॉजिक है , तो बाकी वाक्य रचना है।

WebForms को दिए गए कार्यशीलता की तुलना करते समय, सभी डिज़ाइनर-जनरेट किए गए C # को शामिल करना सुनिश्चित करें, और .aspx कोड के साथ C # पीछे कोड सुनिश्चित करें कि MVC समाधान वास्तव में नहीं है, वास्तव में बहुत सरल है। ।

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

व्यक्तिगत रूप से, मैं चाहता हूं कि प्रारंभिक ट्यूटोरियल सामग्री पर अधिक ध्यान केंद्रित किया जाए, जो कि विशेष रूप से परीक्षण-संचालित, नियंत्रण के व्युत्क्रम आदि की तुलना में चीजों पर केंद्रित है, जबकि अन्य सामान वह है जो विशेषज्ञों को आपत्ति है, खाइयों में लोग अधिक होने की संभावना है "टैग सूप" पर आपत्ति जताई।

बावजूद, यह एक ऐसा मंच है जो अभी भी बीटा में है। इसके बावजूद, यह WAY अधिक तैनाती और गैर-Microsoft डेवलपर्स प्राप्त कर रहा है जो अधिकांश Microsoft-बीटा तकनीक की तुलना में इसके साथ वास्तविक सामान का निर्माण कर रहा है। इस प्रकार, यह चर्चा करता है कि ऐसा लगता है कि यह इसके आस-पास के बुनियादी ढांचे (प्रलेखन, मार्गदर्शन पैटर्न, आदि) की तुलना में आगे है। यह वास्तव में इस बिंदु पर प्रयोग करने योग्य है कि प्रभाव को बढ़ाता है।

Comments

मुझे नहीं पता था कि आप आसानी से अन्य दृश्य इंजनों में स्वैप कर सकते हैं, क्या आप उस पर अधिक जानकारी प्रदान कर सकते हैं?

— RedFilter

मेरे पास लिंक नहीं है, लेकिन फिल हैक ने अपनी साइट पर कुछ हफ़्ते पहले एक लेख किया था जिसमें दिखाया गया था कि कैसे आप उन्हें भी साथ-साथ चला सकते हैं।

— जे विंसिया

तथास्तु! मैं Findcontrol का उपयोग करने से नफरत करता हूं। मैं इससे बहुत नफरत करता हूं।

— एडम लाससेक

उत्कृष्ट, अच्छी तरह से गोल पोस्ट।

— ओवेन

Answer 4

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

आप एंबेडेड सीएसएस को शामिल किए बिना यह पूछते हुए एक और पोस्ट कर सकते हैं।

नोट: ViewData.Model अगले रिलीज में मॉडल बन जाता है।

और एक उपयोगकर्ता नियंत्रण की सहायता से यह बन जाएगा

<% Html.RenderPartial("Pager", Model.PagerData) %>

जहां PagerData को एक्शन हैंडलर में एक अनाम कंस्ट्रक्टर के माध्यम से आरंम्भ किया गया है।

संपादित करें: मैं उत्सुक हूं कि आपका WebForm कार्यान्वयन इस समस्या के लिए कैसा दिखेगा।

Comments

अच्छी पोस्ट। ओप रेंडरपार्टियल के माध्यम से पुन: उपयोग जैसी कुछ तकनीकों को याद कर रहा है जो उनके कोड को क्लीनर बना देगा। ओपी के बचाव में उसने संकेत दिया कि उसे लगा कि वह कुछ गलत कर रहा है।

— डैनियल ऑगर

Answer 5

मुझे इस बात पर यकीन नहीं है कि लोगों ने अपने कोड के बारे में क्या बात करना बंद कर दिया है।

HTML आपके काम का सबसे सार्वजनिक प्रदर्शन है, वहाँ बहुत सारे डेवलपर्स हैं जो बहुत सारी वेबसाइट बनाने के लिए नोटपैड, नोटपैड ++ और अन्य सादे पाठ संपादकों का उपयोग करते हैं।

MVC वेब प्रपत्रों से नियंत्रण वापस पाने, एक निष्क्रिय वातावरण में काम करने और सामान्य रूप से इस पैटर्न के कार्यान्वयन में लगने वाले सभी अतिरिक्त कार्यों के बिना मॉडल व्यू कंट्रोलर डिज़ाइन पैटर्न को लागू करने के बारे में है।

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

यदि आपको कोई पसंद नहीं है, तो आप निश्चित रूप से मार्कअप में सिर्फ उतना ही काम करने जा रहे हैं।

EDIT I को यह भी बताना चाहिए कि वेब फॉर्म और MVC का स्थान है, मैं किसी भी तरह से यह नहीं कह रहा था कि एक दूसरे से बेहतर था, केवल यह कि प्रत्येक MVC के पास मार्कअप पर नियंत्रण हासिल करने की ताकत है।

Comments

मैं आउटपुट मार्कअप (एक बिंदु तक) के बारे में परवाह नहीं करता, मैं बनाए रखने योग्य कोड के बारे में परवाह करता हूं। Webforms से यहां का ट्रेडऑफ IMHO के लायक नहीं है।

— फ्लाईसवाट

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

— फ्लाईसवाट

जब आप 2mb Viewstate देखते हैं, तो वास्तविक तत्वों के नामकरण के विकृत होने के कारण वेब फॉर्म पर नियंत्रण खोजने के लिए टन कंट्रोल करना होता है, इस प्रकाश का स्वागत किया जाता है। मैं हमेशा अपने कोड के बारे में गुदा रहा हूं, कोई भी इसे देख सकता है, और मेरे पास ओसीडी है और मैं अपने घर को साफ रखना चाहता हूं।

— टॉम एंडरसन

यदि आप नहीं जानते कि आप क्या कर रहे हैं, तो आपको केवल 2mb का व्यूस्टेट मिलता है।

— फ्लाईसवाट

आपको टैग सूप भी मिलता है जब आप नहीं जानते कि आप क्या कर रहे हैं और कोड को एक साथ फेंक रहे हैं ...

— ह्यूगोवरे डिस

Answer 6

मुझे लगता है कि आपको कुछ चीजें याद आ रही हैं। सबसे पहले, Response.Write के लिए कोई ज़रूरत नहीं है, आप <%= %>टैग का उपयोग कर सकते हैं । दूसरा, आप सामान्य कार्य करने के लिए अपने स्वयं के HtmlHelper एक्सटेंशन लिख सकते हैं। तीसरा, थोड़ा सा स्वरूपण बहुत मदद करता है। चौथा, यह सब संभवत: कई अलग-अलग विचारों के बीच साझा किए जाने के लिए एक उपयोगकर्ता नियंत्रण में फंस जाएगा और इस प्रकार मुख्य दृश्य में समग्र चिह्न क्लीनर है।

मैं आपको यह अनुदान दूंगा कि निशान अब भी उतना साफ-सुथरा नहीं है जितना कोई चाहेगा, लेकिन कुछ अस्थायी चरों के उपयोग से इसे काफी हद तक साफ किया जा सकता है।

अब, यह इतना बुरा नहीं है और यह भी बेहतर होगा अगर मुझे इसे एसओ के लिए प्रारूपित नहीं करना है।

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

Comments

क्या यह अभी भी सिर्फ इतना अजीब नहीं लगता है, यह देखते हुए कि मैं सिर्फ वेब में एक <asp: hyperlink> की दृश्यता निर्धारित कर सकता हूं?

— फ्लाईसवाट

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

— tvanfosson

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

— tvanfosson

मुझे NavigateUrl, और दृश्यता सेट करना होगा। यह पेज_लोड ईवेंट में 2 लाइनें होगी।

— फ्लाईसवाट

मुझे लगता है कि इस तथ्य को आप रेल में कर रहे थे। पिछली बार जब मैंने ऐसा किया था तो वह क्लासिक एएसपी था, जिसके पास नफरत करने के लिए कई अन्य कारण हैं। शायद मुझे बस अपने शुरुआती गैग रिफ्लेक्स रिवाल्शन पर <%%> टैग लगाने की जरूरत है।

— फ्लाईसवाट

Answer 7

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

रूबी के साथ रेल पर क्या बड़ी बात थी? रेल MVC है। डेवलपर्स परिवर्तित कर रहे हैं, क्योंकि मुंह के शब्द से, यह प्रोग्रामर के लिए उत्पादक होने का रास्ता बन गया है।

बहुत बड़ी बात है; MVC और jQuery के निहित एंडोर्समेंट Microsoft के लिए यह सुनिश्चित करने के लिए टिपिंग पॉइंट हैं कि प्लेटफ़ॉर्म न्यूट्रल महत्वपूर्ण है। और इसके बारे में क्या तटस्थ है, यह है कि वेब प्रपत्रों के विपरीत, Microsoft आपको वैचारिक रूप से लॉक नहीं कर सकता है। आप अपने सभी C # कोड ले सकते हैं और किसी अन्य भाषा में पूरी तरह से पुन: लागू कर सकते हैं (जैसे PHP या जावा - आप इसे नाम देते हैं) क्योंकि यह MVC अवधारणा है जो पोर्टेबल है, कोड ही नहीं। (और सोचें कि यह कितना विशाल है कि आप अपने डिज़ाइन को ले सकते हैं और इसे एक वर्कस्टेशन ऐप के रूप में लागू कर सकते हैं जिसमें थोड़ा कोड परिवर्तन हो सकता है, और कोई डिज़ाइन परिवर्तन नहीं हो। कोशिश करें कि वेब फॉर्म के साथ।)

Microsoft ने निर्णय लिया है कि वेब फॉर्म अगले VB6 नहीं होंगे।

Comments

इसके साथ जोड़ना: MVC में कई सारे व्यू-इंजन उपलब्ध हैं, जिनमें डिफ़ॉल्ट WebForms के साथ-साथ RoR के HAML (जो कोण कोष्ठक पर प्रतिबंध लगाता है, विशेषकर जब वे प्रतिशत-संकेत शामिल हैं) शामिल हैं।

— 5

यह बताते हुए दिलचस्प तरीका ... अच्छे अंक

— Hugoware

— एचएएमएल एफटीडब्ल्यू

Answer 8

कृपया रॉ कॉनरी की पोस्ट I Spose I’m Just Say It: You should Learn Learn MVC पर एक नज़र डालें

Answer 9

वेब रूपों पर ASP.NET MVC फ्रेमवर्क के दो मुख्य लाभ हैं:

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

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

यहाँ समस्या इतनी नहीं है कि ASP.NET MVC चट्टानों या बेकार है, यह है कि यह नया है और इसे सही तरीके से उपयोग करने के लिए बहुत कम समझौते हैं। ASP.NET MVC आपके ऐप में क्या हो रहा है, इस पर बहुत अधिक बारीक नियंत्रण प्रदान करता है। आप कुछ तरीकों को आसान या कठिन बना सकते हैं जो इस बात पर निर्भर करता है कि आप उनसे कैसे संपर्क करते हैं।

Answer 10

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

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

यह कहा जा रहा है, मुझे लगता है कि जब वहाँ से बाहर HTML सहायकों का एक निरंतर सेट होता है तो MVC बहुत अधिक डेवलपर के अनुकूल होगा। मुझे लगता है कि हम निकट भविष्य में वेब पर पॉप अप HTML हेल्पर वर्गों का एक टन देखना शुरू कर देंगे।

Comments

मैं आपके पेजिंग कार्यान्वयन को देखना चाहूंगा क्योंकि मुझे पता नहीं है कि मैं कैसे उस एक से निपटने जा रहा हूं :)

— dtc

यहीं से मुझे पेजिंग हेल्पर्स मिले। आप यहाँ नमूना परियोजना डाउनलोड कर सकते हैं: blogs.taiga.nl/martijn/archive/2008/08/27/…

— पापा बरगंडी

जैसा कि कुछ भी है, सीखने की अवस्था है। आपको इस बात पर सुखद आश्चर्य हो सकता है कि कुछ विशेष क्षेत्र के काम कितने बेहतर हैं। हालांकि मैं झूठ नहीं बोलूंगा - सर्वर कंट्रोल और व्यूस्टेट जैसी कुछ विलासिता निश्चित रूप से याद आती है। मैंने टाइप किया है <asp: टेक्स्टबी ... और फिर एहसास हुआ ... व्हाट्स !!

— Hugoware

यहाँ एक ईमानदार सवाल है। यदि आपको HTML "हेल्पर" वर्गों की आवश्यकता है, तो क्या आपने वास्तव में MVC मॉडल का उल्लंघन नहीं किया है? क्या आप उस सरलता और लालित्य को पीछे नहीं छोड़ रहे हैं जिसके साथ वह बेची जाती है? अगर मैं गलत हूं (और मैं हो सकता हूं!) कृपया मुझे बताएं कि क्यों।

— मार्क ब्रिटिंघम

मुझे नहीं लगता कि आपको MVC में "स्विच" करना है। मैं अभी भी परियोजना के आधार पर WebForms का उपयोग करता हूं।

— हुगोवारे

Answer 11

यह मज़ेदार है क्योंकि यही बात मैंने तब कही थी जब मैंने पहली बार वेबफॉर्म देखे थे।

Comments

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

— जेसन बंटिंग

Answer 12

मैं मानता हूँ कि मुझे अभी तक asp.net MVC नहीं मिला है। मैं इसे एक साइड प्रोजेक्ट में उपयोग करने की कोशिश कर रहा हूं जो मैं कर रहा हूं लेकिन यह बहुत धीमी गति से चल रहा है।

उन चीजों को करने में सक्षम नहीं होने के अलावा जो वेब फॉर्म में करना आसान था मैं टैग सूप को नोटिस करता हूं। यह वास्तव में उस दृष्टिकोण से एक कदम पीछे ले जाता है। मैं उम्मीद करता रहता हूं कि जैसे-जैसे मैं सीखता जाऊंगा यह बेहतर होता जाएगा।

अब तक मैंने देखा है कि MVC का उपयोग करने का शीर्ष कारण आपके HTML पर पूर्ण नियंत्रण प्राप्त करना है। मैंने यह भी पढ़ा कि asp.net MVC वेब रूपों की तुलना में अधिक पृष्ठों को तेजी से परोसने में सक्षम है और शायद इसी से संबंधित है, व्यक्तिगत पेज का आकार औसत वेब फॉर्म पेज से छोटा है।

मुझे वास्तव में परवाह नहीं है कि मेरा HTML कैसा दिखता है जब तक यह प्रमुख ब्राउज़रों में काम करता है, लेकिन मुझे परवाह है कि मेरे पृष्ठ लोड कितनी तेजी से और कितने बैंडविड्थ लेते हैं।

Answer 13

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

अन्य उत्तरों ने एमवीसी के लाभों पर समग्र रूप से चर्चा की है, इसलिए मैं सिंटैक्स पर ध्यान केंद्रित करूंगा:

Html.ActionLink और HTML उत्पन्न करने वाले अन्य तरीकों का उपयोग करने का प्रोत्साहन गलत दिशा में एक कदम है। सर्वर नियंत्रण का यह स्मैक, और, मेरे लिए, एक समस्या को हल कर रहा है जो मौजूद नहीं है। यदि हम कोड से टैग उत्पन्न करने जा रहे हैं, तो HTML का उपयोग करने में परेशान क्यों हों? हम बस DOM या कुछ अन्य मॉडल का उपयोग कर सकते हैं और नियंत्रक में अपनी सामग्री का निर्माण कर सकते हैं। ठीक है, यह बुरा लगता है, है ना? अरे हाँ, चिंताओं को अलग करना, यही कारण है कि हमारे पास एक दृष्टिकोण है।

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

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

इसके कई फायदे हैं:

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

तो, वास्तव में यह वाक्यविन्यास क्या करता है?

mvc: inner = "" - उद्धरणों में जो भी है उसका मूल्यांकन किया जाता है और टैग के आंतरिक HTML को परिणामी स्ट्रिंग के साथ बदल दिया जाता है। (हमारा नमूना पाठ प्रतिस्थापित हो जाता है)

mvc: external = "" - उद्धरणों में जो भी है उसका मूल्यांकन किया जाता है और टैग के बाहरी HTML को परिणामी स्ट्रिंग से बदल दिया जाता है। (फिर, नमूना पाठ प्रतिस्थापित हो जाता है।)

{} - इसका उपयोग विशेषताओं के अंदर आउटपुट डालने के लिए किया जाता है, <% =%> के समान

mvc: if = "" - qoutes को उकेरा जाना बूलियन अभिव्यक्ति है। अगर HTML टैग बंद हो जाता है, तो इफ के पास।

MVC: और

mcv: elseif = "" - ...

MVC: foreach

Comments

आप काफी आसानी से ठीक से लागू कर सकते हैं कि आप अपने खुद के दृश्य इंजन के रूप में वर्णन कर रहे हैं और WebForms समाधान पूरी तरह से खोदें।

— जे व्यानिया

मैं एक नोट बनाने जा रहा था कि अन्य दृश्य इंजन उपलब्ध हैं, और यह भी कि मुझे लगता है कि एक cf- शैली मार्कअप अच्छा काम करेगा, जो कि आप यहाँ दिखा रहे हैं।

— ट्रैकर 1

जानकारी के लिए धन्यवाद, पता नहीं था कि अन्य दृश्य इंजन थे।

— RedFilter

Genshi एक समान दृष्टिकोण वाला एक लोकप्रिय पायथन टेम्पोलेटिंग इंजन है, आप इसे और अधिक प्रेरणा के लिए देख सकते हैं: genshi.edgewall.org/wiki/…

— orip

लेकिन किसी को भी XSLs पसंद नहीं आया तो आप कैसे इसको अपनाने की उम्मीद करते हैं?

— बॉबीशैफ्टो

Answer 14

अब, मैं केवल यहाँ अपने लिए बोल सकता हूँ:

IMO, यदि आप एक डाई-हार्ड (कुछ भी) हैं तो रूपांतरण आपके लिए नहीं है। यदि आप WebForms से प्यार करते हैं, तो इसलिए कि आप जो चाहते हैं उसे पूरा कर सकते हैं, और यही किसी का लक्ष्य भी है।

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

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

इस सब के साथ, यह वह जगह है जहाँ ASP.NET चमकता है: - TDD। कोड परीक्षण योग्य नहीं है, नफ ने कहा।

• चिंताओ का विभाजन। यह MVC पैटर्न की रीढ़ है। मुझे पूरी जानकारी है कि आप इसे वेब प्रपत्रों में पूरा कर सकते हैं। हालांकि, मुझे लगाई गई संरचना पसंद है। डिजाइन और लॉजिक को मिलाना वेब फॉर्म में बहुत आसान था। ASP.NET MVC टीम के विभिन्न सदस्यों के लिए आवेदन के विभिन्न वर्गों पर काम करना आसान बनाता है।

• कहीं और से आ रहा है: मेरी पृष्ठभूमि केकपीएचपी और रूबी ऑन रेल्स है। तो, यह स्पष्ट है कि मेरा पक्षपात कहाँ है। यह केवल इस बारे में है कि आप किस बारे में सहज हैं।

• लर्निंग कर्व: अंतिम बिंदु पर विस्तार करने के लिए; मुझे विभिन्न तत्वों की कार्यक्षमता को बदलने के लिए "टेम्प्लेटिंग" के विचार से नफरत है। मैं इस तथ्य को पसंद नहीं करता था कि फ़ाइल के पीछे कोड में बहुत सारे डिज़ाइन को पूरा किया गया था। यह सीखने के लिए एक और बात थी, जब मैं HTML और CSS से पहले से ही परिचित था। यदि मैं पृष्ठ पर "तत्व" में कुछ करना चाहता हूं, तो मैं "div" या "स्पैन" में चिपका देता हूं, उस पर एक आईडी को थप्पड़ मारता हूं और मैं चला जाता हूं। वेब फॉर्म में मुझे यह करने के लिए शोध करना होगा कि यह कैसे करना है।

• वेब की वर्तमान स्थिति "डिज़ाइन": जावास्क्रिप्ट जैसे jQuery के पुस्तकालय अधिक आम हो रहे हैं। जिस तरह से वेब फॉर्म आपकी आईडी को मैनेज करता है, ठीक उसी तरह क्रियान्वयन (विजुअल स्टूडियो के बाहर) अधिक कठिन हो जाता है।

• अधिक पृथक्करण (डिज़ाइन): क्योंकि बहुत सारे डिज़ाइन आपके नियंत्रण में हैं, इसलिए वेब डिज़ाइनर प्रोजेक्ट पर काम करने के लिए बाहरी डिज़ाइनर (वेब ​​फॉर्म के बिना) के ज्ञान के लिए बहुत मुश्किल होगा। वेब फॉर्म सभी के अंत और सभी होने के लिए बनाया गया था।

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

यदि आप वेब फॉर्म में तारकीय कार्य कर रहे हैं, तो आप कुशल हैं और यह आपके लिए काम करता है, बस यहीं आपको रहना चाहिए।

मूल रूप से, दोनों पर एक त्वरित समीक्षा करें (पेशेवरों और विपक्ष की सूची के साथ एक निष्पक्ष स्रोत [शुभकामनाएँ] खोजने की कोशिश करें), मूल्यांकन करें कि कौन आपके लक्ष्यों को फिट करता है और उसी के आधार पर चुनता है।

निचला रेखा, अपने लक्ष्यों को पूरा करने के लिए कम से कम प्रतिरोध और सबसे अधिक लाभ का रास्ता चुनें। वेब फॉर्म एक बहुत ही परिपक्व ढांचा है और यह भविष्य में बेहतर होगा। ASP.NET MVC केवल एक अन्य विकल्प है (रूबी ऑन रेल्स एंड केकपीपीपी डेवलपर्स जैसे कि खुद में खींचने के लिए: पी)

Answer 15

जावा ईई के जेएसपी इस तरह दिखे जब वे पहली बार प्रस्तावित थे - बदसूरत स्क्रिप्ट कोड।

तब उन्होंने उन्हें अधिक HTML टैग-ईश बनाने के लिए टैग लाइब्रेरी की पेशकश की। समस्या यह थी कि कोई भी टैग लाइब्रेरी लिख सकता था। कुछ परिणाम विनाशकारी थे, क्योंकि लोगों ने एचटीएमएल उत्पन्न करने वाले टैग पुस्तकालयों में बहुत सारे तर्क (और यहां तक ​​कि शैली) को एम्बेड किया था।

मुझे लगता है कि JSP स्टैंडर्ड टैग लाइब्रेरी (JSTL) सबसे अच्छा समाधान है। यह "मानक", HTML टैग-ईश है, और लोगों को पृष्ठों में तर्क रखने से रोकने में मदद करता है।

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

यदि .NET के पास JSTL के समान एक रास्ता है, तो मैं सलाह दूंगा कि वे इसे देखें।

Comments

+1 - अधिक अगर मैं दे सकता था। हाँ ... जावा बहुत पहले से इस सड़क पर है। अजीब बात यह है कि जावा ने कुछ एमवीसी शैली के ढांचे भी देखे हैं जो जेएसएफ और टेपेस्ट्री जैसे घटकों पर भी बोल्ट लगाते हैं। MVC एक वेब एप्लिकेशन IMHO के लिए एकमात्र समझदार वास्तुकला है। मैं ढांचे के साथ गोमांस नहीं होने दूंगा ताकि आप इसकी गहरी समझ प्राप्त कर सकें। ढांचा विकसित होगा।

— cwash

Answer 16

मैंने सोचा कि मैं साझा करता हूं कि यह नमूना चमकदार नए रेजर व्यू इंजन के साथ कैसा दिखता है जो एएसपी .NET एमवीसी 3 के बाद से डिफ़ॉल्ट है।

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

उस के साथ कोई समस्या?
इसके अलावा, आपको वास्तव में अपनी सीएसएस शैलियों को इनलाइन नहीं करना चाहिए, क्या आपको करना चाहिए? और आप सिर्फ दो के बजाय तीन स्थानों पर अशक्तता की जांच क्यों करते हैं? एक अतिरिक्त divशायद ही कभी दर्द होता है। इस तरह से मैं यह करूँगा:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Answer 17

मैं ASP.NET MVC परियोजना से सीधे बात नहीं कर सकता, लेकिन आम तौर पर बोलने वाले MVC फ्रेमवर्क वेब अनुप्रयोग विकास पर हावी होते आए हैं

1. वे डेटाबेस संचालन, "बिजनेस लॉजिक" और प्रस्तुति के बीच एक औपचारिक अलगाव प्रदान करते हैं

2. वे डेवलपर्स को अपने ब्राउज़र / HTML / CSS / Javascript को कई ब्राउज़रों में काम करने और उन ब्राउज़रों के भविष्य के संस्करणों में काम करने की अनुमति देने के लिए दृश्य में पर्याप्त लचीलापन प्रदान करते हैं।

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

यही देखने की शक्ति है। आपको अपने एप्लिकेशन के HTML पर पूर्ण नियंत्रण मिलता है। नकारात्मक पक्ष यह है कि आपको अपने विचारों को तर्क को न्यूनतम रखने के लिए पर्याप्त अनुशासित होने की आवश्यकता है, और टेम्पलेट कोड को यथासंभव सरल रखें।

तो, यह व्यापार बंद है। यदि Webforms आपके लिए काम कर रहे हैं और MVC नहीं है, तो Webforms का उपयोग करते रहें

Comments

"आप अपने विक्रेता पर भरोसा कर रहे हैं अपने HTML / CSS / Javascript को आपके लिए लिखने के लिए" यह बकवास है। क्या हर कोई प्रीबिल्ट कंट्रोल का इस्तेमाल करता है? हमारे पास कभी नहीं है।

— फ्लाईसवाट

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

— फ्लाईसवाट

जैसा मैंने कहा कि जॉन, अगर वेबफॉर्म आपके लिए काम कर रहा है और आपकी दुकान के पास अपना नियंत्रण विकसित करने का समय है, तो इसे करते रहें।

— एलन स्टॉर्म

@FlySwat - क्या आपने ड्रॉपडाउनलिस्ट या डेटाग्रिड का इस्तेमाल किया है?

— सिमोन_विवर

Answer 18

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

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

मैं शायद इसे बिल्कुल ऐसा नहीं करूंगा लेकिन यहाँ आपका उदाहरण है:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

यह मेरे कोड सूप में बहुत सुपाच्य, परीक्षण योग्य और स्वादिष्ट है।

Takeaway यह है कि स्वच्छ कोड वास्तव में संभव है, लेकिन यह उस तरह से एक बड़ा गधा बदलाव है जिस तरह से हम चीजें कर रहे थे। मुझे नहीं लगता कि हर कोई इसे अभी तक ग्रॉस करता है। मुझे पता है कि मैं अभी भी इसका पता लगा रहा हूं ...

Answer 19

स्टीव सैंडर्सन की हाल ही में प्रकाशित पुस्तक 'प्रो ASP.NET MVC' [1] [2] से एप्र्रेस ने एक और विकल्प सुझाया - एक कस्टम HtmlHelper एक्सटेंशन बनाना। उसका नमूना (पृष्ठ ११० पर अध्याय ४ से) एक पृष्ठांकित सूची के उदाहरण का उपयोग करता है, लेकिन यह आपकी स्थिति के लिए आसानी से अनुकूलित किया जा सकता है।

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

आप इसे कुछ इस तरह कोड के साथ अपने विचार में कहेंगे:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[२] http://books.google.com/books?id=Xb3a1xTSfZgC

Comments

वाह, कोड में भयानक मार्कअप ... ब्लेक।

— फ्लाईसवाट

यदि कोई 'PostNavigator' मार्कअप के साथ एक पुन: प्रयोज्य विजेट (या WebControl होगा) तो वह नहीं बदलता है, और जो CSS नियमों द्वारा स्टाइल किया जाता है - यह इतना भयानक समाधान कैसे है?

@GuyIncognito: सहमत, यह एक WebControl और एक स्वच्छ समाधान के अनुरूप लगता है। कुछ बिंदु पर, आपको HTML स्ट्रिंग्स का एक गुच्छा उत्पन्न करना होगा। इस तरह एक विस्तार विधि एक अच्छा समाधान है।

— 1

Answer 20

मैं फिल हैक की एक पोस्ट देखने की उम्मीद कर रहा था, लेकिन यह यहाँ नहीं था इसलिए मैंने इसे बस काट दिया और इसे http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should से चिपका दिया -Learn-mvc / टिप्पणी अनुभाग में

हेकड - 23 अप्रैल, 2009 - रोब, आप एक दंगा कर रहे हैं! :) मुझे यह अजीब लगता है जब लोग MVC में स्पेगेटी कोड लिखते हैं और फिर कहते हैं "देखो! स्पेगेटी!" अरे, मैं वेब फॉर्म में स्पेगेटी कोड भी लिख सकता हूं! मैं इसे रेल, PHP, जावा, जावास्क्रिप्ट में लिख सकता हूं, लेकिन लिस्प नहीं। लेकिन केवल इसलिए कि मैं अभी तक लिस्प में कुछ भी नहीं लिख सकता हूं। और जब मैं स्पेगेटी कोड लिखता हूं, तो मैं अपनी प्लेट को शानदार तरीके से मैकरोनी को देखने की उम्मीद नहीं करता हूं। बिंदु लोग अक्सर इसे क्लासिक एएसपी से तुलना करते हैं, यह है कि क्लासिक एएसपी के साथ लोगों को चिंता का सामना करना पड़ता है। पेजों में लॉजिक होगा जिसमें यूजर इनपुट हैंडलिंग के साथ मॉडल कोड और बिजनेस लॉजिक सभी एक में मिलाए जाएंगे। स्पेगेटी के बारे में यही था! एक बड़ी गड़बड़ी में सभी की चिंताओं को मिलाना। ASP.NET MVC के साथ, यदि आप पैटर्न का पालन करते हैं, तो आपको ऐसा करने की संभावना कम है। हाँ, आपके पास अभी भी आपके विचार में थोड़ा सा कोड हो सकता है, लेकिन उम्मीद है कि सभी दृश्य कोड हैं। पैटर्न आपको अपने उपयोगकर्ता इंटरैक्शन कोड को वहां नहीं लगाने के लिए प्रोत्साहित करता है। इसे कंट्रोलर में रखें। अपना मॉडल कोड एक मॉडल वर्ग में रखें। वहाँ। स्पेगेटी नहीं। अब ओ-टोरो सुशी है। :)

Answer 21

मैं भी; मैं अपना समय ASP.NET MVC के बजाय सिल्वरलाइट पर बिताऊंगा। मैंने MVC 1.0 की कोशिश की है और कुछ दिन पहले नवीनतम 2.0 बीटा 1 रिलीज पर एक नज़र डाली है।

मुझे लगता है कि ASP.NET MVC वेबफॉर्म से बेहतर कैसे हो सकता है। MVC के विक्रय बिंदु हैं:

1. अध्याय परीक्षा)
   
2. अलग डिजाइन (देखें) और तर्क (नियंत्रक + मॉडल)
   
3. कोई भी विचारधारा और बेहतर तत्व आईडी प्रबंधन नहीं
   
4. प्रतिष्ठित URL और बहुत कुछ ...

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

Viewstate: ASP.NET 4.0 पर क्लाइंट आईडी प्रबंधन आ रहा है। मैं केवल यूनिट परीक्षणों के बारे में चिंतित हूं, लेकिन यूनिट परीक्षण मुझे ASP.NET MVC को वेबफॉर्म से चालू करने के लिए पर्याप्त कारण नहीं हैं।

शायद मैं कह सकता हूं: ASP.NET MVC खराब नहीं है, लेकिन वेबफॉर्म पहले से ही पर्याप्त है।

Answer 22

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

ASP.Net MVC का सबसे बड़ा विक्रय बिंदु - StackOverflow MVC स्टैक पर चलता है।

यह कहा जा रहा है ... मैं आमतौर पर दृश्य पृष्ठ के साथ क्या करता हूं, उससे आपका कोड बहुत अधिक सुंदर है। इसके अलावा, मैं जिन लोगों के साथ काम करता हूं उनमें से एक HTML सहायक को एक टैग लाइब्रेरी में लपेटने पर काम कर रहा है। इसके बजाय <% = Html.RandomFunctionHere ()%> यह काम करता है

<hh: randomfunction />

मुझे उम्मीद है कि एमवीसी टीम कुछ बिंदु पर इसके आसपास हो जाएगी क्योंकि मुझे यकीन है कि वे इसका बेहतर काम करेंगे।

Comments

"... मैं जिन लोगों के साथ काम करता हूं उनमें से एक HTML सहायक को एक टैग लाइब्रेरी में लपेटने पर काम कर रहा है। इसके बजाय <% = Html.RandomFunctionHere ()%> यह <hh: randomfunction />" की तरह काम करता है। "रैंडम फंक्शनहेयर ()" विधि के लिए कॉल बस एक विधि कॉल है। यह मार्कअप नहीं है, और उस तथ्य को किसी चीज़ में अमूर्त करना जो एक टैग की तरह दिखता है मुझे लगता है कि यह बिंदु गायब है। यदि मैं उस कोड को देखने वाला एक डेवलपर हूं, तो मैं इसे कुछ कस्टम टैग की तुलना में एक विधि के रूप में देखूंगा ...

— जेसन बंटिंग

Answer 23

आपके द्वारा दिखाए जाने वाले सभी डेटा के लिए सभी तर्क को लपेटने के लिए एक मुखौटा पैटर्न का उपयोग करें और फिर इसे अपने दृश्य में अपने जेनेरिक के रूप में उपयोग करें और फिर .... कोई और अधिक स्पेगेटी कोड नहीं। http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

अगर आपको और मदद चाहिए तो [e-mail]

Answer 24

ASP.NET MVC का कार्यान्वयन भयानक है। उत्पाद सादा बेकार है। मैंने इसके कई डेमो देखे हैं और मुझे MSFT पर शर्म आ रही है ... मुझे यकीन है कि जिन लोगों ने इसे लिखा है वे मुझसे ज्यादा स्मार्ट हैं, लेकिन यह लगभग वैसा ही है जैसा कि उन्हें नहीं पता कि मॉडल-व्यू-कंट्रोलर क्या है ।

केवल वही लोग जानते हैं जो एमवीसी को लागू करने की कोशिश कर रहे हैं, वे लोग हैं जो एमएसएफटी की नई चीजों को आजमाना चाहते हैं। डेमो में मैंने देखा है, प्रस्तोता ने एक माफी मांगी थी ...

मैं MSFT का बहुत बड़ा प्रशंसक हूं, लेकिन मेरा कहना है कि मुझे एमवीसी के उनके कार्यान्वयन से परेशान होने का कोई कारण नहीं दिखता है। या तो वेब फ़ॉर्म का उपयोग करें या वेब विकास के लिए jquery का उपयोग करें, इस घृणा का चयन न करें।

संपादित करें:

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

Comments

साइट पर निर्भर करते हुए, एमवीसी एक बहुत शक्तिशाली उपकरण है जो बिना किसी अतिरिक्त लेगवर्क के बॉक्स से बाहर है। मेरे लिए, मैं अपने मार्कअप के नियंत्रण BACK को प्राप्त करने के लिए उपयोग कर रहा हूं, वेब फॉर्म के मार्कअप के लिए वेब फ़ॉर्म जो घृणा कर सकता है, वह है ... पागल।

— टॉम एंडरसन

मैं यह कहना चाहता हूं कि MVC वास्तव में काफी अच्छा है क्योंकि यह ASP.NET के सांचे में फिट हो रहा है, जो WebForms के पक्ष में है ...

— Hugoware

@tom - अगर आपको किसी चीज़ के बारे में सकारात्मक टिप्पणी पेश करनी है ... साइट के आधार पर ... आप पहले से ही पतली बर्फ पर खड़े हैं। मैं सहमत हूँ कि यदि आवश्यकता ASP.NET MVC का उपयोग करके किसी साइट को विकसित करने की है, तो यह एक अच्छा विकल्प हो सकता है, लेकिन किसी भी चीज़ के लिए, यह एक बुरी पसंद की तरह दिखता है।

— mson

मुझे पसंद है, और पसंद करते हैं, चॉकलेट से वनीला। कोई भी इसके बारे में मुझसे बहस करना चाहता है?

— जेसन बंटिंग

@ जेसन चर्चोल है। उत्पाद सिर्फ सादा SUCKS .... मुझे नीचा दिखा रहा है?