क्या रूपरेखा बहुत अमूर्त है? [बन्द है]


24

मैं एक वर्ष से कम के लिए प्रोग्रामिंग कर रहा हूं और कुछ अनुभव लेखन प्रणाली के अनुप्रयोग, वेब एप्लिकेशन और व्यवसायों / संगठनों के लिए स्क्रिप्ट है। हालाँकि, एक चीज़ जो मैंने कभी नहीं की है, वह Django, Rails या Zend जैसे ढांचे के साथ काम कर रही है।

Django फ्रेमवर्क को देखते हुए, मैं थोड़ा निराश हूं कि फ्रेमवर्क में कितना सार है। मैं DRY और न्यूनतम कोड के मुख्य लक्ष्यों को समझता हूं, लेकिन विभिन्न मॉड्यूलों पर यह अधिक निर्भरता और कोर कार्यों के भारी अमूर्त को ऐसा लगता है:

  1. मॉड्यूल / चौखटे की कभी बदलती प्रकृति के कारण कार्यक्रम तेजी से दिनांकित होते हैं,

  2. उपलब्ध फ्रेमवर्क और मॉड्यूल के ढेरों के कारण समझने में कठिन कोड बनाता है और उनके सभी आइडिओसिंकसरीज,

  3. जब तक आपने सभी दस्तावेज़ नहीं पढ़े हों, कोड को कम तार्किक बनाता है; यानी, मैं कुछ सूची बोध और सशर्त तर्क के माध्यम से पढ़ सकता हूं और यह पता लगा सकता हूं कि एक कार्यक्रम क्या कर रहा है, लेकिन जब आप ऐसे कार्यों को देखते हैं, जिन्हें मनमाने ढंग से तार और शब्दकोशों में पारित करने की आवश्यकता होती है, तो चीजों को समझना थोड़ा मुश्किल हो जाता है जब तक कि आप पहले से ही एक गुरु नहीं होते। एक दिया मॉड्यूल; तथा:

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

क्या हमें वास्तव में किसी ऐसी चीज़ के ऊपर 50 परतों की तरह रखने की ज़रूरत है जो MySQL क्वेरी के रूप में सरल है? PHP के PDO इंटरफ़ेस जैसे कुछ का उपयोग क्यों नहीं किया जाता है, जहां तैयार किए गए स्टेटमेंट / इनपुट परीक्षण को संभाला जाता है, लेकिन सार्वभौमिक रूप से समझने योग्य SQL क्वेरी अभी भी फ़ंक्शन का एक हिस्सा है?

क्या वे सार वास्तव में उपयोगी हैं? क्या फ़ीचर ब्लॉट उन्हें बेकार नहीं बनाता है, बिना फ्रेमवर्क का उपयोग किए लिखे गए समान अनुप्रयोगों की तुलना में एप्लिकेशन को अधिक कठिन बना देता है?


22
कीवर्ड: as a relatively inexperienced programmer- जितना अधिक समय तक आप सॉफ्टवेयर बनाते हैं, उतना ही आप पहिया कम करने और घर पर अधिक समय बिताने की सराहना करेंगे जो आपको प्यार करते हैं।
सर्गर्सग

13
Do we really need to put like 50 layers of abstraction on top of something as simple as a MySQL query?- सबसे पहले, एक अच्छा ढांचा अमूर्त (शायद 2 या 3 आंतरिक) की एक परत है, और दूसरी बात यह है कि "MySQL क्वेरी के रूप में सरल रूप में कुछ" वास्तव में सार का एक अच्छा दर्जनों शामिल है। उस क्वेरी के बाद भी जिसे आपने अपनी व्याख्या की गई भाषा से निष्पादित किया है, उसने डेटाबेस सर्वर पर कर दिया है, फिर भी आपके पास भौतिक संग्रहण पर फ़ाइल सिस्टम पर डेटाबेस पर डेटाबेस पर प्रश्न हैं। इसलिए संक्षेप में: हाँ, हमें सार चाहिए, क्योंकि वे हमारे सिर को विस्फोट से बचाते हैं।
back2dos

7
एफडब्ल्यूआईडब्ल्यू, हां, कभी-कभी हम नलसाजी से आगे निकल जाते हैं। जितनी बार मैंने काम किया है उससे छोटा होने के लिए मैं एक फ्रेमवर्क का उपयोग करता हूं, जो कि मैंने मूल रूप से सोचा था; कभी-कभी अपने स्वयं के कोड परिणाम को सरल डिजाइन में लिखते हैं, समस्या डोमेन के करीब फिट, और लाइसेंस के सिरदर्द के बिना बेहतर प्रदर्शन।
रॉबर्ट हार्वे

2
वहाँ कई सूक्ष्म ढांचे हैं। ये हल्के ढांचे हैं जो कुछ लोगों को अधिक आकर्षक लगते हैं। उदाहरण के लिए: flask.pocoo.org । मैंने कभी इसका इस्तेमाल नहीं किया।
ipaul

