MVC, WCF, EF, LINQ - क्या यह सिर्फ मुझे है? [बन्द है]


17

... या चीजें अधिक जटिल हो रही हैं?

यह मुझे लगता है कि आपको इन दिनों एमएस वेब ऐप को 'ठीक से' विकसित करने के लिए बहुत सारे सामानों को जानना होगा। बुरे पुराने दिनों में जब हमें कोई बेहतर पता नहीं था तो हमारे पास डेटाबेस टेबल, ASP.NET, ADO.NET थे और आपने अपेक्षाकृत सरल अवधारणाओं का उपयोग करके एक वेब ऐप का निर्माण किया।

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


MVC = ASP.Net, WCF = वेब सेवाएँ + .नेट रीमोटिंग, EF = ADO.Net, Linq कुछ फ़ोरम लूपों का प्रतिस्थापन है। अब पहले की तरह ही कई चौखटे हैं।
vortexwolf

जॉन मुझे आपसे आंशिक रूप से सहमत होना है। मैं वर्तमान में अपने .Net कौशल को ब्रश कर रहा हूं, निश्चित रूप से 5 साल पहले की तुलना में अधिक।
टीड्रिंकिंगगीक

जबकि MS क्षेत्र में बहुत सारी DB प्रौद्योगिकियां हो सकती हैं, यह प्रश्न इस साइट पर वास्तव में ऑफ-टॉपिक है। यह वास्तव में एक सवाल नहीं पूछता है और "... बेकार है, क्या मैं सही हूं?" एफएक्यू में सूचीबद्ध शेख़ी श्रेणी
वाल्टर

जवाबों:


17

वे सभी चीजें वैकल्पिक हैं, यदि वे सहायक हैं, तो उनका उपयोग करें, यदि वे नहीं हैं। यह इतना सरल है। आप निश्चित रूप से अच्छे / उचित वेब ऐप्स w / o को अपने समाधान में शामिल कर सकते हैं।

निजी तौर पर, मैं एमवीसी को एक बहुत हल्का और फ्रेमवर्क का उपयोग करने के लिए आसान बनाता हूं (वेबफोर्म, ईमो की तुलना में शुरू करने के लिए बहुत आसान)। इसी तरह, LINQ कुछ भी क्वेरी करने का एक सामान्य तरीका प्रदान करता है; यह भी अच्छा। EF और WCF और मेरे बीच हमारी असहमति रही है, लेकिन जब ऐसा हो, तो मैं उन्हें इस्तेमाल नहीं करता।


2
+1 'यदि वे सहायक हैं तो उनका उपयोग करें'। मैं नियम का उपयोग करने की कोशिश करता हूं, हर परियोजना में 1 नई 'बात' करने की कोशिश करता हूं। थोड़ी देर के बाद आपके पास बहुत सारे सामान के साथ अनुभव होगा और चीजों को देखना आसान हो जाएगा क्योंकि आप इसे अधिक उपयोग करते हैं।
Jan_V

+1 करने के साथ-साथ 'प्रत्येक प्रोजेक्ट पर 1 नई चीज़ करने का प्रयास करें'। मुझे सीखना और साथ ही बढ़ना पसंद है।
पॉल

1
मैं हर प्रोजेक्ट पर 1 नई चीज़ करने की कोशिश करता हूँ, लेकिन आमतौर पर यह है कि नई चीज़ जो मैंने पिछले प्रोजेक्ट से सीखी थी, अब अप्रचलित है :)
gbjbaanb

9

नहीं वास्तव में नहीं। LINQ एक डेटाबेस के साथ इंटरेक्ट करते समय कटा हुआ ब्रेड के बाद सबसे बड़ी चीज़ है।

आपको जो याद रखना चाहिए वह यह है कि ये चीजें अन्य चीजों पर बनी हैं। LINQ आपको ASP.NET वेबसाइट को विकसित करने के लिए आवश्यक चीजों की संख्या में नहीं जोड़ रहा है, क्योंकि अब आपको SQL को जानने की आवश्यकता नहीं है। और LINQ OO है, जो नियमित अनुप्रयोग विकास के साथ कहीं अधिक है, जो इसे SQL की तुलना में पूरा करने में आसान है, और C # के साथ एकीकृत करने में बहुत आसान है।

