विषय
मुझसे पूछें कि किस ढांचे का उपयोग करना है और मेरे पास शायद एक क्रोधी बूढ़ी औरत का क्षण होगा और आपको बताएगा कि सभी ढांचे एक दूसरे के समान खराब हैं। यह कहना नहीं है कि वे सभी खराब हैं, बिल्कुल, लेकिन PHP में हमारे पास अकल्पनीय रूप से बड़ी संख्या में ढांचे हैं (आमतौर पर एन + 1 के रूप में उद्धृत किया जाता है, जहां एन दुनिया में PHP डेवलपर्स की संख्या है), और वे सभी शायद समझ में आते हैं उस व्यक्ति के लिए जिसने उनका आविष्कार किया।
चौखटे का चुनाव करना शायद केवल एक ढांचे का उपयोग करने की कोशिश करने से बेहतर है, भले ही आप वास्तव में क्या बनाने की कोशिश कर रहे थे, क्योंकि यह 'सर्वश्रेष्ठ' है (जो भी 'सर्वश्रेष्ठ' के उपाय से)। ढांचे के प्रसाद के इस चयन का मतलब है कि आप कुछ ऐसा चुन सकते हैं जो परियोजना की जरूरतों को पूरा करता है और इसे दस्तावेज भी किया जा सकता है। किसी भी प्लेटफॉर्म पर फ्रेमवर्क वास्तव में संरचना, पुन: प्रयोज्य मॉड्यूल और पुस्तकालय प्रदान करने के लिए होते हैं, और आम तौर पर एक ही कार्यक्षमता को बार-बार बनाने के लिए सभी उबाऊ और दोहराए जाने वाले कार्यों से बचते हैं। उदाहरण के लिए सीएमएस का निर्माण करते समय, कुछ को मेरे लिए प्रपत्र फ़ील्ड को संसाधित और मान्य करना चाहिए; अगर मेरे अपने उपकरणों पर छोड़ दिया जाए तो मुझे कुछ महत्वपूर्ण याद आ सकता है और मैं प्रत्येक परियोजना के तत्वों को बहुत कुछ करना चाहता हूं जो हैं भिन्न हो, बजाय जो हर बार एक जैसे होते हैं!
फुल-स्टैक फ्रेमवर्क
पूर्ण-स्टैक फ्रेमवर्क, जैसे कि ज़ेंड फ्रेमवर्क, एक डेवलपर के लिए बहुत सारे आर्किटेक्चर अनुभव के बिना शुरू करने के लिए एक अच्छी जगह हो सकती है। यह एक नए एप्लिकेशन को लटकाने के लिए अच्छी संरचना देता है, और इसके चारों ओर एक अच्छा 'पारिस्थितिकी तंत्र' है - बहुत सारी किताबें, ट्यूटोरियल और कुछ उचित दस्तावेज भी। यदि आप एक बड़े एप्लिकेशन का निर्माण करने की कोशिश कर रहे हैं जिसे बहुत से लोगों द्वारा बनाए रखा जाएगा, तो एक लोकप्रिय, व्यापक ढांचा एक अच्छा विकल्प होने की संभावना है क्योंकि यह काफी संरचना को निर्देशित करेगा और अच्छी तरह से ज्ञात और समझा जाएगा।
अलगाव में मदद करने के लिए संरचना होना हमेशा अच्छा होता है; अपने करियर की शुरुआत में मैंने कुछ के साथ काम किया बहुत जूनियर डेवलपर्स और उन्हें एमवीसी (मॉडल व्यू कंट्रोलर) पैटर्न सिखाने का प्रयास किया, जो उस समय अपेक्षाकृत नया था। हमने व्यू लेयर में स्मार्टी का उपयोग करने का निर्णय लिया; आंशिक रूप से ताकि डिज़ाइनर टेम्प्लेट के साथ अधिक आसानी से काम कर सकें, और आंशिक रूप से ताकि जब कोई मेरे डेस्क पर आए और कहा "मैं स्मार्टी के साथ एक्स कैसे करूं?" मैं कह सकता था "दृश्य में X मत करो!" (10 में से नौ बार, यही उत्तर था)। फ्रेमवर्क होने से हमें अपने एप्लिकेशन के अन्य हिस्सों में समान अलगाव खोजने में मदद मिलती है। उनमें से कई स्मार्टी, या मेरी नई पसंदीदा, ट्विग जैसी टेम्प्लेटिंग परत के खिलाफ एकीकरण का समर्थन करते हैं, ताकि आप उन उपकरणों को अपने साथ ले जा सकें जो भी आप चुनते हैं।
बोझ को हल्का
ज़ेंड फ्रेमवर्क की तुलना में बहुत सारे हल्के ढांचे हैं, उदाहरण के लिए मैं कोडइग्निटर के साथ काफी काम करता हूं। क्या यह Zend Framework जितना व्यापक और मजबूत है? नहीं, ऐसा नहीं है। लेकिन एक एप्लिकेशन को तेजी से बनाने में सक्षम बनाने के लिए एक सहायक ढांचे के रूप में, यह उपयोगी है। सामान्य तौर पर, कम 'सहायक' कार्यक्षमता वाले ढांचे को अपना रास्ता खोजना आसान हो सकता है क्योंकि यह अधिक स्पष्ट है कि टुकड़े एक साथ कैसे चलते हैं। एक अपरिचित ढांचे में (मेरे लिए, यह बहुत ज्यादा सब कुछ है), यह स्वचालित बिट्स है जो इसे काम करना और डीबग करना कठिन बनाता है।
"नए ढांचे में खो जाने" की यह भावना अपरिहार्य और पूरी तरह से निराशाजनक है; यहां तक कि एक अनुभवी डेवलपर भी नौसिखिया की तरह महसूस करता है जब वे नहीं जानते कि कुछ भी कैसे काम करता है। यदि आप वास्तव में बदकिस्मत हैं, तो आपने एक ऐसा ढांचा चुना होगा जिसका IRC चैनल आपको बताएगा कि आप भी एक मूर्ख हैं! यह बहुत ही नकारात्मक प्रारंभिक अनुभव है जो बहुत से लोगों को एक नए ढांचे का उपयोग करने या पहली जगह में अपनाने से रोकता है, और बहुत कम ढांचे नए उपयोगकर्ताओं को उस प्रारंभिक बाधा पर मदद करने का अच्छा काम करते हैं।
PHP में हमारे पास कुछ फ्रेमवर्क भी हैं जो वास्तव में उस तरह से फ्रेमवर्क नहीं हैं जिस तरह से मैं आमतौर पर शब्द का उपयोग करता हूं। हमारे पास कुछ सुंदर घटक ढांचे हैं; उपयोग-पर-इच्छा के लिए और एक साथ अच्छी तरह से खेलने के लिए डिज़ाइन किए गए पुस्तकालयों का संग्रह, जैसे कि Zeta Components (पहले eZ Components) और Symfony Components (क्या आपने उनकी साइट देखी है? वे सर्वश्रेष्ठ कलाकृति के लिए पुरस्कार जीतते हैं!)। इनमें से सबसे अच्छा और सबसे अंडरसंग, निश्चित रूप से, PHP का अपना PEAR और PECL प्रसाद है - किसी तरह ये फ्रेमवर्क की इस बहादुर नई दुनिया में भूल जाते हैं।
माइक्रोफ्रेमवर्क
PHP में माइक्रोफ्रेमवर्क एक उभरता हुआ चलन है; ये सुपर-लाइटवेट प्रसाद हैं जो आपको चीजों को एक साथ और अधिक तेज़ी से चिपकाने में मदद करते हैं। एक अच्छा उदाहरण स्लिम है, जो बहुत तेज़ और उपयोग में आसान है, और RESTful अवधारणाओं को समझता है। यह 'मार्गों' के विचार पर आधारित है, जो यूआरएल पैटर्न हैं। आप एक मार्ग पंजीकृत करते हैं और कॉलबैक देते हैं जिसे उस यूआरएल के अनुरोध पर लागू किया जाना चाहिए।
अधिकांश PHP डेवलपर एक फ्रेमवर्क अपनाते हैं और उसके साथ चिपके रहते हैं, या वे एक का उपयोग काम पर और दूसरे को अपने शौक या ओपन सोर्स प्रोजेक्ट के लिए कर सकते हैं। उपयोग करने के लिए "सर्वश्रेष्ठ" ढांचे के बारे में बहुत कम सहमति है, इसलिए हर कोई बस वही जानता है जो वे जानते हैं और नतीजा बड़ी संख्या में ढांचे का समानांतर विकास होता है! मुझे चुनने के लिए चयन करना अच्छा लगता है, लेकिन क्या मैंने उल्लेख किया है कि वे सभी एक दूसरे के समान ही खराब हैं?
यदि आप Zend Framework को जानते हैं तो आप अंत में खुद को Zend Framework डेवलपर के रूप में वर्णित करते हैं; जब तक आपको इसके साथ पकड़ने का मौका नहीं मिलता, तब तक आप किसी अन्य ढांचे में लिखने में सहज नहीं होंगे, और यदि आप अक्सर उनका उपयोग नहीं करते हैं तो आपको चीजों के लिए कई कच्चे PHP फ़ंक्शन याद नहीं होंगे। यह विचार कि हम फ्रेमवर्क-विशिष्ट डेवलपर्स बन गए हैं, केवल अमूर्तता की परतों के शीर्ष पर काम कर रहे हैं, PHP के लिए थोड़ा अजीब है। आखिरकार, यह "वेब समस्या को हल करने के लिए" भाषा है। यह C में लिखा गया है और अपने आप में एक तेज़, हल्की भाषा है ... बशर्ते आप एक बड़े फ्रेमवर्क बूटस्ट्रैप प्रक्रिया के चलने की प्रतीक्षा न करें! इस संदर्भ से माइक्रोपीएचपी घोषणापत्र उभरा, जिसे हम फंकट्रॉन कहते हैं (हालांकि उसका नाम वास्तव में एड फिंकलर है)। यह बयानों की एक श्रृंखला है जो कह रही है कि कई इंटरऑपरेबल छोटे मॉड्यूल बनाना ठीक है, बड़ा बेहतर नहीं है, और वास्तव में, जावा के लिए जीवन बहुत छोटा है - भले ही यह PHP में लिखा गया हो।
