एक साधारण वेबसाइट की प्रोग्रामिंग में अच्छा (साफ) आर्किटेक्चर क्या है, जैसे संपर्क पुस्तक?


28

जब मैं एक साधारण वेबसाइट बनाता हूं, जैसे एक संपर्क पुस्तक, जहां मैं संपर्क जोड़ सकता हूं, हटा सकता हूं और संपर्क अपडेट कर सकता हूं, तो मैं एक index.phpफाइल बनाता हूं जहां एक उपयोगकर्ता, यदि वह लॉग इन नहीं है, तो पासवर्ड दर्ज करने का अनुरोध किया जाता है और यदि वह सही पासवर्ड दर्ज करता है, तो वह एक सत्र सौंपा और संपर्कों के साथ कुछ चीजें कर सकते हैं।

मेरे पास दो फाइलें हैं:

  1. contacts.phpदिखाए जाने वाले HTML कोड के लिए पहला ( ) है। HTML कोड के ऊपर मैं दूसरी फाइल शामिल करता हूं और क्लास बनाता हूं।
  2. दूसरे ( contacts_class.php) में जोड़ने, हटाने और अपडेट करने के सभी तरीके शामिल हैं।

मुझे लगता है कि यह ठीक है, लेकिन जब यह एक बड़ी परियोजना को लागू करने की बात आती है, तो मुझे यह कैसे करना चाहिए? क्या मुझे हर पेज के लिए फोल्डर बनाने हैं और उनमें (जैसे ऊपर, HTML और क्लास) फाइलें डालनी हैं, और मुझे यह कैसे करना चाहिए? बड़ी परियोजनाओं के निर्माण के लिए एक अच्छी और साफ-सुथरी वास्तुकला क्या है जो हर दूसरे प्रोग्रामर को पूरी तरह से समझ में आएगी?

जवाबों:


67

आपने एक बहुत ही रोचक और मौलिक प्रश्न उठाया। बड़े पैमाने पर परियोजना वास्तुकला और फ़ोल्डर संरचना संगठन (जो वास्तुकला के लिए माध्यमिक है) से संबंधित प्रश्न।

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

एमवीसी का अर्थ है मॉडल, व्यू, कंट्रोलर। आप इन दृष्टिकोणों को कॉल कर सकते हैं जो आपको पसंद हैं - एमवीसी, एचएमवीसी, एमवीपी। सार आपके सिस्टम के व्यक्तिगत घटकों को अलग करना है। "नियंत्रक" "मॉडल" से डेटा को पुनर्प्राप्त करता है और उन्हें "व्यू" पर भेजता है, जो अंतिम HTML का प्रतिपादन करता है। आप पहले से ही अपने में "वी" और अपने में contacts.php"एमसी" लागू कर चुके हैं contacts_class.php। तो आपने मॉडल और नियंत्रक से दृश्य को अलग कर दिया है। अब आप आसानी से अन्य भागों को छोड़कर अपना "दृश्य" बदल सकते हैं।

मैं आपको एमवीसी, एमवीपी या जो भी "एमवी" पैटर्न का आँख बंद करके अनुसरण करने का सुझाव नहीं दे रहा हूं। यह उपयुक्तता, प्रभावकारिता और स्वाद की बात है।

आम डायनेमिक वेबसाइट एप्लिकेशन में ऐसे घटक शामिल हो सकते हैं जैसे:

  • प्रवेश बिंदु, कहते हैं index.php
  • सहायक पुस्तकालय / कक्षाएं
  • अनुरोध राउटर
  • मॉड्यूल, घटक या नियंत्रक
  • टेम्पलेट इंजन या शायद एकल विचार

वास्तविक वेब एप्लिकेशन में ईवेंट हैंडलर, ईवेंट डिस्पैचर और हुक जैसे अन्य घटक शामिल हो सकते हैं, लेकिन ये वास्तव में बारीकियां हैं। खैर, मुझे इसे उस तरह से प्रस्तुत करने दें जैसा मैं इसे प्रस्तुत करना चाहता हूं:

ऑपरेशन रूटीन आरेख

