frameworks - ढांचे और पुस्तकालय के बीच क्या अंतर है?




terminology libraries (14)

ढांचे और पुस्तकालय के बीच क्या अंतर है?

मैंने हमेशा पुस्तकालय के बारे में सोचा कि वस्तुओं और कार्यों के एक सेट के रूप में जो किसी विशेष समस्या को हल करने या अनुप्रयोग विकास के विशिष्ट क्षेत्र (यानी डेटाबेस पहुंच) के आसपास केंद्रित है; दूसरी तरफ एक ढांचा एक विशेष पद्धति (यानि एमवीसी) के आसपास केंद्रित पुस्तकालयों का संग्रह है और अनुप्रयोग विकास के सभी क्षेत्रों को शामिल करता है।


लाइब्रेरी:

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

फ्रेमवर्क:

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

लाइब्रेरी, फ्रेमवर्क और आपकी कोड छवि का प्रतिनिधित्व:

KeyDifference:

लाइब्रेरी और ढांचे के बीच महत्वपूर्ण अंतर "नियंत्रण में उलटा" है । जब आप लाइब्रेरी से कोई विधि कॉल करते हैं, तो आप नियंत्रण में हैं। लेकिन एक ढांचे के साथ, नियंत्रण उलटा हुआ है: ढांचा आपको कॉल करता है । Source.

रिश्ता:

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


असल में इन शर्तों का अर्थ उनके द्वारा उपयोग किए जाने वाले संदर्भ के आधार पर कई अलग-अलग चीजों का हो सकता है।

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

इस प्रकार आपके पास एक ही पैकेज में सबकुछ है जो आपको अपने एप्लिकेशन में लाइब्रेरी का उपयोग करने की आवश्यकता है (एक सी / सी ++ / ऑब्जेक्टिव-सी लाइब्रेरी बिना .h फाइलें बेकार है, जब तक कि आप उन्हें कुछ लाइब्रेरी दस्तावेज के अनुसार स्वयं लिखते हैं), बजाय फ़ाइलों के समूह को चारों ओर स्थानांतरित करने के लिए (एक मैक बंडल यूनिक्स स्तर पर सिर्फ एक निर्देशिका है, लेकिन यूआई इसे एक फ़ाइल की तरह व्यवहार करता है, जैसा कि आपके पास जावा में जेएआर फाइलें हैं और जब आप इसे क्लिक करते हैं, तो आप आमतौर पर नहीं देखते अंदर क्या है, जब तक कि आप सामग्री को दिखाने के लिए स्पष्ट रूप से चयन नहीं करते)।

विकिपीडिया फ्रेमवर्क को "buzzword" कहते हैं। यह एक सॉफ्टवेयर ढांचे को परिभाषित करता है

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

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

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

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


आपकी व्याख्या मेरे लिए बहुत अच्छी लगती है ... एक लाइब्रेरी कुछ भी हो सकती है जो संकलित और अन्य कोड में पुन: उपयोग के लिए स्वयं निहित है, इसकी सामग्री पर सचमुच कोई प्रतिबंध नहीं है।

दूसरी तरफ एक ढांचे से आपके विकास, एमवीसी की तरह, एप्लिकेशन विकास के कुछ विशिष्ट क्षेत्र में उपयोग के लिए सुविधाओं की एक श्रृंखला होने की उम्मीद है।


इस तरह मैं इसके बारे में सोचता हूं (और दूसरों द्वारा तर्कसंगत देखा है):

एक पुस्तकालय कुछ आपके कोड के भीतर निहित है। और एक ढांचा आपके आवेदन के लिए एक कंटेनर है।


एक लाइब्रेरी एक संकुचित-स्कोप्ड उद्देश्य के लिए कार्यक्षमता लागू करती है जबकि एक ढांचा पुस्तकालयों का संग्रह होता है जो सुविधाओं की एक विस्तृत श्रृंखला के लिए समर्थन प्रदान करता है। उदाहरण के लिए, लाइब्रेरी System.Drawing.dll ड्राइंग कार्यक्षमता को संभालती है, लेकिन समग्र .NET ढांचे का केवल एक हिस्सा है।


