कस्टम एमवीसी फ्रेमवर्क बनाने के लाभ

Question

स्क्रैच से कस्टम PHP एमवीसी फ्रेमवर्क बनाना एक छोटी डिजिटल एजेंसी के लिए पूरी तरह से व्यर्थ हो जाएगा?

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

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

यह सिर्फ मुझे समझ में नहीं आता है - क्या कोई मुझे अन्यथा पीछा कर सकता है?

Answer 1

किसी भी ढांचे

पेशेवरों के लिए

• सटीक कार्यक्षमता प्राप्त आप चाहते हैं
• छोटे अपनी परियोजना
• कोड

विपक्ष के साथ परिचित करने के लिए महत्वपूर्ण जानकारी पर नियंत्रण

• सब कुछ टूट जाता है कि आप अपने आप को ठीक करना होगा
• की गलतियों से सीखने के नहीं मिलता है अतीत

निजी तौर पर मेरा सुझाव है कम ऑडियंस के कारण के रूप में कई कीड़े देखा नहीं मिलेगा खुद को लिखने पर विचार करने से पहले मौजूदा ढांचे की खोज करना। बस याद रखें कि ठीक है अगर आप इसे एक दिन में समझ में नहीं आता है!

Answer 2

मैं इसे व्यर्थ मानता हूं। लेकिन यह PHP प्रोग्रामर का अभिशाप है जो बार-बार पहिया का आविष्कार करते हैं। मुझे पता है कि मैं किस बारे में बात कर रहा हूं। मैंने भी कोशिश की।

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

बहुत सारे अप्रयुक्त कोड के साथ बिंदु पूरी तरह से मान्य नहीं है। ज़ेंड में कक्षाएं होती हैं जिन्हें दूर तक हटाया जा सकता है।

संपादित करें: PHP के प्रदर्शन उदाहरण के लिए eAccelerator के माध्यम से बढ़ाया जा सकता है। मुझे एक नया नया ढांचा बनाने से आसान लगता है।

Answer 3

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

चूंकि वे एक फूला हुआ ढांचा बारे में चिंतित हैं, मेरा सुझाव है कि बजाय वे एक हल्के PHP ढांचे CodeIgniter और Kohana इस तरह के रूप में प्रयोग की जांच।

Answer 4

यह समय बर्बाद है। जब तक वे फेसबुक के यातायात के साथ कोई साइट नहीं बनाते हैं, तो प्रदर्शन हिट वे वाईआई बनाम जैसे कुछ का उपयोग कर सकते हैं।

Answer 5

एमवीसी एफडब्ल्यू औसत परियोजना कोड बेस का 5% से कम है, इसलिए मैं दृढ़ता से प्रत्येक परियोजना के लिए एमवीसी बनाने की सिफारिश करें और इसे परियोजना विनिर्देशों में अनुकूलित करें। अगर किसी के पास एमवीसी पैटर्न और एमवीसी फ्रेमवर्क का निर्माण और निर्माण करने में कुछ अनुभव है, तो इसे कुछ दिनों में बनाया जा सकता है।

सामान्य तर्क कस्टम एफडब्ल्यू द्वारा दी गई गति और प्रदर्शन हैं।

Answer 6

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

मैंने एक बार कंपनी में काम किया जो Django का उपयोग करने के बजाय अपना स्वयं का वेब ढांचा लिखने के लिए निर्धारित था। फ्रेमवर्क के "व्यवस्थापक" भाग पर काम कर रहे डेवलपर्स में से एक ने कहा कि मैं चाहता था कि वह अपना काम खो दे क्योंकि Django ऑटो जेनरेट किया गया व्यवस्थापक है।

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

Answer 7

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

Answer 8

यह समय की बर्बादी नहीं है, लेकिन मैं आपसे सहमत हूं, मैंने इसे स्वयं भी करने की कोशिश की। मैं जिस परियोजना पर काम कर रहा हूं उसके आधार पर मैं ज़ेंड, कोड इग्निटर और ईंधन का उपयोग कर रहा हूं।

परिणाम जो मैंने अपना स्वयं का ढांचा बनाने में किया था वह समय सीमा है। यदि आप एक बहुत ही तंग समय सीमा के साथ एक परियोजना पर काम कर रहे हैं तो अपना खुद का ढांचा बनाना एक बुरा विचार होगा।

Answer 9

यह इस बात पर निर्भर करता है कि वे किस तरह की परियोजनाएं करते हैं, और उनकी क्या ज़रूरत है। कभी भी यह न भूलें कि सॉफ्टवेयर में, 'सर्वश्रेष्ठ' हमेशा आप जो कर रहे हैं उस पर निर्भर करता है। सब कुछ के लिए कोई 'सुनहरा समाधान' नहीं है। इसमें एमवीसीएस शामिल है।

वहाँ अपनी खुद की MVC कोड करने के लिए विभिन्न कारणों से कर रहे हैं:

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

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

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

कोडिनेटर के साथ प्रमुख अनुप्रयोगों को कोड करने वाले लोगों के साथ क्या होने जा रहा है? क्या वे स्वयं कोडधारक प्रतिष्ठानों की सुरक्षा करने जा रहे हैं? इसलिए वास्तव में अपने स्वयं के एमवीसी के रखरखाव बन रहे हैं? या वे उनके लिए एमवीसी बनाए रखने के लिए बाहरी पार्टियों को किराए पर ले जा रहे हैं?

कोई अच्छा भविष्य निवेश नहीं है।

मेरे स्वयं के एमवीसी कोडिंग के लिए मेरी प्राथमिकता मुख्य रूप से एक एमवीसी है जो कोडिंग की अपनी शैली फिट बैठती है। एक MVC के लिए मेरा मापदंड:

• फास्ट विकास
• फास्ट संशोधन
• कम रखरखाव
• स्पीड
• सुरक्षा
• चरम सादगी
• विश्वसनीयता संबंध में भविष्य के विकास के लिए

मैंने पहले अपने लिए एक प्रमुख एमवीसी कोड किया है। और मैं अभी भी अपनी शौक वेबसाइटों में से एक पर सफलतापूर्वक इसे चला रहा हूं जो प्रति माह ~ 600,000-1,200,000 अद्वितीय आगंतुकों को संभालता है। किसी दिए गए पल में, 250+ विज़िटर (गूगल एनालिटिक्स - इसमें कोई भी बॉट शामिल नहीं है) साइट पर मौजूद हो सकता है, पेज के बाद पेज को हड़ताली कर सकता है। और यह भी झपकी नहीं है। मुझे वह पसंद है। इसके बावजूद इसमें कई कमियां हैं जिन्हें मैं पसंद नहीं करता, यह शानदार काम करता है।

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

उल्लेख नहीं है कि यह नए कौशल को विकसित करने और विकसित करने का एक शानदार तरीका है।

लेकिन एक बात जरूरी है: इसे बहुत अच्छी तरह से योजना बनाएं, और उस पर निर्माण रखें, इसे बदलना और सुधारना।