सामान्य ढांचा संचालन दिनचर्या निम्नानुसार है:

  1. ब्राउज़र अनुरोध सीधे प्रवेश बिंदु निष्पादन योग्य / स्क्रिप्ट ( index.php) के लिए भेजा जाता है ।
  2. प्रवेश बिंदु लिपि सहायक पुस्तकालयों, कक्षाओं को लोड करती है और हमारे प्रोग्रामिंग वातावरण के कुछ और आरंभीकरण करती है।
  3. URL अनुरोध राउटर उदाहरण के लिए दिया गया है। यह चरण 2 चरण का हिस्सा हो सकता है।
  4. अनुरोध राउटर URL को पार्स करता है और एक विशेष घटक, मॉड्यूल या नियंत्रक को ऑपरेशन भेजता है।
  5. घटक (या नियंत्रक) रूट किए गए अनुरोध को संसाधित करता है और डेटा को प्रदान किए जाने वाले दृश्य में भेजता है।

इसी प्रोजेक्ट फ़ोल्डर संरचना को आरेख में दिखाया गया है।

मैं आपको यह जांचने का सुझाव दूंगा कि अन्य ढांचे कैसे लागू किए जाते हैं। अनुशंसित सीएमएस / चौखटे के साथ शुरू करने के लिए कोडिनगर, ओपनकार्ट, जुमला 1.5 और टैंगो सीएमएस हैं।


3
आपने उस छवि को बनाने के लिए क्या उपयोग किया? बहुत बढ़िया जवाब!
मार्क टोमलिन

3
मेरे उत्तर के सकारात्मक मूल्यांकन के लिए धन्यवाद! मैं वास्तव में इसकी प्रशंसा करता हूँ! यह उत्तर पूरी तरह से विभिन्न ओपन सोर्स वेब एप्लिकेशन फ्रेमवर्क के विश्लेषण का परिणाम है, जो मैंने पहले खुद के लिए आयोजित किया था। उन लोगों के लिए जो छवि बनाने में रुचि रखते थे और सॉफ्टवेयर का उपयोग किया जा रहा था, छवि को इंकस्केप 0.48 और जीआईएमपी 2.6.10 का उपयोग करके बनाया गया था। उस के साथ कोई समस्या नहीं। बस दो परतों का उपयोग करें: पाठ के साथ आयतों के लिए एक, छाया के लिए एक (धुंधला काली आयतें)। मुझे लगता है कि आप बाकी समझते हैं?

एक प्रश्न, आप 'संपर्क' नियंत्रकों को 3 फाइलों में अलग क्यों करेंगे। क्या उन्हें सिर्फ एक कॉन्टैक्टसेफपी में जोड़ना साफ नहीं होगा। आपको बस राउटर से एक एक्शन पैरामीटर में पास होना है। जब तक आपका दृष्टिकोण अस्थायी और तर्क को प्रत्येक क्रिया के लिए एक फ़ाइल में नहीं मिलाता है, तब तक 'संपर्कों' के विचारों के लिए यही कहा जा सकता है। मैं PHP में ज्यादा देव नहीं करता (मैं ज्यादातर पायथन में काम करता हूं) लेकिन मुझे आशा है कि सभी ढांचे इस दृष्टिकोण का उपयोग नहीं करते हैं। अन्यथा महान राइटअप के लिए +1।
इवान प्लाइस

2

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

कृपया ध्यान रखें कि पुस्तक पहले से ही पुरानी है (आईटी भूमि में) लेकिन कई सिद्धांत अभी भी मान्य हैं या आपको उनसे सीखना चाहिए। (वह समझ में आया था?)

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


2

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

दूसरा, अपनी वास्तुकला की जांच करने का एक बहुत आसान तरीका यूनिट टेस्ट लिखने की कोशिश कर रहा है। उदाहरण के लिए यदि क्लास "कार्ड डेक" में एक "फेरबदल ()" विधि है, तो आपको पूर्वनिर्धारित आकार का कार्ड डेक बनाने में सक्षम होना चाहिए (अर्थात 5 कार्ड 1,2,3,4,5), कॉल फेरबदल और एक में सत्यापित करें आसान तरीका परिणाम (आईडी 1,4,2,5,3)

आप संपूर्ण प्रोजेक्ट क्लासेस को बिना इंस्टेंट किए इसे करने में सक्षम होना चाहिए, और परीक्षण को पढ़ने के लिए बहुत साफ होना चाहिए।

यदि आप ऐसा नहीं कर सकते हैं, तो आपको कक्षाओं के बीच परतों को जोड़ना होगा, उनका पुनर्गठन करना चाहिए, जब तक कि आपको इसे करने का एक आसान तरीका न मिल जाए।

