Aspnetcore: एमवीसी प्रयोग करने योग्य होने के लिए बहुत जटिल है?

यदि आप EntityFramework जैसे ORM (ऑब्जेक्ट रिलेशन मैपर) के प्रशंसक नहीं हैं, तो आप ADO.NET का उपयोग करके हाथ से SQL लिख सकते हैं। आप हल्के वजन वाले ओआरएम जैसे डैपर का भी उपयोग कर सकते हैं जो प्रश्न उत्पन्न नहीं करता है (आप उन्हें हाथ से लिख सकते हैं)। EntityFramework में आवश्यक होने पर आपको अधिक नियंत्रण देने के लिए एक ExecuteSQL विधि भी है (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql)।

साथ ही, यदि एमवीसी साधारण पृष्ठों के लिए बहुत जटिल दिखता है, तो रेजर पेजों को आजमाएं

मैं अत्यधिक सुझाव देता हूं कि आप कई एमवीसी ट्यूटोरियल्स में से एक का पालन करें; नए प्रोजेक्ट टेम्प्लेट को देखकर सिर्फ 5 मिनट से जादू की तरह कुछ समझने की उम्मीद नहीं की जा सकती है।

वेबफॉर्म के सापेक्ष सादगी के लिए, क्या मैं आपको व्यूस्टेट के दुर्भाग्य की याद दिला सकता हूं, रनैट = सर्वर और भगवान हम सभी को पृष्ठ जीवनचक्र से बचाते हैं।
सधन्यवाद

यह मजाकिया है।

मेरे लिए बहुत सीधा लगता है।

साथ ही, यदि एमवीसी साधारण पृष्ठों के लिए बहुत जटिल दिखता है, तो रेजर पेजों को आजमाएं

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

मुझे फूला हुआ ईएफ से नफरत है - डैपर इतना आसान है, खासकर अगर डैपर जैसे कुछ के साथ प्रयोग किया जाता है । FastCRUD

यह सिर्फ आप ही नहीं @ LJ9999 , MVC और किसी भी ढांचे में सभी उत्तर नहीं हैं। हो सकता है कि यह आपकी परियोजना के अनुकूल सबसे अच्छी संरचना न हो, और हो सकता है कि यह आपके विचार के अनुरूप न हो। जब तक आपको आत्म-दंड पसंद नहीं है, तब तक चौकोर खूंटे को गोल छेद में फिट करने की कोशिश करने की आवश्यकता नहीं है।

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

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

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

+1 करने के लिए डैपर, इसका इस्तेमाल करें।

आप इकाई ढांचे का उपयोग क्यों करते हैं, यह आपके वांछित व्यवहार को उसी भाषा में व्यक्त करने का एक त्वरित और आसान तरीका है जिसमें आप कोड जेन सुपरपोर्ट के साथ अपना कोड परिभाषित करते हैं (पढ़ें: बाजार में कम समय)। हालांकि मैं आम तौर पर इसका उपयोग नहीं करता, और आपके पास भी नहीं है।

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

