मैं वेब एप्लिकेशन के साथ सबसे अधिक काम करता हूं और भले ही मैं सामान्य होने की कोशिश कर रहा हूं, लेकिन मेरा जवाब आपके प्रोग्रामिंग के क्षेत्र पर लागू नहीं हो सकता है।
मैं "लाइब्रेरी" के समानार्थी शब्द "फ्रेमवर्क" का उपयोग करने जा रहा हूं।
एक रूपरेखा को लागू करने से पहले, कुछ चीजों पर विचार करना चाहिए, यहां कुछ सामान्य उदाहरण हैं।
# 1। क्या रूपरेखा समय और प्रयास को बचाएगी?
इस सवाल का जवाब लगभग हमेशा हाँ है । विशिष्ट समस्याओं को हल करने के लिए फ्रेमवर्क का निर्माण किया जाता है , और उन्हें बहुत अच्छी तरह से हल किया जाता है। उदाहरण के लिए, EntityFramework जैसे ढांचे आपको SQL-कोड लिखने से पूरी तरह से बचा सकते हैं । यदि आपकी प्रोग्रामिंग टीम SQL में धाराप्रवाह नहीं है तो यह शानदार हो सकता है।
फ्रेमवर्क या तो बनाए गए हैं, ए) प्रोग्रामर के अनुकूल इंटरफेस को जोड़ने के लिए अन्यथा जटिल घटकों या बी) पहले से ही ज्ञात (या स्थापित) घटकों में अमूर्तता जोड़ते हैं।
बाद वाले (या कुछ मामलों में पूर्व भी) वास्तव में विकास के रास्ते में आ सकते हैं । यह विशेष रूप से तब लागू होता है जब आप या आपकी प्रोग्रामिंग टीम एक नया ढांचा लागू करने जा रही है, जिसमें उन्होंने पहले कभी काम नहीं किया है।
यह संभावित रूप से आपकी विकास प्रक्रिया को धीमा कर सकता है, जो संभावित रूप से महंगा हो सकता है।
# 2 आपके आवेदन का पैमाना
ऐसा कहा जाता है कि "कुछ भी करने लायक कुछ अति करने योग्य है" , लेकिन आमतौर पर ऐसा नहीं होता है। यदि आपके आवेदन का बिंदु "आलू" प्रिंट करना है, तो सुपर-आकार के ढांचे को लागू करने का कोई अच्छा कारण नहीं है ।
जब आप एक एप्लिकेशन विकसित कर रहे हों (यह वेब, डेस्कटॉप, मोबाइल या किसी अन्य प्रकार का बोधगम्य प्रकार हो) - यदि आपको लगता है कि आपके ढांचे का आकार आपके (संभवत: भविष्य में) इसके कार्यान्वयन को "बौना" करता है, तो यह एक बड़ी बात हो सकती है। चेतावनी का संकेत है कि आपका ढांचा आपके आवेदन को केवल धुंधला कर सकता है। एक अच्छा किस्सा यह होगा कि यदि आप jQuery को शामिल करते हैं, तो बस दस्तावेज़ तैयार होने पर अपने शरीर-टैग में "लोड" -क्लास जोड़ना होगा। केवल देशी जावास्क्रिप्ट के साथ ऐसा करना थोड़ा कठिन हो सकता है , लेकिन यह आपके आवेदन को प्रस्फुटित नहीं करता है।
दूसरी ओर अगर कोई ढांचा अंदर (यानी डेटाबेस फ्रेमवर्क) पर बहुत गंदा काम करता है , तो इसे लागू करने के लिए व्यवहार्य हो सकता है, भले ही आप केवल "आंशिक रूप से" ढांचे का उपयोग कर रहे हों। एक अच्छा किस्सा यह होगा कि आप अपना ADO.NET या MongoDB- ड्राइवर बनाने की कोशिश न करें, सिर्फ इसलिए कि आपको पूरी लाइब्रेरी का उपयोग करने की आवश्यकता नहीं है।
कभी-कभी फ्रेमवर्क ओपन-सोर्स (और 'डू-जो-यू-यू-वांट-लाइसेंस) के साथ आता है। यह एक नई संभावना को खोलता है जहां एक प्रोग्रामिंग टीम केवल एक ढांचे के कुछ हिस्सों को चुन सकती है।
यह अंततः प्रश्न # 1 और # 3 पर वापस आता है।
# 3 प्रभाव।
कभी-कभी एक रूपरेखा को लागू करना सीधे अंतिम उपयोगकर्ता को प्रभावित कर सकता है । यह वेब एप्लिकेशन के लिए विशेष रूप से सच है, क्योंकि बड़े क्लाइंट-साइड फ्रेमवर्क अंत-उपयोगकर्ता के अनुभव को नकारात्मक रूप से प्रभावित कर सकते हैं। धीमी मशीनों वाले उपयोगकर्ताओं को धीमी गति से प्रतिपादन, जावास्क्रिप्ट के साथ प्रदर्शन के मुद्दे या उप-समरूप मशीनों के कारण इसी तरह के मुद्दों का अनुभव हो सकता है। धीमे कनेक्शन वाले उपयोगकर्ता धीमे (कम से कम प्रारंभिक) लोडिंग समय का अनुभव कर सकते हैं।
यहां तक कि अन्य प्रकार के अनुप्रयोगों में, अंत-उपयोगकर्ता आपके एप्लिकेशन-निर्भरता से नकारात्मक रूप से प्रभावित हो सकते हैं। फ्रेमवर्क कम से कम हमेशा कुछ डिस्क स्थान लेते हैं, और यदि आप एक मोबाइल ऐप (या यहां तक कि एक डेस्कटॉप ऐप) विकसित कर रहे हैं, तो इस पर ध्यान देने की आवश्यकता हो सकती है।
सर्वर-साइड फ्रेमवर्क (और भी अधिक वेब-विशिष्ट) आपके एंड-यूज़र्स को सबसे अधिक प्रभावित नहीं करेगा, लेकिन यह आपके बुनियादी ढांचे को प्रभावित करेगा । कुछ रूपरेखाओं में स्वयं निर्भरताएं होती हैं जिनके लिए आपको अपने वेब सर्वर को पुनः आरंभ करने की आवश्यकता हो सकती है, या तो पूरी तरह से सेवा या सर्वर।
कुछ ढांचे बहुत संसाधन-भारी भी हो सकते हैं ।
यह निश्चित रूप से # 1 और # 2 बिंदु पर वापस आता है।
यह सब सिर्फ एक बड़ा "विचारों का चक्र" है, और यह तय करने के लिए कोई वास्तविक वैज्ञानिक तरीका नहीं है कि आपको एक रूपरेखा लागू करनी चाहिए या नहीं।
कॉर्बिन मार्च ने इसे बहुत अच्छी तरह से संक्षेप में प्रस्तुत किया:
मैंने जिन समूहों के साथ काम किया है, वे एक ही काम करते हैं - लागत और लाभों पर एक अनुमान लगाते हैं, सबसे उत्पादक मार्ग चुनते हैं, और आशा करते हैं कि वे सही हैं। यह बहुत वैज्ञानिक नहीं है - एक भाग अंतर्ज्ञान, तीन भागों का अनुभव, एक भाग विपणन के लिए संवेदनशीलता, एक भाग चालाक, और पाँच भाग रैंक राय।
अभिजात्य नहीं होना भी महत्वपूर्ण है । चौखटे उपकरण हैं जिनका उपयोग किया जाना है। मुझे पता है कि दोनों चरम सीमा के लोग; एक तरफ आपके पास आदमी है जो अपने लिए जीवन बहुत कठिन बना रहा है, दूसरी तरफ आपके पास वह व्यक्ति है जो धीमी, फूला हुआ अनुप्रयोगों का निर्माण करता है।
सभी रूपरेखाओं में उपयोग-मामले हैं, यह केवल उन्हें सही उद्देश्यों के लिए लागू करने का मामला है।