कोड डिज़ाइन और संरचना

Question

इसे हाल ही में हाइलाइट किया गया है (मेरे पिछले प्रश्नों में) जिस तरह से मैंने वेब अनुप्रयोगों को डिज़ाइन किया है वह आदर्श नहीं है।

निम्नलिखित पर विचार करें। मैं एक बहु-उपयोगकर्ता वेबसाइट पर काम कर रहा हूं जिसमें प्रोफाइल और मंच और समर्थन टिकट सहित कई अलग-अलग वर्ग हैं। संरचना इस प्रकार है:

एक मुख्य पृष्ठ में अन्य सभी पृष्ठों शामिल या * required_once * हम इसे home.php फोन करता हूँ कर रहे हैं।

में home.php, पहली बातें भरी हुई में से एक router.php है, यह हर एक $ _GET और $ _POST कि उपयोगकर्ता संभवतः उत्पादन कर सकता है, और हर रूप को संभालती है और इस प्रक्रिया के माध्यम से एक सॉर्ट की गई है मुख्य चर $ data_process कहा जाता है। Router.php अनिवार्य रूप से केवल एक विशाल स्विच() $ data_process के लिए कथन है। यह सभी डेटा पार्स करता है और परिणाम देता है।

अगला शामिल header.php है, जो न केवल पृष्ठ के लिए आवश्यक चर को संसाधित करेगा, बल्कि हेडर भी स्थापित करेगा और यह तय करेगा कि वहां क्या दिखाया जा रहा है, उदाहरण के लिए मेनू, उपयोगकर्ता जानकारी, और वर्तमान में देखे जाने वाले पृष्ठ के बारे में जानकारी (यानी होम> सहायता> टिकट देखें)।

फिर पृष्ठ $ पृष्ठ चर के अनुसार लोड किया गया है। एक सरल शामिल हैं।

फिर footer.php, फिर बंद करें।

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

पीएस - क्या कोई भी मेरे लिए PHP, MySQL और डिज़ाइन संरचना की व्याख्या करने वाली पुस्तकों को पढ़ने में आसान है?

Answer 1

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

Answer 2

वहाँ "अच्छा डिजाइन" के पास कोई धर्मवैधानिक परिभाषा है - सबसे अच्छा आप देखेंगे कि आपके डिजाइन इष्टतम तरीके से अपने परियोजना पर विभिन्न बलों को संतुलित करता है के लिए आशा कर सकते हैं, अपनी परियोजना पर बलों रख-रखाव, प्रदर्शन, scalability हो सकता है, विस्तारशीलता - क्लासिक गैर-कार्यात्मक आवश्यकताओं - लेकिन खोज इंजन अनुकूलन, मानक अनुपालन और अभिगम्यता जैसी चीजें (विशेष रूप से वेब परियोजनाओं पर लागू होने वाली चीजें)।

यदि आपके सभी यूआरएल फॉर्म हैं "www.mysite.com/home.php?action=getDetails & productID = 123", तो आपकी खोज इंजन मित्रता बहुत कम है। अर्थपूर्ण यूआरएल होना बेहतर है - "www.mysite.com/products/DesktopPc/details.php"। आप अपने वर्तमान डिजाइन में चालाक। Htaccess चालबाजी के माध्यम से इसे प्राप्त कर सकते हैं।

एक रखरखाव बिंदु से, आपके डिजाइन में कुछ समस्याएं हैं। यदि मैंने इसे सही ढंग से समझा है, तो साइट पर एक नया पृष्ठ जोड़ने के लिए आपको कई अलग-अलग स्रोत फ़ाइलों में कोड को संशोधित करने की आवश्यकता है - router.php (आपका विशाल स्विच स्टेटमेंट), पृष्ठ स्वयं, और शायद header.php भी। यह इंगित करता है कि कोड कसकर coupled है। विशाल स्विच स्टेटमेंट को संशोधित करना मनोरंजक बग के संभावित स्रोत की तरह लगता है, और राउटर और हेडर का संयोजन, चर को जोड़ना, साथ ही वास्तविक पृष्ठ स्वयं थोड़ा नाजुक लगता है। यह ठीक है अगर आप परियोजना पर काम कर रहे एकमात्र व्यक्ति हैं, और आप लंबी अवधि के लिए आसपास जा रहे हैं; यदि ऐसा नहीं है, तो ऑफ-द-शेल्फ फ्रेमवर्क का उपयोग करना बेहतर है (एमवीसी वर्तमान पसंदीदा है; ज़ेंड, सिम्फनी और केक सभी PHP में यह अच्छी तरह से करते हैं) क्योंकि आप दस्तावेज़ों पर नए डेवलपर्स को इंगित कर सकते हैं और उम्मीद करते हैं कि उन्हें गति पर।

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

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

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

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

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