किसी ऐसे व्यक्ति के रूप में जो Asp.Net, और MVC के प्रत्येक पुनरावृत्ति के माध्यम से हमारे पास अब Asp.Net Core के माध्यम से चला गया है, मैं आपको बता सकता हूं कि डिबगिंग पृष्ठ जीवन चक्र बग और वेबफॉर्म के साथ किसी भी सापेक्ष जटिलता के कुछ भी बनाने की कोशिश करना एक दुःस्वप्न की तुलना में था एमवीसी को। वेबफॉर्म जादुई घटनाओं की तरह लगने वाले पीछे चल रहे बहुत से वास्तविक कार्यों को छुपाते हैं। यह आपका हाथ पकड़ने की कोशिश करके वेब अनुरोधों के काम करने के पूरे तरीके को सारगर्भित करता है और यह दिखावा करता है कि वेब स्टेटलेस नहीं है। यह आपसे झूठ बोलता है और आपको बताता है कि आप सुंदर हैं और उन जींस में आपका बट अच्छा दिखता है। यह आपके आत्मविश्वास को झूठा बनाता है और वेब तकनीकों को अस्पष्ट बनाता है। और आप आनंदपूर्वक अपने दिन के बारे में सोचते हैं कि यदि आप एक फॉर्म के साथ एक वेब पेज बना सकते हैं और इसे एक टेबल पर सहेज सकते हैं तो आप कुछ भी कर सकते हैं। जब तक आपको कस्टम डायनामिक फ़ॉर्म बनाने के लिए वह नई आवश्यकता नहीं मिल जाती। या इस विशेष क्लाइंट साइड फ्रेमवर्क के साथ कुछ काम करें, क्योंकि क्लाइंट को लगता है कि यह सुंदर है। आप महसूस करते हैं कि अब आप ज्वार के खिलाफ काम कर रहे हैं और आश्चर्य करते हैं कि बाकी सभी इसे कैसे कर रहे हैं।
एमवीसी रॉकेट साइंस नहीं है, यह एक सिद्ध पैटर्न है जो विकास समुदाय में "एक बेहतर तरीका होना चाहिए" और स्क्वायर होल में गोल खूंटे चिपकाने के वर्षों के बाद विकसित हुआ है। यदि आपको लगता है कि यह जटिल है, तो शायद यह इसलिए है क्योंकि आपने ऐसी किसी भी समस्या का सामना नहीं किया है जिसे ठीक करना चाहिए और आपने जटिल समस्याओं को हल करने में पर्याप्त समय नहीं लगाया है। सरल ट्यूटोरियल के साथ शुरू करें यदि यह भारी है।
यदि आप तय करते हैं कि यह आपके लिए नहीं है तो हमेशा PHP या NodeJs होते हैं।

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

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

मैं एमवीसी को ऐसे उदाहरणों के साथ सीखने की सलाह देता हूं जो इकाई ढांचे का उपयोग नहीं करते हैं ताकि आप एक ही बार में एक अवधारणा सीख सकें। हालाँकि, इसके बारे में बात करने के लिए यह वास्तव में सही जगह नहीं है।

ओएमजी मैं अभी बहुत जोर से हंस रहा हूं।

देखो दोस्त, अगर यह बहुत कठिन या जटिल लगता है तो इससे दूर हटो और कुछ और इस्तेमाल करो। कोई आपके सिर पर बंदूक नहीं रखता है, है ना?

हम में से कुछ लोग कई बार ब्लॉक के आसपास रहे हैं और वेब फॉर्मों पर एएसपी एमवीसी की सादगी पसंद करते हैं क्योंकि हमें मोनोलिथिक वेब फॉर्म मठों से निकलने वाले अवांछित स्पेगेटी कोड के भयानक ढेर से निपटना पड़ा है।

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

क्या यह व्यंग्य पोस्ट है? सुनिश्चित नहीं है कि रेडिट या जीथब पर ...

मैंने दो अलग-अलग प्रणालियों के लिए एएसपीनेट वेब फॉर्म और एएसपीनेट एमवीसी के तहत ईआरपी विकास पर काम किया है, मैं विश्वास के साथ कह सकता हूं कि वेब फॉर्म पर काम करना एक यातना है, खासकर जब आपके पास खराब वास्तुकला के साथ एक बड़ा समाधान है, और इसके विपरीत एमवीसी जादुई रूप से एक बदसूरत दिखने वाली वास्तुकला को परतों को व्यवस्थित करने की क्षमता के साथ शीर्ष स्तर के समाधान में बदल सकता है और मजबूत विश्वसनीय ओआरएम जैसे ईएफ के साथ रिपोजिटरी पैटर्न का उपयोग कर सकता है।
लेकिन ईमानदारी से मैं जिन डेवलपर्स से मिला हूं उनमें से अधिकांश एमवीसी के बारे में शिकायत करते हैं, सीमित अनुभव और नए पैटर्न के ज्ञान से पीड़ित हैं।
मैं व्यक्तिगत रूप से उन डेवलपर्स को सलाह देता हूं जो एमवीसी को शून्य से नायक तक सीखना चाहते हैं, वेब का दौरा करने और एमवीसी पर विवादास्पद विषयों और ब्लॉगों पर समय और पैसा बर्बाद करने के बजाय https://www.pluralsight.com को आजमाएं, जो कई मामलों में पक्षपातपूर्ण या खराब है। के सन्दर्भ में।

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

