क्या PHP अनुप्रयोग डिजाइन/डिज़ाइन पैटर्न आप उपयोग करते हैं?

Question

कृपया मेरे साथ PHP में उपयोग के लिए अपने पसंदीदा एप्लिकेशन डिज़ाइन/डिज़ाइन पैटर्न साझा करें। कुछ बातें मैं चाहूँगा पता करने के लिए:

• कैसे अपने फ़ोल्डर्स
• तैयार कर रहे हैं आप अपने पीएचपी अनुप्रयोगों में वस्तु oritentation का उपयोग
• आप CRUD, पृष्ठांकन, या किसी से निपटने का एक मानक तरीका है अन्य आम कार्यों?
• आप दोहराव कोड का उपयोग करने से कैसे बचते हैं? पुस्तकालयों/आम कोड साझा करने आदि के लिए आपका दृष्टिकोण क्या है?
• आप किस तरीके से अपना कोड अधिक सुरुचिपूर्ण बना सकते हैं?

आपको इनमें से सभी का जवाब देने की आवश्यकता नहीं है, इनमें से कुछ का जवाब देना या इनमें से कुछ सहायक होंगे।

कारण मैं यह पूछ रहा हूं, क्योंकि मैं PHP में दोहराव, बदसूरत कोड लिखने से बहुत थक गया हूं और मैं अपनी फ्रीलांसिंग परियोजनाओं के लिए एक छोटा सा ढांचा बनाना चाहता हूं जो प्रोग्रामिंग को आसान बना देगा और मुझे ध्यान केंद्रित करने देगी फॉर्म प्रमाणीकरण, अंकन, और अन्य सांसारिक गतिविधियों के बजाय चुनौतीपूर्ण/व्यावसायिक कार्य जो PHP

में प्रोग्रामिंग कार्य का 80% बनाते हैं सभी राय की सराहना की!

Answer 1

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

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

आप अपने खुद के लिए, यहाँ कुछ चीजें मैं अपने खुद के अनुभव से सिफारिश करेंगे कर रहे हैं रोल करने का फैसला करते हैं:

• सुरक्षा आपका शीर्ष प्राथमिकता करें - यदि आप एक डेटा का उपयोग परत लिखते हैं, उपयोग बाध्य पैरामीटर। यदि आप एक फॉर्म कक्षा लिखते हैं, तो सीएसआरएफ और एक्सएसएस के खिलाफ सुरक्षा करें। अपने अपवादों को पकड़ें और अपनी त्रुटियों को संभाल लें। सुनिश्चित करें कि आपका PHP वातावरण सुरक्षित है। अपने स्वयं के एन्क्रिप्शन एल्गोरिदम के साथ आने का प्रयास न करें। यदि आप सुरक्षा पर पर ध्यान केंद्रित नहीं करते हैं, तो लिखने के लायक नहीं है, यह स्वयं का ढांचा है।
• अपने कोड पर टिप्पणी करें - आपको टिप्पणियों की आवश्यकता होगी ताकि आपको यह याद रखने में मदद मिल सके कि आपका कोड थोड़ी देर बाद काम करता है। मैं आमतौर पर पाते हैं कि डॉकब्लॉक टिप्पणियां पर्याप्त से अधिक हैं। इसके अलावा, टिप्पणी आपने कुछ क्यों किया, आपने क्या किया। यदि आपको को समझाने की आवश्यकता है, तो आप रिफैक्टर करना चाहेंगे।
• एकल जिम्मेदारी वर्ग और तरीके - अपने वर्गों और तरीकों में से अधिकांश एक बात और केवल एक बात करना चाहिए। विशेष रूप से डेटाबेस के साथ के लिए देखें - आपका पेजिनेशन क्लास पर आपके डेटा एक्सेस ऑब्जेक्ट पर निर्भर नहीं होना चाहिए, न ही लगभग किसी भी अन्य (निम्न-स्तर) वर्ग को होना चाहिए।
• यूनिट टेस्ट - अपने तरीकों में से प्रत्येक को एक ही चीज़ खाता है तो यह अब तक आसान उन्हें परीक्षण करने और यह होगा बेहतर कोड में परिणाम के लिए होना चाहिए।परीक्षण पहले लिखें, फिर परीक्षण पास करने के लिए कोड लिखें। इससे आपको बिना किसी ब्रेकिंग के बाद बाद में रिफैक्टर करने की स्वतंत्रता भी मिल जाएगी।
• सार इसी वर्ग - आप एक से अधिक वर्ग कि समान काम करता है है, तो एक माता पिता वर्ग कक्षाएं के बीच समानता का उपयोग करता है बनाने और इसे विस्तार।
• प्रतिनिधि और modularize - आप कर रहे हैं एक सत्यापन प्रणाली लेखन, कुछ सुपर सत्यापन कक्षा में एक पद्धति के रूप में प्रत्येक सत्यापनकर्ता शामिल नहीं हैं (और संभावना है कि आप शायद होगा कर रहे हैं)। उन्हें व्यक्तिगत कक्षाओं में अलग करें और उन्हें आवश्यकतानुसार कॉल करें। यह कई क्षेत्रों में लागू किया जा सकता है: फ़िल्टर, भाषाएं, एल्गोरिदम, सत्यापनकर्ता, और इसी तरह।
• सुरक्षित रखें और निजीकरण - सबसे मामलों में, यह नहीं बल्कि वर्ग चर के सीधी पहुंच देने से गेटर और सेटर तरीकों का उपयोग करने के लिए बेहतर है।
• अनुरूप एपीआई - यदि आप एक प्रस्तुत करना है, तो() विधि और एक ड्रॉ() विधि कि विभिन्न कक्षाओं में ही बातें करते हैं, एक चुनना है और सभी वर्गों में यह साथ जाना। के पैरामीटर को उसी पैरामीटर का उपयोग करने वाले विधियों के पैरामीटर के समान रखें। एक सतत एपीआई एक आसान एपीआई है।
• याद रखें Autoloading - वर्ग नाम एक छोटे से भद्दा और लंबे प्राप्त कर सकते हैं, लेकिन जिस तरह से Zend नाम वर्गों और निर्देशिका बहुत आसान बना देता है Autoloading आयोजन करता है। अद्यतन: PHP 5.3 के रूप में, आपको नामस्थानों का उपयोग शुरू करना चाहिए।
• कभी भी गूंज या मुद्रित करें - इसे वापसी मूल्य के रूप में दें और उपयोगकर्ता को यह तय करने दें कि इसे प्रतिबिंबित किया जाना चाहिए या नहीं। कई बार आप किसी अन्य विधि के पैरामीटर के रूप में वापसी मान का उपयोग करेंगे।
• दुनिया की समस्याओं को हल करने का प्रयास न करें - अपना पहला हल करें। यदि आपको अभी एक सुविधा की आवश्यकता नहीं है, संख्या या दिनांक या मुद्रा को स्थानांतरित करने के लिए कक्षा की तरह, इसे लिखें नहीं। प्रतीक्षा करें जब तक आपको इसकी आवश्यकता न हो।
• को पूर्ववत न करें - कुछ अपने फ्रेम के साथ सरल अनुप्रयोगों को ठीक ट्यून करने से पहले बनाएं। अन्यथा, आप कुछ भी उत्पादक पर समय व्यतीत कर सकते हैं।
• उपयोग स्रोत नियंत्रण - यदि आप एक कृति बनाने अनगिनत घंटे खर्च करते हैं, तो जोखिम नहीं है यह खो रहा है।

