वेब फ्रेमवर्क का उपयोग करने से होने वाले फायदे और नुकसान? [बन्द है]

Question

यह सवाल वेब आधारित फ्रेमवर्क का उपयोग करने के फायदे और नुकसान को निकालने पर केंद्रित है : जैसे कि केक PHP, Zend, jQuery, ASP.NET)। यह सवाल पूरी तरह से भाषा अज्ञेय का है । मुझे "दिग्गजों के कंधों पर खड़े होने " की धारणा के साथ शुरू करते हैं ।

लाभ:

• डेवलपर्स डेवलपर्स - पहले से कोड की 100 लाइनों को लेने और एक साधारण फ़ंक्शन कॉल में उन्हें संपीड़ित करने की सुविधा लेने से डेवलपर्स को अपने वेब साइटों में अधिक जटिल सुविधाओं को एकीकृत करने का अधिकार मिलता है।
• अनुप्रयोगों के त्वरित विकास के लिए अनुमति दें - यह उन लोगों के लिए बहुत प्रासंगिक है जिन्हें बहुत छोटी विंडो में बनाई गई वेबसाइटों की आवश्यकता है (क्या इसका कोई उदाहरण है?)
• कम लागत - प्रोग्रामर को ग्राहक पर लागत बचत को पारित करने की अनुमति देता है, उत्पन्न ग्राहकों की एक पूरी नई श्रेणी जो एक वेबसाइट चाहती थी लेकिन पहले उच्च विकास लागत का वहन नहीं कर सकती थी।

नुकसान:

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

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

Answer 1

यहां नीचे पंक्ति है: एक रूपरेखा विन्यास के बाहर सुविधाओं को लागू करना मुश्किल हो सकता है।

आइए धारणा द्वारा इस धारणा के माध्यम से चलते हैं।

लॉस्ट अंडरस्टैंडिंग - एक फ्रेमवर्क की सुविधाओं पर भरोसा करने से एक डेवलपर को समझ में आने का खतरा है कि चीजें कैसे काम करती हैं (हुड के नीचे)।

असत्य। आप यह समझने में कभी नहीं चूकेंगे कि चीजें कैसे काम करती हैं। चौखटे जादुई नहीं हैं। वे सिर्फ इतना आसान कोड हैं जो आपको खुद नहीं लिखना है।

मानो या न मानो, आप ढांचे का उपयोग कर गलतियाँ करेंगे। आपने जो गलत किया, उसे समझने के लिए आपको HTTP के सबसे निचले स्तरों पर डिबग करना होगा।

आप हुड के नीचे क्या हो रहा है की दृष्टि कभी नहीं खो देंगे। जब तक, निश्चित रूप से, आपका ढांचा इतना महाकाव्य और परिपूर्ण है कि आपको कभी कोई समस्या नहीं है।

कॉन्फ़िगरेशन क्लिफ - एक बार जब आप अपने ढांचे के कॉन्फ़िगरेशन से आगे बढ़ जाते हैं तो आपकी उत्पादकता सही से बंद हो जाती है, फ्रेमवर्क कॉन्फ़िगरेशन के बाहर सुविधाओं को लागू करना मुश्किल हो सकता है।

यह कीमती थोड़ा समझ में आता है।

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

दूसरा। फ्रेमवर्क के बाहर चीजों को लागू करना हमेशा बहुत काम होता है क्योंकि - अहम - फ्रेमवर्क के बाहर कुछ भी लागू करना हमेशा बहुत काम होता है। यह सीखने में खर्च किए गए समय और रूपरेखा को कॉन्फ़िगर करने से कोई लेना-देना नहीं है। ढांचे के बाहर कुछ भी लागू करना स्वाभाविक रूप से कठिन है।

डेवलपर ट्रामलाइन - आपको (डेवलपर) चीजों को उस तरह से करना होगा जिस तरह से [फ्रेमवर्क] डेवलपर चाहता है कि आप चीजों को करें।

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

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

क्या? इसका फ्रेमवर्क से कोई लेना-देना नहीं है। धोखाधड़ी धोखाधड़ी है, भले ही इस्तेमाल किए गए उपकरणों के बावजूद।

Comments