जैसा कि मैंने हमेशा इसका वर्णन किया है:

एक पुस्तकालय एक उपकरण है।

एक ढांचा जीवन का एक तरीका है।

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


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


मुझे इस जवाब के स्रोत को याद नहीं है (मुझे लगता है कि मैंने इसे इंटरनेट में .ppt में पाया), लेकिन जवाब काफी सरल है।

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

यह समस्या किसी एप्लिकेशन में जानकारी लॉग या डिबगिंग हो सकती है, चार्ट खींच सकती है, एक विशिष्ट फ़ाइल प्रारूप (एचटीएमएल, पीडीएफ, एक्सएलएस) बना सकती है, डेटा बेस से कनेक्ट हो सकती है, किसी एप्लिकेशन का एक हिस्सा या एक पूर्ण एप्लीकेशन या एक कोड लागू होता है डिजाइन पैटर्न

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

लाइब्रेरी और फ्रेमवर्क के आधार पर मुख्य अंतर निर्भरता है कि वे अपने स्वयं के कोड को betwen करते हैं, अन्य शब्दों में फ्रेमवर्क का उपयोग करने के लिए आपको एफडब्ल्यू में लगभग सभी कक्षाओं, मॉड्यूल या कोड का उपयोग करने की आवश्यकता होती है, लेकिन लाइब्रेरी का उपयोग करने के लिए आप एक या अपने स्वयं के आवेदन में lib में कुछ कक्षाएं, मॉड्यूल या कोड

इसका अर्थ यह है कि यदि एक फ्रेमवर्क है, उदाहरण के लिए, उस ऐप में ढांचे का उपयोग करने के लिए 50 कक्षाएं हैं जिन्हें आप उपयोग करने की ज़रूरत है, तो अपने कोड में 10-15 या उससे अधिक कक्षाएं बताएं, क्योंकि इस तरह फ्रेमवर्क तैयार किया गया है, कुछ वर्ग (कक्षाओं की वस्तुओं) ढांचे में अन्य वर्गों में विधियों के लिए इनपुट / पैरामीटर हैं। .NET ढांचे, वसंत, या किसी भी एमवीसी ढांचे को देखें।

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

और फ्रेमवर्क और पुस्तकालयों की तुलना में और श्रेणियां भी हैं, लेकिन यह विषय बंद है।


मुझे लगता है कि आपने काफी अंतर को कम किया है: ढांचा एक फ्रेम प्रदान करता है जिसमें हम अपना काम करते हैं ... किसी भी तरह, यह एक साधारण पुस्तकालय की तुलना में अधिक "बाधा" है।
ढांचे को पुस्तकालयों के एक सेट में स्थिरता भी जोड़नी चाहिए।


मुझे लगता है कि पुस्तकालय एक लक्ष्य तक पहुंचने के लिए उपयोगिता का एक सेट है (उदाहरण के लिए, सॉकेट, क्रिप्टोग्राफी, आदि)। फ्रेमवर्क लाइब्रेरी + RUNTIME EINVIRONNEMENT है। उदाहरण के लिए, एएसपी.नेट एक ढांचा है: यह HTTP अनुरोध स्वीकार करता है, पेज ऑब्जेक्ट बनाता है, लाइफ कण घटनाओं का आह्वान करता है। फ्रेमवर्क यह सब करता है, आप थोड़ा सा कोड लिखते हैं जो जीवन चक्र के एक विशिष्ट समय पर चलाया जाएगा वर्तमान अनुरोध!

वैसे भी, बहुत दिलचस्पी सवाल!


मैं भूल जाता हूं कि मैंने यह परिभाषा कहाँ देखी, लेकिन मुझे लगता है कि यह बहुत अच्छा है।