फिर अपनी परियोजना के सभी मुख्य वर्गों के लिए इस चरण को दोहराएं।

अंतिम लेकिन कम से कम नहीं: एक अच्छा आर्कीटेक्चर न-सो-कोर क्लासेस पर "आलसी" हो सकता है (यह अर्थव्यवस्था का मामला है: बहुत अच्छी तरह से डिज़ाइन की गई चीजों की कीमत वास्तविक दुनिया में बहुत अधिक है)।


1

बड़े पैमाने पर परियोजनाओं के लिए एक अच्छी वास्तुकला एमवीसी (मॉडल व्यू कंट्रोलर) है: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

क्या अन्य प्रोग्रामर यह समझ पाएंगे कि यह पूरी तरह से एक अलग मामला है। MVC जटिल हो सकता है और कभी-कभी छोटी परियोजनाओं के लिए ओवरकिल हो जाता है। इसका एक लाभ यह है कि यह आसानी से तराजू है।


यह एक पैटर्न है, न कि एक वास्तुकला।
अर्ध्द

मेरा तर्क है कि वे इस मामले में उसी में से एक हैं। आप दोनों में अंतर कैसे करेंगे? इसके अलावा, मेरे द्वारा पोस्ट किए गए विकिपीडिया पृष्ठ की पहली पंक्ति पढ़ें।
क्रिस लाप्लांट

1
मेरे अनुभव से, एमवीसी जटिल नहीं है और छोटी परियोजनाओं में भी बहुत उपयोगी है। मैं हालांकि सहमत हूं, कि यह एक पैटर्न है न कि एक पूरी वास्तुकला।
डैनी वारोड

एमवीसी एक पैटर्न है, न कि आर्किटेक्चर प्रति एसई, लेकिन इसे आर्किटेक्चर का हिस्सा माना जा सकता है। और यह सब के बाद जटिल नहीं है।

1

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

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

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

इन दो टैक्सोनॉमीज़ को पहचानने के बाद, मैं प्रत्येक स्तरीय की पहचान करते हुए शीर्ष स्तर के फ़ोल्डर बनाऊंगा। (यूआई, नियंत्रक, सेवा, बर्तन आदि)। प्रत्येक उच्च स्तरीय फ़ोल्डर्स के तहत, मैं कार्यक्षमता या संसाधन (प्रोजेक्ट - / EditProject - / SearchProject आदि) के आधार पर बच्चे के फ़ोल्डर बनाऊंगा। आदर्श रूप से कार्यात्मक वर्गीकरण बहुस्तरीय होगा।


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

1

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

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


1

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

अन्य चरम स्थिति के लिए एक अच्छी भावना पाने के लिए सीसाइड पर एक नज़र डालें


1

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

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


0

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

  1. यह इकाई परीक्षण किया जा सकता है
  2. चिंताओ का विभाजन
  3. कई लोग बिना किसी टकराव के इस पर काम कर सकेंगे।
  4. इसे ज्यादा समस्या के बिना बढ़ाया जा सकता है
  5. यह स्केलेबल हो सकता है। जब बड़ी परियोजनाओं की बात आती है तो स्केलेबिलिटी एक बड़ी चिंता होगी। चेकआउट कोहना फ्रेमवर्क, जो अच्छी तरह से लिखा गया है और इसे बहुत अच्छी तरह से स्केल किया जा सकता है

0

इससे पहले कि आप कोई भी प्रोडक्शन कोड लिखें उसे 2 सप्ताह (रात :) और इस पुस्तक को पढ़ें। यह प्रोग्रामिंग आर्किटेक्चर, प्रैटिस और पैकिगिंग के बारे में लंबे समय तक आपके मन को बदल देगा।

फुर्तीला सिद्धांत, पैटर्न और अभ्यास C # प्रेंटिस हॉल द्वारा

उदाहरण C # में हैं, लेकिन उन्हें पढ़ना आसान है, यह सही कोड सिंटैक्स कैसे लिखना है, यह प्रोग्रामर के रूप में सोचने के बारे में नहीं है।

मैं वादा करता हूँ कि आप इसे अपने पीसी पर अपने सबसे प्रशंसनीय स्थान पर सहेज लेंगे और आप आश्चर्यचकित होंगे कि आप इसे जाने बिना प्रोग्रामिंग कर रहे हैं। यह आपकी सोच को बदल देगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.