"लॉस्ट अंडरस्टैंडिंग" के संबंध में मैं आपसे सहमत नहीं हूँ। यदि आप एक उदाहरण के रूप में jQuery लेते हैं, तो आपको स्टैक ओवरफ्लो पर दर्जनों प्रश्नों को देखने की जरूरत है, जहां यह स्पष्ट है कि जिज्ञासु jQuery, जावास्क्रिप्ट और DOM के बीच अंतर नहीं कर सकता है।

— RoToRa

@RoToRa: यदि आप SO (यानी, C प्रोग्रामिंग) पर किसी विशिष्ट विषय को देखते हैं, तो आपको बड़ी संख्या में ऐसे लोग दिखाई देंगे जो यह पता नहीं लगा सकते कि क्या चल रहा है। दरअसल, कुछ लोगों को यह भी समझ नहीं आता है कि फ्लोटिंग-पॉइंट नंबर क्या है। मुझे नहीं लगता कि यह ढांचा है। मुझे लगता है कि कुछ लोग ऐसे हैं जिनके पास तकनीक समझने की सीमित क्षमता है।

— 13:10

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

— JHarley1

@ JHarley1: "लेकिन यह विषय से मीलों दूर था"। आप इसे ठीक करने के लिए प्रश्न को अपडेट कर सकते हैं।

— एस.लॉट

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

— 14:28 पर user281377

Answer 2

Con: समर्थन की अंतिम संभावित गिरावट / लोकप्रियता का ह्रास

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

प्रो: व्यापार के लिए कोड

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

Comments

चीयर्स रयान, यहां कुछ अच्छे अंक हैं। मैंने कभी भी फ्रेमवर्क को गिराने / अनुग्रह से गिरने पर विचार नहीं किया।

— JHarley1

क्या मुझे डाउनवोट पर कुछ प्रतिक्रिया मिल सकती है, कृपया?

— रयान हेस

मुझे यह उपयोगी लगा - मैंने मतदान किया है।

— JHarley1 15

Answer 3

लाभ

• तेजी से विकास का समय
• कम कीड़े
• त्वरित साझा विकास
• पुस्तकालय का समर्थन
• आसान DB बातचीत

नुकसान

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

मैं सभी परियोजनाओं के लिए चौखटे का उपयोग करने की वकालत करता हूं लेकिन सबसे सरल। यदि आपको किसी मौजूदा HTML साइट पर हमसे संपर्क करने की आवश्यकता है, तो आप किसी फ़्रेम में जाने के बजाय एक PHP फ़ाइल का उपयोग कर सकते हैं।

Answer 4

कुछ बातें जो दिमाग में आती हैं ...

लाभ

• कोड का पुन: उपयोग - एक रूपरेखा का उपयोग करके, आप उस कोड का पुन: उपयोग कर रहे हैं जो परीक्षण और सत्य है।
• तीव्र विकास / प्रोटोटाइपिंग।
• (अक्सर) एकीकृत इनपुट सत्यापन, जिसे सुरक्षित माना जा सकता है (डेवलपर इसे सही तरीके से उपयोग कर रहा है)

नुकसान

• समर्थन का नुकसान। यहाँ आकर सिम्फनी 1.4 है। मुझे लगता है कि सिम्फनी काफी समय के लिए 1.4 का समर्थन करेगी, लेकिन यह जानकर कि 2.0 पीछे की ओर संगत नहीं है, 1.4 आने वाले वर्षों में एक समर्थन डेड-एंड की तरह लगता है।
• ओवरहेड; एक रूपरेखा का उपयोग करके, आप हजारों लाइनें चला रहे हैं जो आपके विशिष्ट अनुप्रयोग पर लागू नहीं हो सकती हैं, लेकिन दूसरों पर लागू होती हैं। कुछ इसे एक उचित व्यापार बंद करते हैं, और कुछ प्रदर्शन के लिए जमीन से अपना कोड लिखने का विकल्प चुनते हैं।
• अपनी विशिष्ट आवश्यकताओं के लिए गलत ढांचे का उपयोग करना। सभी रूपरेखा समान रूप से नहीं बनाई गई हैं।

Answer 5

यह सब आपके द्वारा उपयोग किए जाने वाले ढांचे पर निर्भर करता है।

