क्या PHP के साथ एक बड़े webapp का निर्माण करते समय एक रूपरेखा से बचने के लिए यह समझ में आता है?

Question

कई वर्षों से PHP वेब एप्लिकेशन डेवलपर होने के नाते, मेरे पास MVC और फ्रेमवर्क का मेरा हिस्सा है। पहले तो मैंने सोचा कि वे कटी हुई ब्रेड के बाद से सबसे अच्छी चीज हैं; सब कुछ लागू करने के लिए बहुत आसान लग रहा था।

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

उदाहरण के लिए, मेरी एक परियोजना में जहां मैं स्लिम (C) + Idiorm (M) + Twig (V) का उपयोग करता हूं (जो मेरा मानना ​​है कि यह बहुत लचीला है), मुझे केवल माता-पिता के टेम्पलेट्स में गतिशील डेटा प्रदर्शित करने के लिए एक कस्टम फ़ंक्शन बनाना है; एक फ्रेमवर्क के बिना मैं शामिल फ़ाइल में केवल mysql_query () निष्पादित कर सकता था।

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

लेकिन वास्तव में, ऑल-इन-वन वेब आधारित स्कूल प्रबंधन प्रणाली की तरह एक जटिल वेब एप्लिकेशन के लिए, फ्रेमवर्क आमतौर पर उपरोक्त उदाहरण में मेरी व्यावसायिक प्रक्रिया के तरीके से मिलता है।

तो मेरा सवाल यह है कि क्या यह ठीक है कि आप मूल बातों पर वापस जाएं, और मेरी अगली परियोजना को करने के लिए मानक PHP कोड और कामगारों का उपयोग करें, जहां एक गजियन फ्रेमवर्क और लाइब्रेरी हो सकती हैं, बशर्ते मैं अच्छी कोडिंग प्रथाओं का उपयोग कर सकूं और समझदार पैटर्न का पालन कर सकूं MVC की तरह? मेरी विकास टीम बहुत छोटी है: केवल 2 प्रोग्रामर और 1 डिजाइनर। अन्य प्रोग्रामर ऊपर मेरे विचारों से सहमत हैं।

Comments

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

— एसएलटी

@ एस.लॉट: ठीक है, मैं अपने प्रश्न में एक उदाहरण प्रदान करता हूं। और वास्तव में, मुझे रूपरेखाओं से नफरत नहीं है। मैं सिर्फ आधुनिक दिनों में एक PHP फ्रेमवर्क का उपयोग नहीं करने पर लोगों के विचारों को जानना चाहता हूं।

— फुरुनोमो

"मुझे अक्सर गतिशील डेटा प्रदर्शित करने के लिए एक कस्टम फ़ंक्शन बनाना पड़ा"? एक बहुत विस्तृत उदाहरण नहीं है। यह स्पष्ट नहीं है कि फ्रेमवर्क आपको क्यों या कैसे विफल हुआ। एक बहुत ही दूरस्थ संभावना है कि आप गलत तरीके से फ्रेमवर्क का उपयोग कर रहे थे।

— S.Lott

Answer 1

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

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

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

Comments

बेशक मैं mysql_query()यहाँ और वहाँ एक यादृच्छिक फेंक नहीं है । मेरा मतलब है, क्लासिक PHP में मैं बस Categories::read_all()कुछ हेडर में परिणाम के माध्यम से जैसे कॉल और लूप में कॉल जोड़ सकता हूं , जबकि ट्विग में मुझे उसके लिए एक कस्टम ट्विग फ़ंक्शन बनाना होगा। और प्रोटोटाइप के लिए, मुझे मचान फीचर्स पसंद हैं :)

— फुरुनोमो

आपको सावधानीपूर्वक रूपरेखा तैयार करने और अपने कोड के बारे में सोचने की आवश्यकता नहीं है। फ्रेमवर्क के बिना ऐसा करना आसान है। चौखटे आप पर औसत दर्जे के कोड संगठन पैटर्न को मजबूर करते हैं।

— रेयानोस

जब आप जटिल प्रोजेक्ट्स कर रहे होते हैं तो फ्रेमवर्क वास्तव में चमकते हैं क्योंकि वे नियमों और दिशानिर्देशों का एक सेट निर्धारित करते हैं जिनका आपको पालन करना चाहिए। मैंने डीन का जवाब +1 किया क्योंकि यह मेरा अनुभव भी रहा है।

— बुरहान खालिद

Answer 2

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

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

बड़ी परियोजनाओं के लिए, मैं दूसरों से सहमत हूं, जिसका अर्थ है कि एक रूपरेखा का उपयोग करना संभवतः लंबे समय में सबसे अच्छा विकल्प होगा।

Comments

एक छोटी सी साइट के लिए क्या आसान है एक बड़े के लिए आसान नहीं हो सकता है। और दूसरा रास्ता।

— गोरान जोविक

@ गोरान जोविक, सहमत।

— डैनियल स्कोको

