Zend फ्रेमवर्क, व्यक्तिपरक छापें

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

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

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


Zend फ्रेमवर्क वेब अनुप्रयोगों के विकास के लिए एक उत्कृष्ट, विचारशील और सुविधाजनक मंच के रूप में तैनात है। मेरी व्यक्तिगत राय में एक विशिष्ट वेब अनुप्रयोग क्या है? खैर, ये कई अलग-अलग स्क्रीन, कई रूप, कई प्लेटें हैं। यह सब सक्रिय रूप से एक डेटाबेस के साथ काम करता है, आमतौर पर एक रिलेशनल डेटाबेस के साथ। ठीक है, मैं MySQL के साथ 95% मामलों में अधिक विशिष्ट हूं। इसलिए, वेब अनुप्रयोगों के विकास के लिए मंच से, मैं कम से कम फॉर्म बनाने के लिए अच्छे अवसरों की उम्मीद करता हूं, विभिन्न स्क्रीन और रिलेशनल डेटाबेस के साथ सुविधाजनक काम करता हूं। और इसलिए मैंने मास्टर करना शुरू कर दिया।

पहली चीज़ जो मुझे करने की ज़रूरत थी, वह थी Zend फ्रेमवर्क की मूल बातें सीखना। मैंने इस मंच के लिए समर्पित एक पुस्तक पढ़ी “ ज़ेंड फ्रेमवर्क। PHP वेब अनुप्रयोग विकास। विक्रम वासवानी द्वारा पोस्ट किया गया । ” ऐसा लगता है कि इस समय इस तरह की रूपरेखा के लिए समर्पित प्रिंट में यह लगभग एकमात्र रूसी भाषा की पुस्तक है। सिद्धांत रूप में, पुस्तक काफी अच्छी है। इसे पढ़ने के बाद, मुझे सामान्य समझ थी कि फ्रेमवर्क के साथ कैसे काम किया जाए। फिर मैंने अंतरालों को भरने के लिए आधिकारिक दस्तावेज का अध्ययन करना शुरू किया और आम तौर पर यह समझा कि यह रूपरेखा मुझे और क्या प्रदान कर सकती है। आखिरकार, पुस्तक इंजन की सभी विशेषताओं पर विचार नहीं करती है। व्यापक और समझदारी से लिखा गया आधिकारिक दस्तावेज यहां फ्रेमवर्क है ।zend.com /manual/ ru लगभग एक हफ्ते बाद, मैंने फैसला किया कि हम एप्लिकेशन को विकसित करना शुरू कर सकते हैं।

कोडिंग पर मेरा विश्वदृष्टि

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

मैं OOP और OOP पैटर्न के उपयोग का सम्मान करता हूं। लेकिन आवेदन को उचित और कोड पठनीयता या इसके आगे के सुधार को वास्तव में सरल बनाना चाहिए। पैटर्न के लिए पैटर्न खराब हैं।

अच्छा कोड स्पष्ट कोड है। स्पष्ट कोड संक्षिप्त कोड है। यदि आप कोड को छोटा लिख ​​सकते हैं, तो एक नियम के रूप में यह अधिक समझ में आएगा। कोड की अधिक तार्किक रूप से जुड़े टुकड़े जो एक मॉनिटर स्क्रीन पर फिट होते हैं, बेहतर है।

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

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