मैं लेखक से सहमत हूं। उन लोगों के लिए जो पहली बार एमवीसी का उपयोग कर रहे हैं। दृष्टिकोण उतना अनुकूल नहीं है जितना कि PHP, रेल .. इसका उपयोग करने से पहले समझने के लिए बहुत अधिक अवधारणा। हालांकि, एक बार जब आप अवधारणा प्राप्त कर लेते हैं, तो एमवीसी बहुत प्रभावी प्रतीत होता है।

कोई इकाई ढांचे से नफरत क्यों करेगा। मुझे पिछले तीन वर्षों में 5 से अधिक SQL क्वेरी नहीं लिखनी पड़ी हैं।

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

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

कुछ नमूने:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/0313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

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

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

एमवीसी को ईएफ के उपयोग की आवश्यकता नहीं है, हालांकि अंतर्निहित उपयोगकर्ता प्रमाणीकरण इसका उपयोग करता है।

दोस्तों, मदद या सकारात्मकता के साथ टिप्पणी करें, लेकिन उपहास के साथ नहीं। ऐसा लगता है कि ओपी को ईएफ के साथ चिंता हो रही है, और डेविड की टिप्पणी उत्कृष्ट है। https://github.com/aspnet/AspNetCore/issues/7039#issuecomment -457869924

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

अरे स्वागत है @LJ9999 काश और लोग इस तरह के सवाल पूछते।
मैं यह कहकर शुरू करूंगा कि यह केवल मेरी राय है, इसलिए कृपया बेझिझक सहमत हों या किसी भी या सभी से असहमत हों।

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

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

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

मुझे उम्मीद है कि यह प्रतिक्रिया किसी तरह से मदद करती है। बस यह जान लें कि ऐसे कई व्यक्ति हैं जो मदद करने को तैयार हैं, हालांकि किसी के लिए आपकी मदद करना आसान बनाना आपकी जिम्मेदारी है।

@ LJ9999 एक (उम्मीद है कि रचनात्मक) टिप्पणी ...

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

मेरा निचला रेखा मानदंड सरल है... लागू करने के लिए कोड की पंक्तियों की संख्या। अधिक कोड - अधिक बग जोखिम, अधिक सीखने की अवस्था, अधिक बर्बाद घंटे (जब तक कि आप घंटे के हिसाब से ठेकेदार बिलिंग नहीं करते)।
मैंने जावास्क्रिप्ट ढांचे के साथ एमवीसी करने से 8x अधिक कोड वॉल्यूम देखा है .. पुराने स्कूल सीएसटीएमएल पृष्ठों पर। और 5x अधिक समय।

"सही रास्ता" वाक्यांश का उपयोग करने वालों से सावधान रहें

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

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

@shanselman

दोस्तों, मदद या सकारात्मकता के साथ टिप्पणी करें, लेकिन उपहास के साथ नहीं। ऐसा लगता है कि ओपी को ईएफ के साथ चिंता हो रही है, और डेविड की टिप्पणी उत्कृष्ट है। #7039 (टिप्पणी)

मैं स्कॉट से पूरी तरह सहमत हूं।

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

यह वास्तविक समस्या से मेल खाने के लिए शीर्षक बदलने में मदद कर सकता है।

हम समय-समय पर 'चर्चा' के मुद्दों को बंद कर देते हैं जिन्हें लंबे समय से अपडेट नहीं किया गया है।

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