यह प्रश्न पुराने स्कूल WCF और LINQ की दर्दनाक यादों को SQL में वापस लाता है । दो चौखटे मैंने बहुत समय लड़े हैं। एक ऐसा ढांचा, जो अभी-अभी पर्याप्त है, समझने में सरल है, और अनुकूलित करना आसान है, वास्तव में एक दुर्लभ पक्षी है। लेकिन वे मौजूद हैं।
फिल

जवाबों:


21

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

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

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

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

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

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


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

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


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

@ तेज़ झटका? हाँ। बेहतर? कि यह बहस का मुद्दा है।
दोपहर का भोजन 0317

@ Lunmeat317 मेरा क्या मतलब है कि अगर कोई नहीं जानता कि वह क्या कर रहा है और एक रूपरेखा का उपयोग करता है, तो वह कुछ गलती करने की संभावना है। लेकिन अगर वह खुद से सभी कोड लिखता है, तो वह एक गलती करने के लिए लगभग निश्चित है।
svick

2
इस बात से सहमत। "आप पुस्तकालयों का उपयोग करते हैं, लेकिन फ्रेमवर्क आपका उपयोग करते हैं" एक अच्छा उद्धरण है। हमें अधिक पुन: प्रयोज्य पुस्तकालयों की आवश्यकता है और सभी कम-से-एक ढांचे की आवश्यकता है।
gbjbaanb

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

29

यह मुझे लगता है कि आप अमूर्तताओं और कोड के पुन: उपयोग को गलत समझते हैं।

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

जैसे आप स्क्रैच से एक जंबो जेट नहीं बनाते हैं, बिना किसी इंजीनियरिंग ज्ञान का उपयोग किए सालों तक अन्य विमान बनाते समय, आप स्क्रैच से बिजनेस सॉफ्टवेयर नहीं लिखते हैं।

आप पहले स्थान पर PHP या रूबी का उपयोग करके प्राप्त करते हैं, आपके पास पहले से ही बड़ी मात्रा में सार हैं, क्या आप हैं? सबसे स्पष्ट वाले:

  1. ऑपरेटिंग सिस्टम, प्रोग्रामिंग लैंग्वेज और कंपाइलर असेंबलर और हार्डवेयर पर भारी अमूर्तता प्रदान करते हैं

  2. वेब सर्वर सॉकेट्स, फेलओवर, एचटीटीपी प्रोटोकॉल आदि का अमूर्त हिस्सा प्रदान करता है।

  3. SQL एक अमूर्तता प्रदान करता है कि कैसे डेटा को एक स्थायी भंडारण समर्थन पर संग्रहीत किया जाता है और तेज पहुंच के लिए मेमोरी में रखा जाता है, ACID, मिररिंग इत्यादि सुनिश्चित करता है।

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

फ्रेमवर्क इससे अलग नहीं हैं। आप वे कर सकते हैं जो वे करते हैं। बस यही कि आप अपना समय उसी कार्यक्षमता को पुनः प्राप्त करने में व्यर्थ करेंगे, इस अंतर के साथ कि वे रूपरेखाएँ इसे बेहतर बनाएंगी और बहुत बार उनके कोड का परीक्षण किया जाएगा और आपकी तुलना में बेहतर ढंग से दस्तावेज किया जाएगा।

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

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

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

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

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

  • यदि आपके पास अपनी गाड़ी थी, तो आपके सहयोगी को कुछ कस्टम कोड बनाए रखना होगा, शायद दस्तावेज भी नहीं, बिना कहीं मदद प्राप्त किए।

एक फ्रेमवर्क का उपयोग करके, आप एक कोड पर भरोसा करते हैं जो है:

  • अनुभवी डेवलपर्स द्वारा लिखित,

  • अक्सर जोड़ी-समीक्षा की जाती है,

  • यूनिट परीक्षण किया है,

  • व्यापक रूप से प्रलेखित,

  • हजारों डेवलपर्स द्वारा वर्षों से उपयोग किया जाता है,

  • अक्सर समर्थित है, इसलिए आप बग की रिपोर्ट कर सकते हैं और वास्तव में इसे देख सकते हैं,

  • कई डेवलपर्स द्वारा जाना जाता है जो संभावित कैविट्स और मुद्दों को जानते हैं और स्टैक ओवरफ्लो जैसी साइटों पर मदद कर सकते हैं।

  • आपके लिए अभी उपलब्ध है, मुफ्त में।


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

3
@MattFenwick - मेरे लिए ओपी कह रहा है कि अगर आप इन रूपरेखाओं का उपयोग करते हैं, तो अमूर्त बहुत दूर चला गया है और अधिक समस्याओं का कारण बनता है तो वे लायक हैं। निश्चित रूप से सवाल बुरा अमूर्त बुरा नहीं है?
जेफ ओ

3

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


2

हम्मीरएसबी का हम्माम एक पहलू जो हमने बहुत काम किया वह था हमारा ढांचा। हालांकि इस तरह की अमूर्तता के साथ दो मूलभूत समस्याएं हैं। य़े हैं:

  1. निर्भरता विस्फोट, और

  2. गलत अमूर्तता

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

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