if(@$_POST['action'] == 'done') { $dbi->exec(“UPDATE bug SET status='done' WHERE id=:bugId“, array('bugId'=>$bugid)); $message = “Status changed to <b>Done</b>”; } elseif(@$_POST['action'] == 'delete') { // …. } //….   20-30   ... 

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

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

अब वेब परियोजनाओं में टेम्पलेट्स के बारे में थोड़ा। मुझे समझ में नहीं आता है कि जब स्मार्टी जैसी टेम्प्लेट भाषाओं का उपयोग किया जाता है। जब एक पूर्ण PHP भाषा होती है, तो एक नई और आम तौर पर सीमित भाषा का आविष्कार क्यों करें? क्या यह वास्तव में एक लेआउट डिजाइनर के लिए कठिन है कि PHP शानी का उपयोग कैसे करें अगर (...) और foreach (...)? यह स्मार्टी की तुलना में अधिक जटिल नहीं है, लेकिन हम परियोजना में एक नई विदेशी भाषा नहीं जोड़ते हैं।
वैसे, ऐसा होता है कि टेम्प्लेट्स (या दृश्य) इतने जटिल होते हैं कि उन्हें न केवल यदि और फोरच का उपयोग करना पड़ता है, बल्कि कक्षाओं और ऑब्जेक्ट्स सहित बहुत जटिल निर्माण भी होते हैं, जो एक दूसरे से विरासत में मिलते हैं। हालांकि एक ही समय में, प्रस्तुति का कार्य एक ही रहता है - शुष्क डेटा से HTML कोड उत्पन्न करने के लिए।

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

 function renderTemplate($file, $vars) { foreach($vars as $_name => $_var) { $$_name = $_var; } require $file; } //  renderTemplate(“page.tpl.php”, array( 'menu' => array('/about'=>' ', '/contacts'=>'') 'title' => '' )); 

प्लस, ज़ाहिर है, कैशिंग के लिए परिरक्षण के लिए सबसे सरल बंधन है। ऐसा लगता है कि खुशी के लिए और कुछ नहीं चाहिए।

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

Zend फ्रेमवर्क स्थापित करें

रूपरेखा, जैसा कि यह निकला, वजन लगभग 25 एमबी है और इसमें लगभग 3,000 फाइलें हैं। कमजोर नहीं, मैंने सोचा! जाहिरा तौर पर वहाँ सब कुछ महसूस किया जाता है कि आप केवल सपने देख सकते हैं!

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

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

यह पता चला कि Zend फ्रेमवर्क साझा होस्टिंग के साथ काम करने के लिए डिज़ाइन नहीं किया गया है, जैसा कि लांच करने के लिए VirtualHost निर्देशिका अपनी परियोजना के रूट के अलावा अन्य में रजिस्टर करने के लिए कहता है। इसलिए आपके पास कम से कम VDS सर्वर होना चाहिए। ठीक है, हाँ, मैंने राय सुनी है कि यदि आप कुछ ऐसा विकसित कर रहे हैं जो साझा होस्टिंग पर काम करता है, तो आप शांत नहीं हैं, और आपके पास पेशेवरों के लिए कोई जगह नहीं है। हालांकि मैंने हमेशा सोचा था कि सभी वेब परियोजनाओं का 95% साझा होस्टिंग पर घूम रहा है। ठीक है, वैसे भी, फ़ाइल के कुछ स्ट्रोक के बाद, मुझे अभी भी शार्क हॉटिंग पर जाने का प्रोजेक्ट मिला।
डेटाबेस के साथ काम करें

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

डेटाबेस के साथ काम करने के लिए, फ्रेम Zend_Db घटकों का उपयोग करता है। यह आपको SQL के माध्यम से सबसे आम DBMS के साथ काम करने की अनुमति देता है।

यह आपको एसक्यूएल का उपयोग किए बिना प्रश्न बनाने की अनुमति देता है, और कुछ मुश्किल वस्तु का निर्माण करके, जो कि रूपरेखा के अंदर अभी भी एसक्यूएल में बदल जाता है। यह सिर्फ मुझे लगता है कि अधिक या कम जटिल क्वेरी लिखने के लिए, इस रैपर के निर्माण की तुलना में SQL क्वेरी लिखना अभी भी अधिक सुविधाजनक और स्पष्ट है, जो कि, जैसा कि यह पता चला है, आपको किसी भी जटिल क्वेरी से कोई मतलब नहीं है। सामान्य तौर पर, मेरा मानना ​​है कि एसक्यूएल का अध्ययन करने से बेहतर है कि इसे एक रूपरेखा बनाने के लिए मजबूर करने की कोशिश की जाए, और यह आशा की जाए कि यह इसे एक इष्टतम तरीके से करेगा। Native SQL सभी प्रोग्रामर्स के लिए बेहतर पढ़ा जा सकने वाला, समझने योग्य है और आपको किसी विशेष DBMS की सभी विशेषताओं का उपयोग करने की अनुमति देता है। आप कहते हैं कि ऑब्जेक्ट क्वेरी डिज़ाइनर का उपयोग करने से आप किसी विशेष डेटाबेस की बोली से अमूर्त हो सकते हैं? जटिल प्रश्नों के साथ - यह हमेशा के लिए सार से दूर है, यहां तक ​​कि एक शांत कंस्ट्रक्टर के साथ भी। ठीक है, एक और तर्क - मुझे एक भी परियोजना याद नहीं है जहां डीबीएमएस को बदलना आवश्यक होगा, और साथ ही पूरे प्रोजेक्ट, व्यापार तर्क और डेटा मॉडल के वैश्विक परिवर्तन का कोई सुझाव नहीं था, अर्थात्। पिछले एक के आधार पर एक पूरी तरह से नई परियोजना लिखना। सामान्य पृष्ठभूमि के खिलाफ पिछले संस्करण से डेटा मॉडल वर्ग के एक टुकड़े को सहेजने से जीवन बहुत आसान नहीं होगा।

तो, Zend फ्रेमवर्क में SQL के साथ क्या काम करता है? खैर, कुछ इस तरह से:
$ परिणाम = $ db-> fetchAssoc ('आइटम का चयन करें> जहां उम्र> 18');

और फिर $ परिणाम के साथ, आप तालिका के रूप में एक साहचर्य सरणी के साथ काम कर सकते हैं (हालांकि यह काफी सरणी नहीं है), जो बहुत सुविधाजनक है। आप आगे की प्रक्रिया के लिए सरणी पास कर सकते हैं, या आप इसे सीधे प्रदर्शन के लिए एक दृश्य में पास कर सकते हैं।

कई और सुविधाजनक तरीके हैं जो SQL प्रश्नों के परिणाम निकालते हैं:
fetchCol () - एक एकल कॉलम को पुनः प्राप्त करता है। जब आपको ID shek की सूची प्राप्त करने की आवश्यकता हो तो सुविधाजनक
fetchRow () - पहली पंक्ति को पुनः प्राप्त करता है। यह सुविधाजनक है जब आपको प्राथमिक कुंजी द्वारा एक प्रविष्टि का चयन करने की आवश्यकता होती है।
fetchOne () - केवल एक मान प्राप्त करता है। यह तब भी सुविधाजनक है जब आपको वास्तव में एक मूल्य प्राप्त करने की आवश्यकता होती है और सरणी से बाहर एक तत्व लेने के लिए कोड लिखना नहीं चाहता।
fetchPairs () - एक ऐररेटिव ऐरे के रूप में वैल्यूज़ पेयर रिट्रीव करता है। एक कुंजी-मूल्य हैश बनाता है। विभिन्न शब्दकोश बनाने के लिए यह बहुत उपयोगी है।

ये सभी विधियाँ आपको कोड की पंक्तियों की संख्या को कम करने की अनुमति देती हैं। सभी प्रकार के अतिरिक्त छोरों को निकालें, तत्वों को निकालना, आदि। नतीजतन, मॉडल में कोड का थोक काफी कम हो जाता है।

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

ठीक है, चलो आगे बढ़ते हैं। यह डेटा तालिका और उन्हें पेड़ की तरह सरणी के निर्माण से दूर करने के लिए आवश्यक है। यह पता चला है कि यह आम ऑपरेशन भी लागू नहीं है। यानी ऐसा कुछ नहीं है:

$ hierarhy = db-> fetch_tree ("Select id, parent_id, टाइटल फ्रॉम ट्री ',' id ',' parent_id ');

आगे बढ़ो। SQL में, आपको पैरामीटर पास करने की आवश्यकता है। ठीक है, हाँ, पहली नज़र में, सब कुछ सरल है। यह निम्नानुसार किया जाता है:

$ परिणाम = $ db-> fetchAssoc ('चयन करें * समाचार से जहां आईडी =?', 7);

तुम भी कुछ प्लेसहोल्डर्स डाल सकते हैं।

$ परिणाम = $ db-> fetchAssoc ('चयन करें * समाचार से कहाँ = =? और टाइप =?', सरणी (2, 8));

केवल अब, जब कार्यक्रम जटिल हो जाता है, तो प्रश्नों की जटिलता बढ़ती है, और दर्जनों पैरामीटर हो सकते हैं। हमें नामित प्लेसहोल्डर्स की आवश्यकता है। उनके सीरियल नंबर द्वारा माना जाता है प्लेसहोल्डर - यह दूर है कोड की स्पष्टता के लिए अनुकूल नहीं है। जैसा कि यह निकला, Zend फ्रेमवर्क उन्हें लागू नहीं करता है! वे काम करते हैं, लेकिन केवल अगर चयनित डेटाबेस उनका समर्थन करता है। उदाहरण के लिए, यदि आपने MySQLi को चुना है, तो आप नामित प्लेसहोल्डर्स के साथ काम करने में सक्षम नहीं होंगे। क्या नामांकित मापदंडों का अनुकरण करना वास्तव में इतना कठिन था? ठीक है, यह बात सॉल्व हो गई। यह पता चला है कि यदि आप एडॉप्टर के रूप में मैसकली के बजाय Pdo_Mysql का चयन करते हैं, तो नामित पैरामीटर काम करना शुरू कर देंगे, क्योंकि वे पीडीओ के अंदर ही उत्सर्जित होते हैं। सच कहूं, तो मुझे यह तुरंत नहीं मिला। अपमान थम गया, लेकिन एक अप्रिय विवाद बना रहा।

अक्सर SQL प्रश्नों में आपको इस तरह कोड का उपयोग करना होता है

चयन करें * आइटम से जहां आईडी में (1,3,5,8,12)

जहां आईडी-सूची गतिशील रूप से सरणी से उत्पन्न होती है।
मुझे व्यक्तिगत रूप से Zend फ्रेमवर्क पर खूबसूरती से ऐसा करने का कोई तरीका नहीं मिला है। एक निश्चित उद्धरण है () विधि। आप इसे इस तरह से उपयोग कर सकते हैं

$ sql = $ db-> quoteInto ("आइटम का चयन करें * जहां से id = IN (?)", सरणी (1,3,5,8,12));

हम क्वेरी में नामित पैरामीटर का उपयोग करने में असमर्थता के साथ कई टुकड़ों से एक जटिल क्वेरी के संकलन के साथ डालते हैं, लेकिन फिर हमें आवश्यक एसक्यूएल कोड मिलता है। सरणी खाली होने के बाद ही हम अभी भी एक सिंटैक्स त्रुटि प्राप्त करते हैं, क्योंकि एसक्यूएल तो बाहर का चयन करेगा * आइटम से आईडी = आईएन ()।
तो या तो हम सब कुछ लपेटते हैं यदि (गणना ($ idList)> 0), या हम प्रत्येक बार सरणी में जानबूझकर अमान्य पहचानकर्ता जोड़ते हैं, उदाहरण के लिए -1। क्रिवेंको, लेकिन समाधान। लेकिन वैसे भी, यह पता चला है? कि आप एक जटिल एसक्यूएल क्वेरी केवल स्ट्रिंग को समेट कर बना सकते हैं। और मैं किसी भी SQL क्वेरी को PHP के किसी भी एम्बेडिंग के बिना कोड के एक टुकड़े के रूप में देखना पसंद करता हूं। और यह लानत है, HTML और PHP को मिलाना बुरा माना जाता है, लेकिन SQL और PHP, आप देखते हैं, ठीक हैं।

सामान्य तौर पर, Zend_Db मुझे वास्तव में पसंद नहीं है। मैंने इसके उपयोग से कोई महान लाभ या मजबूत सुविधा नहीं देखी। वैसे, Zend_Db का वजन 500KB से अधिक है।

सामान्य तौर पर, डेटाबेस के साथ काम करने के लिए, मैं निम्नलिखित सार्वजनिक विधियों के साथ घर में बने छोटे वर्ग का उपयोग करना पसंद करता हूं:

कनेक्ट ($ विन्यास) - डेटाबेस से जुड़ता है
fetchTable ($ sql, $ params) - रिकॉर्ड की एक सरणी लौटाता है
fetchRow ($ sql, $ params) - एक रिकॉर्ड लौटाता है
fetchCol ($ एसक्यूएल, $ पैरामीटर) - एकल स्तंभ लौटाता है
fetchOne ($ sql, $ params) - अदिश मान लौटाता है
fetchPairs ($ sql, $ key, $ value, $ params) - एक सरणी कुंजी - मान लौटाता है
fetchDict ($ sql, $ key, $ params) - एक सरणी कुंजी देता है - रिकॉर्ड
fetchTree ($ sql, $ key, $ पैरेंट, $ params) - एक पेड़ लौटाता है
निष्पादित ($ sql, $ params) - एक गैर-चयन क्वेरी निष्पादित करता है
getInsertId () - अंतिम उत्पन्न ऑटो वेतन वृद्धि लौटाता है
getAffectedRows () - संशोधित रिकॉर्ड की संख्या लौटाता है

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

आकार

वेब एप्लिकेशन के लिए अगली सबसे महत्वपूर्ण चीज है फॉर्म। आमतौर पर उनमें से एक बहुत हैं। संरचना और उपस्थिति भी बहुत विविध हैं। Zend फ्रेमवर्क रूपों के साथ काम करने के लिए Zend_Form का उपयोग करता है।

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

 $username = new Zend_Form_Element_Text('username'); $username ->addValidator('alnum') ->addValidator('regex', false, array('/^[az]+/')) ->addValidator('stringLength', false, array(6, 20)) ->setRequired(true) ->addFilter('StringToLower'); '); $username = new Zend_Form_Element_Text('username'); $username ->addValidator('alnum') ->addValidator('regex', false, array('/^[az]+/')) ->addValidator('stringLength', false, array(6, 20)) ->setRequired(true) ->addFilter('StringToLower'); 

सभी फ़ील्ड्स बनाने के बाद, उन्हें फॉर्म ऑब्जेक्ट में जोड़ें।

 $form ->setAction('/somepath') ->setMethod('post') ->addElement($name) ->addElement($company) ->addElement($email) ->addElement($phone) ->addElement($action); 

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

 $form->addElement(new Zend_Form_Element_Text('username')) ->setRequired(true) ->addValidator('regex', false, array('/^[az]+/')); 

लेकिन यह असंभव है!

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

आइए "xxx" ईमेल के वक्र को निर्दिष्ट करने का प्रयास करें। हमें एक त्रुटि संदेश प्राप्त होता है:

'xxx' बुनियादी प्रारूप स्थानीय-भाग @ होस्टनाम में कोई मान्य ईमेल पता नहीं है

सामान्य। बेशक संदेश को रूसी में अनुवाद करना आवश्यक होगा, लेकिन वहां यह आसानी से किया जा सकता है। और अब आइए “i@_domain.xx” और भी अधिक घुमावदार पते की कोशिश करें।
और यहाँ है कि हम क्या मिलता है:

'_domain.xx' ईमेल पते के लिए कोई मान्य होस्टनाम नहीं है 'i@_domain.xx'
'_domain.xx' एक DNS होस्टनाम प्रतीत होता है, लेकिन ज्ञात सूची के विरुद्ध TLD से मेल नहीं खा सकता है
'_domain.xx' एक मान्य स्थानीय नेटवर्क नाम प्रतीत नहीं होता है
'i' को डॉट-एटम प्रारूप के विरुद्ध मिलान नहीं किया जा सकता है
'i' को उद्धृत-स्ट्रिंग प्रारूप के विरुद्ध मिलान नहीं किया जा सकता है
'i' ईमेल पते के लिए कोई मान्य स्थानीय हिस्सा नहीं है 'i@_domain.xx'

6 पोस्ट! इसकी जरूरत किसे है? क्या औसत उपयोगकर्ता वास्तव में समझता है कि एक TLD, उद्धृत-स्ट्रिंग या डॉट-एटम क्या है? औसत उपयोगकर्ता को केवल एक संदेश की आवश्यकता है - "अमान्य ई-मेल" और यह बात है! लेकिन मानक उपकरण इसकी अनुमति नहीं देते हैं। संदेशों के इस ढेर के उत्पादन से छुटकारा पाने के लिए - अपने स्वयं के सत्यापनकर्ता वर्ग को लिखना प्रस्तावित है।

ठीक है, चलो कहते हैं कि हम प्रपत्र किया था, सभी क्षेत्रों, सभी प्रमाणकों में स्थापित। अब इसे बाहर निकालो। डिफ़ॉल्ट रूप से, प्रपत्र के लिए HTML कोड कुछ इस तरह दिखाई देगा:

 <dl class="zend_form"> <dt id="phone-label"> <label for="phone" class="required"></label> </dt> <dd id="phone-element"> <input type="text" name="phone" id="phone" value=""> <ul class="errors"><li> </li></ul> </dd> ... </dl> 

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

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

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

मुझे आपको रूपों के साथ काम करने के लिए सबसे सरल "साइकिल" का एक उदाहरण देना चाहिए, जो आपको संक्षिप्त रूप से और आसानी से फ़ॉर्म बनाने की अनुमति देता है।

फ़ॉर्म को कॉन्फ़िगर करना:

 $form = new UniversalForm(array( 'name' => array('label'=>'', 'required'=>true), 'email' => array('label'=>'', 'type'=>'email'), 'birthday' => array('label'=>' ', 'type'=>'date'), 'sex' => array('label'=>'', 'type'=>'choice', 'items'=>array('m'=>'', 'f'=>'')), 'code' => array('label'=>'', 'regExp'=>'/^\d{6}$/', 'regExpMessage'=>' ', 'value'=>'000000'), 'action' => array('type'=>'hidden', 'value'=>'updateInfo'), )); 

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

$ फॉर्म-> सेटफ्रॉमपोस्ट (); // POST से डेटा सेट करें
$ फार्म-> अमान्य (); // जांचें कि डेटा वैध है। यदि नहीं, तो त्रुटि संदेश स्थापित किया जाएगा कि फॉर्म सबमिशन स्क्रिप्ट आउटपुट करेगा।
$ डेटा = $ फॉर्म-> getValues ​​(); // मान प्राप्त करें
$ फॉर्म-> सेटवैल्यूज़ ($ डेटा); // फ़ील्ड मान सेट करें। यद्यपि कंस्ट्रक्टर में भ्रामक सरणी के माध्यम से ऐसा करना संभव है
$ फॉर्म-> रेंडर ('form.tpl.php'); // HTML उत्पन्न करें। यदि कोई टेम्पलेट निर्दिष्ट नहीं है, तो डिफ़ॉल्ट टेम्पलेट का उपयोग किया जाएगा।
$ फॉर्म-> रेंडरज (); // क्लाइंट सत्यापन PHP सत्यापनकर्ताओं की नकल करने वाले जावास्क्रिप्ट सत्यापनकर्ता उत्पन्न करें।

खैर, अब कुछ विधियाँ जो MVC के दृष्टिकोण से गलत हैं।
$ फॉर्म-> getSqlSet (); // SQL कोड का एक टुकड़ा लौटाता है
की तरह इस्तेमाल किया जा सकता है

$ sql = "अद्यतन खाता" सेट करें। $ फॉर्म-> getSqlSet ()। "WHERE आईडी = 777";

निम्नलिखित विधियों का उपयोग उसी उद्देश्य के लिए किया जाता है।
$ फॉर्म-> getSqlFieldsList ();
$ फॉर्म-> getSqlValuesList ();
हां, यह पूरी तरह से विहित रूप से सही निर्णय नहीं है। लेकिन तब खेतों के सेट को केवल फॉर्म कंस्ट्रक्टर में एक बार वर्णित किया जाना चाहिए। यदि यह बदल जाता है, तो सभी SQL क्वेरी स्वचालित रूप से बदल जाएंगी।

व्यवस्थापक

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

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

निष्कर्ष और छापें

जैसा कि आप समझते हैं, इस "सही" ढांचे ने मुझ पर बहुत अच्छा प्रभाव नहीं डाला।

लेकिन शायद यह है कि Zend Framwork अभी भी निम्नलिखित मामलों में महारत हासिल कर सकता है:
1. यदि आपके पास अपने आवेदन के लिए एक सहनीय रूपरेखा बनाने के लिए पर्याप्त अनुभव नहीं है।
2. यदि आप नहीं जानते कि एमवीसी के साथ कैसे काम करें, लेकिन इस विचारधारा का अनुभव करना चाहते हैं
3. यदि आपको ओओपी और विशिष्ट डिजाइन पैटर्न के आवेदन की अच्छी समझ नहीं है, तो Zend Framwork आपको कई उदाहरण दिखाएगा। वहां उन्होंने ओओपी का उपयोग किया जहां भी आवश्यकता हो और आवश्यक न हो।
4. इसके अलावा, Zend Framwork ठीक काम करेगा यदि आप एक साधारण एप्लिकेशन बनाते हैं, जिसका काम डेटाबेस से डेटा निकालने और स्क्रीन पर प्रदर्शित करने से अधिक है। उदाहरण के लिए, कुछ समाचार पोर्टल या उत्पाद कैटलॉग।

हालाँकि, यह अभी भी बेहतर हो सकता है कि आपकी आँखों को किसी अन्य ढांचे में बदल दिया जाए? ज़ेंड फ्रेमवर्क पहले से ही जमीन खोना शुरू कर चुका है, और संभवतः अच्छे कारण के लिए।

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

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

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

PS: अगर मैं किसी की "धार्मिक भावनाओं" को ठेस पहुंचाता हूं तो मैं पहले से माफी मांगता हूं।

PS2:लेख Zend फ्रेमवर्क के बारे में लिखा गया था। और यह एमवीसी के गुणों को चुनौती देने का प्रयास नहीं है, लेकिन दुर्भाग्य से कई लोगों ने इसे इस तरह से लिया।