Answer 2

मैं लगभग एक टूटी हुई रिकॉर्ड की तरह लग रहा है, लेकिन मैं सुझाव है कि आप दो कारणों के लिए सामान्य चौखटे में से कुछ पर एक नज़र डालें:

1. यहां तक ​​कि अगर आप एक का उपयोग करने के लिए नहीं चुनते हैं, उनमें से कुछ हैं बहुत अच्छी तरह से लिखा और बहुत अच्छी तरह से डिजाइन किया गया। मुझे विशेष रूप से ज़ेंड फ्रेमवर्क पसंद है लेकिन मैं उस पर एक सेकंड में वापस आऊंगा।
2. खुद से पूछें कि आप पहिया को फिर से क्यों बदल रहे हैं। क्या आपको सचमुच लगता है कि आप उसी डिजाइन की समस्याओं को समझते हैं, जो हर किसी के पीछे समुदाय से कहीं ज्यादा बेहतर है (यहां पसंद का ढांचा डालने) ताकि स्क्रैच से कुछ लिखने को सही ठहराया जा सके? जिसने मूल रूप से कई ढांचे को देखा और फैसला किया कि वे बहुत बड़े थे, एक सीखने की अवस्था या बहुत अधिक उपरांत प्रस्तुत किया और खुद को विकसित किया, मैं आपको बता सकता हूं कि खरोंच से खुद को लिखना एक बड़ा दर्द है यदि आप बस एक मौजूदा एक का उपयोग कर सकते हैं जिसे आसानी से बढ़ाया जा सकता है।

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

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

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

Answer 3

मैंने अपनी अधिकांश PHP पद्धति here समझाया है।

लेकिन आजकल, मैं बस हर जगह Django का उपयोग कर सकता हूं।

Answer 4

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

मैंने Joomla के साथ कुछ परियोजनाएं की हैं, जो वास्तव में एक सीएमएस है लेकिन यह ग्राहकों को सामग्री पर बहुत अधिक नियंत्रण प्रदान करती है।

अंततः मैं अपनी परियोजनाओं के लिए एक वास्तविक ढांचे का उपयोग करने पर बस गया हूं। मैं symfony का उपयोग कर रहा हूं, जो रेल द्वारा प्रेरित है और बहुत अच्छी तरह से प्रलेखित है, लेकिन मैंने सुना है cakePHP और ZendFramework भी बहुत अच्छे हैं।

Answer 5

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

* How your folders are designed 

CodeIgniter (या उस बात के लिए किसी भी ढांचे), प्रत्येक अपने स्वयं के फ़ोल्डर के साथ देखा गया, मॉडल, और नियंत्रकों में अपने तर्क अलग करती है।