पाठ्यक्रम की एक बड़ी समस्या यह है कि कोड को अधिक स्वचालित रूप से स्वचालित किया जाता है, खासकर जब यह अपारदर्शी भी होता है, तो यह देखना कठिन है कि क्या गलत है। यह ORM के बारे में एक बिंदु है जो @jhewlett ऊपर बनाता है (देखें /software//a/190807/63722 )।

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

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

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


2

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

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

निश्चित रूप से सभी रूपरेखाओं के लिए एक सीखने की अवस्था है, और यह आपके लिए अधिक काम करने वाले कार्य के साथ सख्त है। हालाँकि, फ्रेमवर्क सीखने का मतलब है कि आपने समय बचा लिया है और अगली बार स्क्रैच से अपने आवेदन को दोबारा लिखने के बजाय, अगली परियोजना पर उस सभी ज्ञान का लाभ उठा सकते हैं।

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


1

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

ऑब्जेक्ट-रिलेशनल मैपर (ORMs) पर विचार करें। वे महान हैं कि वे आपके लिए बहुत सारे थकाऊ मैपिंग कोड का ध्यान रखते हैं। वे आपके लिए अपनी वस्तुएँ भी बना सकते हैं। हालाँकि, SQL को दूर करने में, प्रदर्शन के बारे में तर्क करना और अपनी अड़चनों को अनुकूलित करना बहुत कठिन है।

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


1

मैं सहमत हूं कि "आप पुस्तकालयों का उपयोग करते हैं, लेकिन फ्रेमवर्क आपका उपयोग करते हैं"। यह एक बहुत ही साफ तरीका है। मैं इस बात से सहमत नहीं हूं कि जैसे ही आप कोड का पुन: उपयोग करना शुरू करते हैं, आप एक रूपरेखा का निर्माण करने लगते हैं, जैसा कि आपको आमतौर पर अपने कोड का फिर से उपयोग करने के लिए एक त्वरित प्रतिलिपि और पेस्ट से ज्यादा कुछ करने की आवश्यकता नहीं होती है - यह एक है पुस्तकालय आप बना रहे हैं; आप अपनी साइट या ऐप में कोड कैसे लाते हैं, इसके बारे में अजीब होने की आवश्यकता नहीं है।

मेरे लिए, महत्वपूर्ण बिंदु यह है कि मुझे एक संसाधन से अधिक बाहर निकलना होगा, इससे मुझे निवेश करने की आवश्यकता है। या, किसी अन्य कोण से, मैं कहूंगा कि जैसे ही किसी रूपरेखा की आवश्यकता उपलब्ध (ओं) की तुलना में अधिक है, सभी लाभ अनुपस्थित हैं। तो यह 'हाँ! कृप्या! और धन्यवाद!' उन सभी के लिए जो अपने स्वयं के html / CSS / PHP और SQL के रूप में आवश्यक रूप से सीधे और कार्य छोड़ देंगे कि संपत्ति बनाते हैं।

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


0

कुछ लोग कहते हैं कि यह फ्रेमवर्क का हॉलीवुड सिद्धांत है: "हमें कॉल न करें, हम आपको कॉल करेंगे"। इसके विपरीत, जब भी आप लाइब्रेरी का उपयोग करते हैं, तो आपका कोड लाइब्रेरी को कॉल करता है , न कि दूसरे तरीके से।

जैसा कि आप देख सकते हैं, महत्वपूर्ण बिंदु वह है जो नियंत्रण में है - अर्थात्, नियंत्रण के प्रवाह के नियंत्रण में। कौन फैसला करता है कि कौन सा बयान किसके बाद चलाया जाता है।

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

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

यदि आप फ्रेमवर्क पसंद करते हैं, तो आप सुरक्षा के लिए स्वतंत्रता का आदान-प्रदान करना पसंद करते हैं: आप शायद अधिक व्यावहारिक हैं और आप अपने काम को सही तरीके से करने के लिए दूसरों पर भरोसा करते हैं। यदि आप लाइब्रेरी पसंद करते हैं, तो आप स्वतंत्रता के लिए सुरक्षा का आदान-प्रदान करना पसंद करते हैं: आप शायद एक आदर्शवादी से अधिक हैं और आप दूसरे के विचारों और दावों पर सवाल उठाते हैं।

मुझे नहीं लगता कि यह तय करना समझदारी होगी कि पूर्व या उत्तरार्ध जैसा होना बेहतर है।

आपके प्रश्न का उत्तर देना: क्या रूपरेखा बहुत अधिक अमूर्त है? यह इस पर निर्भर करता है कि आप कौन हैं, और विशेष रूप से पहले सिद्धांतों से आप किस दूरी पर सहज महसूस करते हैं।

...

और भी विशेष रूप से, अगर आपको Django जैसी रूपरेखा पसंद नहीं है, तो फ्लास्क की तरह "माइक्रोफ़्रामवर्क" खोजें। :)

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