सामग्री
मला कोणती फ्रेमवर्क वापरायची आहे ते विचारा आणि मला बहुधा कुरुप म्हातारी महिलेची आठवण येईल आणि सर्व फ्रेमवर्क एकमेकांइतकेच वाईट असल्याचे आपल्याला सांगेन. ते सर्व अगदी वाईट आहेत असे म्हणू शकत नाही, परंतु पीएचपीमध्ये आमच्याकडे अकल्पनीयरित्या मोठ्या संख्येने फ्रेमवर्क आहेत (सामान्यत: एन + 1 असे नमूद केले जाते, जिथे एन जगातील पीएचपी विकसकांची संख्या आहे) आणि त्या सर्वांना कदाचित अर्थ प्राप्त झाला ज्याने त्यांचा शोध लावला त्या व्यक्तीला.
आपण नेमके काय बनवण्याचा प्रयत्न करीत आहात याची पर्वा न करता केवळ एक फ्रेमवर्क वापरण्याचा प्रयत्न करण्यापेक्षा फ्रेमवर्कची निवड करणे अधिक चांगले आहे कारण ते सर्वात चांगले आहे. फ्रेमवर्क ऑफरिंगच्या या निवडीचा अर्थ असा आहे की आपण प्रोजेक्टच्या गरजा भागविणारी एखादी गोष्ट निवडू शकता आणि कदाचित त्याचे दस्तऐवजीकरण देखील केले जाईल. कोणत्याही प्लॅटफॉर्मवरील फ्रेमवर्क खरोखरच स्ट्रक्चर्स, पुन्हा वापरण्यायोग्य मॉड्यूल्स आणि लायब्ररी प्रदान करण्यासाठी असतात आणि समान कार्यक्षमता पुन्हा पुन्हा वाढवण्यासाठी सर्व कंटाळवाणे आणि पुनरावृत्ती कार्ये टाळतात. उदाहरणार्थ सीएमएस तयार करताना, काहीतरी माझ्यासाठी फॉर्म फील्डवर प्रक्रिया आणि सत्यापित केले पाहिजे; माझ्या स्वत: च्या डिव्‍हाइसेसवर सोडल्यास कदाचित मी काहीतरी महत्त्वाचे गमावतो आणि त्याऐवजी प्रत्येक प्रकल्पातील घटक मी करू इच्छितो भिन्न, प्रत्येक वेळी सारख्या नसण्याऐवजी!
पूर्ण स्टॅक फ्रेमवर्क
डेव्हलपर करीता भरपूर आर्किटेक्चरचा अनुभव न घेता, झेंड फ्रेमवर्क सारख्या पूर्ण-स्टॅक फ्रेमवर्कसाठी छान जागा असू शकते. हे नवीन अनुप्रयोग चालू ठेवण्यासाठी चांगली रचना देते आणि त्याभोवती एक चांगली ‘पारिस्थितिकीय व्यवस्था’ आहे - भरपूर पुस्तके, शिकवण्या आणि काही वाजवी कागदपत्रे देखील. जर आपण एखादा मोठा अनुप्रयोग तयार करण्याचा प्रयत्न करीत असाल जो बर्‍याच लोकांद्वारे देखरेख केला जाईल, तर एक लोकप्रिय, सर्वसमावेशक चौकट एक चांगली निवड असेल कारण ती बर्‍याच रचना तयार करेल आणि सुप्रसिद्ध आणि समजेल.
वेगळे करण्यास मदत करण्यासाठी रचना असणे नेहमीच चांगले असते; माझ्या कारकीर्दीच्या सुरुवातीला मी काहींबरोबर काम केले खूप कनिष्ठ विकासक आणि त्यांना एमव्हीसी (मॉडेल व्ह्यू कंट्रोलर) नमुना शिकवण्याचा प्रयत्न केला, जे त्यावेळी तुलनेने नवीन होते. आम्ही व्ह्यू लेयरमध्ये स्मार्टटी वापरण्याचा निर्णय घेतला; अंशतः जेणेकरून डिझाइनर टेम्पलेटसह अधिक सहजपणे कार्य करू शकतील आणि अंशतः जेणेकरून जेव्हा कोणी माझ्या डेस्कवर येऊन “स्मार्टीसह एक्स कसे करावे?” मी म्हणू शकतो "दृश्यात एक्स करू नका!" (10 पैकी नऊ वेळा, हे उत्तर होते). फ्रेमवर्क असणे आम्हाला आमच्या अनुप्रयोगाच्या इतर भागांमध्ये समान वेगळेपणा शोधण्यात मदत करते. त्यापैकी बरेचजण स्मार्टी, किंवा माझे नवीन आवडते, ट्विग यासारख्या टेम्पलेटिंग लेयरच्या विरूद्ध एकत्रिकरण करण्यास समर्थन देतात, जेणेकरून आपण ती साधने आपल्यास कोणती फ्रेमवर्क निवडता हे आपल्या बरोबर घेऊन जाऊ शकता.
भार हलका करा
झेंड फ्रेमवर्कपेक्षा बर्‍याच फिकट फ्रेमवर्क आहेत, उदाहरणार्थ मी कोडइग्निटर सह थोडे काम करतो. हे झेंड फ्रेमवर्क जितके व्यापक आणि मजबूत आहे? नाही, ते नाही. परंतु buildingप्लिकेशन वेगाने तयार करणे सक्षम करण्यासाठी मदतनीस फ्रेमवर्क म्हणून ते उपयुक्त आहे. सर्वसाधारणपणे, तुलनेत कमी 'मदतनीस' असलेल्या कार्यक्षमतेसह फ्रेमवर्क शोधणे सुलभ होऊ शकते कारण तुकडे एकत्र कसे जातात हे अधिक स्पष्ट आहे. अपरिचित फ्रेमवर्कमध्ये (माझ्यासाठी ते सर्वकाही खूपच चांगले आहे), हे स्वयंचलित बिट्स आहे ज्यामुळे कार्य करणे आणि डीबग करणे कठीण होते.
"नवीन चौकटीत हरवले" ही भावना अटळ आणि पूर्णपणे निराश आहे; एखादा अनुभवी विकसकसुद्धा नवशिक्यासारखा वाटतो जेव्हा त्यांना काहीही कसे कार्य करते हे माहित नसते. जर आपण खरोखर दुर्दैवी असाल तर आपण एक चौकट निवडला असेल ज्याचे आयआरसी चॅनेल आपल्याला एक मूर्ख असल्याचे देखील सांगेल! हा अगदी नकारात्मक प्रारंभिक अनुभव आहे ज्याने बर्‍याच लोकांना नवीन फ्रेमवर्क वापरण्यास किंवा प्रथम स्थानावरील दत्तक घेण्यास बंदी घातली आहे आणि त्या आरंभिक अडथळ्यांपासून नवीन वापरकर्त्यांना मदत करण्याचे काम फार कमी फ्रेमवर्क करतात.
पीएचपीमध्ये आमच्याकडे अशी काही फ्रेमवर्क देखील आहेत जी मी सहसा हा शब्द वापरतो त्या मार्गाने खरोखर फ्रेमवर्क नसतात. आमच्याकडे काही सुंदर घटक फ्रेमवर्क आहेत; झेटा घटक (पूर्वीचे ईझेड घटक) आणि सिम्फोनी घटक (जसे की त्यांची साइट पाहिली आहे का? त्यांनी सर्वोत्कृष्ट कलाकृतीसाठी पुरस्कार जिंकला आहे!) यासारख्या वापरायच्या-जाणा-या रचनांकरिता आणि एकत्र छान खेळण्यासाठी लायब्ररीचे संग्रह. यातील सर्वात उत्तम आणि सर्वात अंडरस्टँडिंग अर्थातच, पीएचपीची स्वत: ची पेअर आणि पीईसीएल ऑफरिंग्ज आहेत - जे काहीसे या फ्रेमवर्कच्या या शूर नवीन जगामध्ये विसरतात.
मायक्रोफ्रेमवर्क्स
मायक्रोफ्रेमवर्क्स ही पीएचपीमध्ये एक उदयोन्मुख ट्रेंड आहे; या सुपर-लाइटवेट ऑफरिंग्ज आहेत ज्या आपल्याला एकत्र गोष्टी अधिक द्रुतपणे गोंद लावण्यास मदत करतात. एक चांगले उदाहरण म्हणजे स्लिम, जे वापरण्यास अतिशय वेगवान आणि सोपे आहे आणि रेस्टॉरंट संकल्पना समजते. हे यूआरएल नमुने असलेल्या ‘मार्ग’ च्या कल्पनेभोवती आधारित आहे. आपण मार्ग नोंदविला आणि एक कॉलबॅक द्या जी जेव्हा विनंती केली जाईल तेव्हा विनंती केली पाहिजे.
बरेच पीएचपी विकसक एक चौकट अवलंबतात आणि त्यास चिकटतात किंवा ते कदाचित कामाच्या ठिकाणी आणि दुसर्या आपल्या छंद किंवा ओपन सोर्स प्रोजेक्टसाठी वापरू शकतात. वापरण्यासाठी "सर्वोत्कृष्ट" फ्रेमवर्कबद्दल फारसे एकमत नाही म्हणून प्रत्येकजण आपल्या माहितीनुसारच चिकटून राहतो आणि याचा परिणाम म्हणजे मोठ्या प्रमाणात फ्रेमवर्कचा समांतर विकास! मला निवडण्यासाठी आवडत आहे, परंतु मी ते नमूद केले आहे की ते सर्व एकमेकांसारखे वाईट आहेत?
जर आपल्याला झेंड फ्रेमवर्क माहित असेल तर आपण स्वत: चे वर्णन झेंड फ्रेमवर्क विकसक म्हणून केले पाहिजे; जोपर्यंत आपणास पकडण्याची संधी मिळेपर्यंत आपणास दुसर्या चौकटीत लिहिणे आरामदायक ठरणार नाही आणि आपण बहुतेक वेळा क्वचित पीएचपी फंक्शन्स वापरत नसाल तर कदाचित आपल्याला आठवत नाही. आम्ही केवळ फ्रेमवर्क-विशिष्ट विकसक बनलो आहोत ही कल्पना, केवळ अमूर्ततेच्या स्तरांवर कार्य करीत आहे, ती PHP साठी थोडी विचित्र आहे. तथापि, ही "वेब समस्येचे निराकरण करण्याची भाषा" आहे. हे सी मध्ये लिहिलेले आहे आणि स्वतःमध्ये एक वेगवान, हलकी भाषा आहे ... प्रदान केल्याने आपण मोठ्या फ्रेमवर्क बूटस्ट्रॅप प्रक्रियेची वाट पाहत नाही. या संदर्भातून मायक्रो पीएचपी मॅनिफेस्टो उद्भवला, ज्याला आपण फंक्टाट्रॉन म्हणतो अशा मनुष्याने लिहिलेले (जरी त्याचे नाव खरोखर एड फिन्कलर आहे). हे असंख्य विधानांची मालिका आहे की असंख्य इंटरऑपरेबल लहान मॉड्यूल्स तयार करणे ठीक आहे, ते चांगले नाही आणि खरोखरच जावाचे आयुष्य खूप लहान आहे - जरी ते पीएचपीमध्ये लिहिलेले असले तरीही.