के लिए +1 building your own। आप इसे महसूस करते हैं या नहीं, आप कई सहायक कार्यों और / या कक्षाओं के साथ समाप्त हो जाएंगे, जिन्हें आपकी अपनी रूपरेखा माना जा सकता है।

— इज़्काता

Answer 3

उदाहरण के लिए सर्वर साइड "फ्रेमवर्क" के साथ मेरे अनुभव बहुत अप्रिय रहे हैं:

ए) जार फ़ाइल नर्क जहां आपस में टकराव या एक दूसरे के साथ ऐप सर्वर पर सामान के असंगत संस्करणों के लिए संघर्ष करना चाहते हैं और कुछ भी नहीं जानते हैं और किसी भी तरह से निर्धारित करने की स्थिति में नहीं हैं क्योंकि यह आपको तैनात करने से रोकेगा। कई सर्वर।

बी) हजारों अनावश्यक SQL निष्पादन में सबसे सरल वस्तु निर्माण का भयावह विस्फोट।

ग) विचित्र धारणा है कि एक्सएमएल की 100 लाइनों की कोडिंग किसी भी तरह से आसान है या जावा की 2 लाइनों को कोड करने से अधिक विश्वसनीय है।

डी) क्लाइंट साइड ऑब्जेक्ट्स को दूसरे में, या कभी-कभी कई अन्य भाषाओं (सी # जेएस आदि) पर मैप करने के लिए पूरी तरह से अनावश्यक सर्वर साइड POJOS की 100s लिखने की आवश्यकता है

) ३०-स्तरीय डीप स्टैक ट्रेस मिलने पर वास्तव में क्या हुआ, इसका कोई सुराग नहीं है, जिसमें उस कोड की पंक्ति भी शामिल नहीं है जिसे आपने फ्रेमवर्क को कॉल करने के लिए उपयोग किया था।

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

इस तरह से सोचने की कोशिश करें "मुझे इसकी आवश्यकता क्यों है ... क्या यह केवल रूपरेखा को खुश रखने के लिए है?" .. अगर मुझे इसकी आवश्यकता नहीं है, तो मुझे और क्या नहीं चाहिए?

Answer 4

Django डेवलपर्स द्वारा एक प्रस्तुति तरीका था, जिसे अब मुझे खोजने में परेशानी हो रही है, लेकिन वे "दक्षता की घाटी" के बारे में बात करते हैं जहां एक रूपरेखा आपको अधिक उत्पादक बनाती है।

यह मानते हुए कि जब आप एक परियोजना शुरू करते हैं, तो आपके पास रूपरेखा का कोई ज्ञान नहीं होता है, आपकी उत्पादकता शुरू में बहुत कम होगी - आप भाषा के मुहावरे के बजाय रूपरेखा के सम्मेलन को सीखेंगे (जो उम्मीद है कि आप पहले से ही जानते हैं)।

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

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

प्रस्तुति में, वे उल्लेख करते हैं कि यदि आपको पहले से ही ढांचे के सम्मेलनों का ज्ञान है, तो छोटे आकार की परियोजनाओं में दक्षता के लिए प्रारंभिक बाधा नहीं है।

इस प्रकार, छोटी परियोजनाओं के लिए (मेरे अनुभव में, ~ 500 घंटे से कम कुछ भी) एक फ्रेमवर्क के साथ आपकी दक्षता बिना आपकी दक्षता की तुलना में अधिक, संभावना होगी। एक बार जब आप एक निश्चित सीमा (500 और 800 घंटों के बीच, IME) में पहुंच जाते हैं, तो आपको यह एहसास होने लगता है कि फ्रेमवर्क क्या दे सकता है, इसकी सीमाएँ हैं।

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

Answer 5

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

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

मैंने सुना है कि Zend फ्रेमवर्क 2 (वर्तमान में बीटा में) एक बेहतर उत्पाद है, लेकिन मेरे मुंह में छोड़ दिया गया बुरा स्वाद Zend 1 का मतलब है कि मैं इसे आज़माने के लिए किसी भी जल्दी में नहीं हूं।

फिर भी, इस बिंदु पर मैं सिर्फ शेख़ी कर रहा हूँ। :) वहाँ बहुत सारे ढांचे हैं, प्रत्येक अपने पेशेवरों और विपक्षों के साथ, मैं उनमें से कुछ का मूल्यांकन करने का सुझाव दूंगा।

Answer 6

आप जो वर्णन करते हैं, उसे अतीत में "अमूर्त प्रेरित जटिलता" कहा जाता है। इसे प्रबंधित करने का एकमात्र पेपर है: डेविड केपल द्वारा प्रबंध अमूर्त-प्रेरित जटिलता । केपेल सुझाव देंगे कि रूपरेखा में एक डिजाइन है जो अमूर्त प्रेरित जटिलता का कारण बनता है।

Answer 7

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

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

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

Answer 8

एक फ्रेमवर्क का उपयोग करके अपने कोड लिखने के कई पक्ष हैं:

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

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

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

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

Answer 9

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

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