* Do you have a standard way of dealing with CRUD, pagination, or any other common tasks? 

सीआई एक पृष्ठांकन पुस्तकालय है, और यह एक वस्तु उन्मुख रास्ता (ORM) में अपने CRUD कॉल लपेटकर के लिए DataMapper की तरह 3 पार्टी पुस्तकालयों है।

* What are ways in which you can make your code more elegant? 

मॉडल, दृश्य और नियंत्रक का पृथक्करण बहुत ही सुरुचिपूर्ण कोड के लिए बनाता है।

Answer 6

(2 सवाल मैं जवाब नहीं दिया काफी जब ढांचे का उपयोग कर लगाए गए) मैं Zend फ्रेमवर्क, जो काफी फ़ोल्डर लेआउट और OOP (MVC प्रतिमान) को परिभाषित करता है का उपयोग करें। सामान्य कार्यों के लिए, उदाहरण के लिए पेजिनेशन के लिए मैं Zend_Paginator का उपयोग करता हूं (मेरे मॉडल वर्ग Zend_Paginator_Adapter_Interface लागू करते हैं), सत्यापन के लिए मैं Zend_Validate कक्षाओं आदि का उपयोग करता हूं। धन्यवाद, मैं पहिया को पुनर्निर्मित करने के बजाय व्यवसाय तर्क पर पूरी तरह से ध्यान केंद्रित कर सकता हूं।

Answer 7

मुझे लगता है कि बहुत सारे PHP डेवलपर्स ने मेरे लिए एक समान मार्ग का पालन किया है: छोटी स्क्रिप्ट -> प्रक्रियात्मक/इनलाइन-कोड -> संभवतः टेम्पलेटिंग -> ओओपी -> फिर एक ढांचा। मुझे लगता है कि एक PHP डेवलपर के लिए वर्तमान संस्करण के साथ उपलब्ध सुविधाओं से मेल खाने के लिए PHP के साथ "बड़े हो गए" सीखने के लिए काफी आम हो सकता है।

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

अधिकांश परियोजनाओं के लिए (जहां तेजी से विकास और पोर्टेबल कोड प्राथमिकताएं हैं) मैं केक का उपयोग करता हूं, हालांकि हल्के वजन वाले ऐप्स (जिसे मैंने हाल ही में विकसित किया था Good Baad) जो आप तेजी से चलाना चाहते हैं (कम स्पेक हार्डवेयर पर) बड़े ढांचे में से एक की कार्यक्षमता द्वारा जोड़ा गया थोक/वजन की आवश्यकता नहीं है, मैं अपने No Framework PHP MVC framework पर रasmस लेरडोर्फ़ के लेख को पढ़ने की अनुशंसा करता हूं।

मूल रूप से यदि आप एक वास्तविक ऑब्जेक्ट उन्मुख भाषा के बाद हैं जो सुंदर कोड और सर्वोत्तम डिजाइन प्रथाओं को प्रोत्साहित करता है तो PHP हमेशा रूबी पायथन और सी # की पसंद को खोने जा रहा है। लेकिन, PHP की ताकतें हैं उदा। एक templating भाषा की आवश्यकता नहीं है (यह एक है), PHP बहुत तेजी से और सस्ता चल सकता है और सभी अनुप्रयोगों के लिए एक बड़े ढांचे के वजन की जरूरत नहीं है।

मैं एक डिजाइन पैटर्न को अपनाने को प्रोत्साहित करता हूं जो एमवीसी जैसे डिजाइन पैटर्न की प्रबंधनीयता लेता है और इसे PHP की शक्तियों के साथ जोड़ता है।

Answer 8

Zend Framework और Doctrine का उपयोग करना, मेरी फ़ोल्डर संरचना आम तौर पर इस तरह दिखता है:

root 
    app 
    config   (db config, routing config, misc config) 
    doctrine  (fixtures, migrations, generated stuff, etc) 
    lib 
    logs 
    models   (doctrine models) 
    modules  (zend mvc modules) 
    bootstrap.php 
    docs    (db diagrams, specs, coding standards, various docs) 
    pub    (web root) 
    tests 
    tools   (console tools, i.e. doctrine-cli) 
    vendor   (zend and doctrine libraries, preferably as svn-externals) 

Answer 9

मैं थोड़ी देर के लिए अपनी खुद की सामग्री लिखने के आसपास गड़बड़ कर रहा हूं और हर बार मैं इसे पूरी तरह खत्म करने के लिए कभी भी नहीं मिल सकता क्योंकि मैं कुछ पर अटक जाता हूं।

और फिर वह हिस्सा आता है जहां मैं यह महसूस करने आया हूं कि मैं कुछ सही कर रहा हूं या नहीं।

और जैसा कि मैंने खुद को भीड़ के साथ जाने के लिए छोड़ दिया है: ज़ेंड।

मैंने दूसरों को देखा लेकिन ऐसा लगता है कि ज़ेंड थोड़ी देर के आसपास रहा है और वे अपनी चीजें जानते हैं।

एमवीसी भी मैं जिस तरह से लिख रहा हूं उसके साथ आगे बढ़ रहा हूं।