यदि आप ASP.NET का उपयोग कर रहे हैं, तो आप नुकसान में हैं: यह सबसे अच्छा है , और सबसे बुरी तरह से यह एक ऐसा काम है जो उन चीजों को करने के लिए एक दर्द देता है जो अन्य चौखटों में तुच्छ हैं जो इस तथ्य को छिपाते नहीं हैं कि आप कर रहे हैं वेब पर काम करना।

ASP.NET MVC उस समस्या को ठीक करना चाहता है, और यह इतनी अच्छी तरह से करता है।

चौखटे मौजूद हैं ताकि हम काम करने में अधिक समय बिता सकें, और कम समय में मचान का निर्माण कर सकें। उस संबंध में, मुझे कोई नुकसान नहीं दिखता, जब तक कि आप वास्तव में मचान बनाने में समय नहीं बिताना चाहते।

Comments

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

— JHarley1

Answer 6

मैं कुछ बिंदु जोड़ना चाहूंगा।

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

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

लाभ:

• जब आप लगातार उन परियोजनाओं के लिए सीखने के समय का उपयोग करते हैं, जो पहले से ही आपकी परियोजनाओं पर काम करने वाले लोगों के लिए कम हो जाती हैं।
• आपका अपना त्वरित विकास
• अपने खुद के सशक्त डेवलपर्स

Comments

@ कीडिजक: मैं लाइसेंस के बारे में कभी नहीं हूं, क्या भुगतान किए गए ढांचे के कोई उदाहरण हैं?

— JHarley1

@ JHarley1 oakleafsd.com मुझे नहीं पता कि मैं इसे एक "वेब फ्रेमवर्क" कहूंगा, लेकिन मेरे पास मोर्टल्स .NET के पास तेजी से वेब एप्लिकेशन बनाने में आपकी मदद करने के लिए एक्सटेंशन हैं। .NET फ्रेमवर्क अब इस ढांचे को अधिकांश अप्रचलित बना रहा है, हालांकि।

— रयान हेस

@ जेरले मैंने अपने उत्तर में थोड़ा अधिक सामान्यीकरण किया हो सकता है, लेकिन मेरे दिमाग में मैं टेलीकिक वेबकंट्रोल या इटेक्स इटक्लेपडॉटइन . com/ terms- of-use/ index.php जैसी चीजों के बारे में सोच रहा था । मैंने एक ऐसी कंपनी में भी काम किया, जहाँ एक्सटीजे

— KeesDijk

Answer 7

मैं पिछले 13 वर्षों में व्यक्तिगत अनुभव से बात करता हूं। मेरी कंपनी में हमने स्ट्रट्स का उपयोग किया, एक छोटी वक्र के बाद यह बहुत अच्छा था। मेरे अगले में हमने एक ऐसी वास्तुकला का उपयोग किया जो ज्यादातर अपारदर्शी थी, कुछ हद तक जैसे कि बड़ी हो गई, हम इसे बढ़ा सकते थे लेकिन कोर कोड केवल सरस था। और इसी तरह। पिछले 3 वर्षों में एक छोटी सी कंपनी में काम कर रहे हैं (देव की संख्या <30) और यह सब हमारे अपने jsps, सर्वलेट्स और ejbs थे। 2012 में हमारे कई ग्राहकों और jsps की पुनरावृत्ति को देखते हुए, एक j2ee फ़िल्टर बनाना था, जो struts2 के 20% की नकल करता था। स्टट्स 2 का उपयोग क्यों नहीं? मेरी इच्छा है कि हमारे पास है: लेकिन यह हमारे मुख्य वास्तुकार को पारित नहीं कर सका; पर्याप्त अनुभव या समय नहीं।

इसलिए हमारे पास कुछ सामान्य जेएसपीएस थे जो हमारे मिनी फ्रेमवर्क का उपयोग करते थे। अब जब मेरे पास स्ट्रट्स 2 जाने का समय हो गया है तो मुझे लगता है कि हमने बहुत याद किया है!

हम कुछ महान एल्गोरिदम और कैश और यूआई का उपयोग करते हैं, लेकिन बहुत सारे घंटे खो दिए हैं और बहुत सारे कोड के साथ बोझ डाला है कि हमारे पास रिटायर होने के लिए 3 साल की योजना है।