लाइब्रेरी एक मॉड्यूल है जिसे आप अपने कोड से कॉल करते हैं, और एक ढांचा एक मॉड्यूल है जो आपके कोड को कॉल करता है।



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

मान लीजिए कि आप एक मछली करी बनाना चाहते हैं। फिर आपको तेल , मसालों और अन्य उपयोगिता जैसी सामग्री की आवश्यकता होती है। आपको मछली की भी आवश्यकता है जो आपके पकवान को तैयार करने के लिए आधार है (यह आपके आवेदन का डेटा है)। एक साथ सभी सामग्री एक ढांचे कहा जाता है। अब आप अपनी मछली करी बनाने के लिए एक या एक संयोजन में उनका उपयोग करेंगे जो आपका अंतिम उत्पाद हैअंडरस्कोर.जेएस , बूटस्ट्रैप.एसएस , बूटस्ट्रैप.जेएस , fontawesome , AngularJS आदि से बने वेब फ्रेमवर्क के साथ तुलना करें। उदाहरण के लिए, ट्विटर बूटस्ट्रैप v.35

अब, यदि आप केवल एक घटक मानते हैं, जैसे कि तेल कहें। आप जो भी तेल चाहते हैं उसका उपयोग नहीं कर सकते हैं क्योंकि यह आपकी मछली (डेटा) को बर्बाद कर देगा। आप केवल जैतून का तेल का उपयोग कर सकते हैं। Underscore.js के साथ तुलना करें। अब आप किस ब्रांड का तेल उपयोग करना चाहते हैं वह आपके ऊपर है। कुछ पकवान अमेरिकी जैतून का तेल (underscore.js) या भारतीय जैतून का तेल (lodash.js) के साथ बनाया गया था। यह केवल आपके आवेदन का स्वाद बदल देगा। चूंकि वे लगभग एक ही उद्देश्य की सेवा करते हैं, इसलिए उनका उपयोग डेवलपर की वरीयता पर निर्भर करता है और वे आसानी से बदल सकते हैं।

फ्रेमवर्क : पुस्तकालयों का एक संग्रह जो आपके आवेदन के लिए अद्वितीय गुण और व्यवहार प्रदान करता है। (सभी अवयव)

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

प्लगइन : लाइब्रेरी (यूई-राउटर -> एंगुलरजेएस) या संयोजन में कई पुस्तकालयों (डेट-पिकर -> बूटस्ट्रैप.एसएस + jQuery) के लिए एक उपयोगिता निर्माण, जिसके बिना आपकी प्लगइन अब अपेक्षित काम कर सकती है।

पीएस AngularJS एक एमवीसी ढांचा है लेकिन एक जावास्क्रिप्ट पुस्तकालय है। क्योंकि मेरा मानना ​​है कि पुस्तकालय देशी प्रौद्योगिकी (इस मामले में जावास्क्रिप्ट) के डिफ़ॉल्ट व्यवहार को बढ़ाता है।


वेब डेवलपर परिप्रेक्ष्य से:

  1. लाइब्रेरी को दूसरी लाइब्रेरी द्वारा आसानी से बदला जा सकता है। लेकिन ढांचा नहीं कर सकता।

    यदि आपको jquery date picker लाइब्रेरी पसंद नहीं है, तो आप अन्य दिनांक पिकर जैसे बूटस्ट्रैप डेट पिकर या पिकडेट के साथ प्रतिस्थापित कर सकते हैं।

    यदि आपको एंगुलरजेएस पसंद नहीं है जिस पर आपने अपना उत्पाद बनाया है, तो आप किसी भी अन्य ढांचे के साथ प्रतिस्थापित नहीं कर सकते हैं। आपको अपना संपूर्ण कोड बेस फिर से लिखना होगा।

  2. ज्यादातर लाइब्रेरी फ्रेमवर्क की तुलना में बहुत कम सीखने वक्र लेता है। उदाहरण: underscore.js एक पुस्तकालय है, Ember.js एक ढांचा है।