यदि आपको नहीं लगता है कि LINQ SQL की तुलना में आसान है, तो शायद आपको कुछ ऐसे उदाहरणों को पोस्ट करना चाहिए जो नए प्रतिमानों में कठिन हैं।

इससे भी महत्वपूर्ण बात, पहले की वेबसाइटों में बहुत कम कार्यक्षमता थी। आप नई वेबसाइट कैसे बनाने जा रहे हैं जो बेहतर प्रदर्शन करें, बेहतर पैमाने पर हों और एक ही कोड में नए फ़ंक्शन प्रदान करें?


4
LINQ में बायां जॉइन SQL की तुलना में कठिन है। यदि आप डेटाबेस की समस्याओं का निवारण करने की कोशिश कर रहे हैं, तो भी आप SQL वैसे भी देखने के लिए तैयार होंगे। यदि आप कभी भी गैर-Microsoft विकास प्लेटफ़ॉर्म पर जाना चाहते हैं, तो SQL को जानना आपकी मदद करेगा।
btilly

10
कोई भी ORM फ्रेमवर्क SQL जितना शक्तिशाली नहीं है। ऐसे प्रश्न हैं, जिन्हें मुझे ओआरएम ढांचे में करना असंभव है।
बिट-ट्विडलर

1
@ बिट-ट्विडलर> हाँ, और इसीलिए अधिकांश ORM फ्रेमवर्क आपको कच्चे SQL (या स्प्रोक्स) को भी निष्पादित करते हैं। आपके पास एक अच्छा सी # आदमी हो सकता है जो अधिकांश पैदल यात्री प्रश्न लिखता है, और आप जैसे डीबी विशेषज्ञ उनके लिए हार्ड सामान को एक स्प्रो या दृश्य में पैकेज कर सकते हैं।
पॉल

1
जबकि मैं बड़े पैमाने पर डेटाबेस डिजाइन करता हूं और क्लाइंट-साइड और सर्वर-साइड एसक्यूएल का एक टन लिखता हूं, मैं डीबीए नहीं हूं। मैं एक सॉफ्टवेयर इंजीनियर हूँ। मैंने कभी भी कहीं भी काम नहीं किया है जहां सॉफ्टवेयर डेवलपर्स जहां यूनी-कुशल हैं। किसी भी दिन, मैं सी, सी ++, जावा, ऑब्जेक्ट पास्कल, पीएल / एसक्यूएल, या इंटेल असेंबली भाषा में कोड लिख सकता हूं (मैं एचएमटीएल, एक्सएमएल और सीएसएस को प्रोग्रामिंग भाषाओं के रूप में नहीं गिनता क्योंकि वे ट्यूरिंग पूर्ण नहीं हैं)। मैं अपने स्वयं के टूल सेट और एक टॉमकैट-आधारित परीक्षण वातावरण को बनाए रखता हूं (मेरी टीम के सभी के पास अपना टॉमकैट सर्वर है)।
बिट-ट्विडलर

1
एक डेटाबेस (LINQ-to-SQL, LINQ-to-Entities) के साथ बातचीत करने के लिए LINQ लिखना SQL को जाने बिना ...? आपदा के लिए नुस्खा।
कर्क ब्रॉडहर्स्ट

3

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

मुझे यकीन है कि कुछ क्लासिक एएसपी लोगों ने .NET के बारे में उसी तरह महसूस किया, लेकिन कुछ उस तर्क को जारी रख सकते हैं। मैं क्लासिक एएसपी में कुछ साइटों का निर्माण करता हूं और वापस नहीं जाऊंगा।


2

"थोड़ा पागल हो गया"। ठीक उसी तरह से जैसे मैं एक DataSet, ADO.NET, ASP.NET समाधान का वर्णन करता हूँ । :)

मैं मानता हूं कि सीखने के लिए और भी बहुत कुछ है, लेकिन आपके द्वारा उल्लेखित रूपरेखाओं में से प्रत्येक ने .NET विकास को बेहतर बनाया है।


0

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

मैं एक बार एक मजाकिया उद्धरण पर लड़खड़ाया - "सभी कोड s # में बदल जाता है! पर्याप्त समय और हाथ दिए गए हैं" - जो IMHO बताता है कि मौजूदा रूपरेखाओं के भीतर नया सामान नए विचारों को कार्रवाई में लाने और विकास करने के लिए क्यों उभरना चाहिए।

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