मॉड्यूल / प्लगइन्स का समर्थन करते हुए आप अपने MVC फ्रेमवर्क को कैसे व्यवस्थित करते हैं? [बन्द है]

Question

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

मानक एमवीसी

/controller
/model
/view

समस्या: संबंधित घटकों (मंच, ब्लॉग, उपयोगकर्ता, आदि) का कोई पृथक्करण नहीं।

मॉड्यूलर एमवीसी

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

मॉड्यूल-आधारित प्रणाली को चुनना आपको एक समस्या के साथ छोड़ देता है।

• लंबे नाम (फोरम_मॉडल_फोरम = फोरम / मॉडल / फोरम। एफपी) (जैसे Zend)
• फाइल सिस्टम is_file()यह पता लगाने के लिए खोज करता है कि फोरम मॉडल में कौन सा फ़ोल्डर है? (जैसा कोहना)

क्या उनकी कोई अन्य MVC संरचनाएं हैं जो अलग-अलग मॉड्यूल को अलग करने की कोशिश करते समय अच्छी तरह से काम करती हैं? क्या इन संरचनाओं से लाभ हैं जो मुझे याद आ रहे हैं?

Comments

मैं यह भी जोड़ना चाहूंगा कि मुझे ऐसा ढांचा चाहिए जो PSR-0 के अनुरूप हो ताकि जरूरत पड़ने पर मैं Zend और Doctrine जैसे पुस्तकालयों का भी उपयोग कर सकूं।

— Xeoncross

Answer 1

प्रयत्न:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

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

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

इससे यह स्पष्ट होना चाहिए कि आपके पास कई ग्राहक हो सकते हैं, सभी एक तरह से या किसी अन्य, एक मॉडल के साथ बातचीत कर सकते हैं।

Comments

+1 क्योंकि मैं एमवीसी घटकों के आपके स्पष्टीकरण से पूरी तरह सहमत हूं और उन्हें कैसे काम करना चाहिए। हालांकि, एक मॉड्यूल का मुद्दा यह है कि आप अन्य उपयोगकर्ताओं द्वारा बनाए गए मॉड्यूल को आयात कर सकते हैं ताकि मॉड्यूल पथ के बाहर मॉडल होने से यह कम "ड्रैग-एंड-ड्रॉप" बनाता है। हालाँकि, आपकी विधि उन अनुप्रयोगों के लिए बहुत मायने रखती है जो बाहरी प्लगइन्स या मॉड्यूल का उपयोग नहीं करते हैं।

— Xeoncross

@ Xeoncross यह सच है, मैं वास्तव में यहाँ खाते में पुन: प्रयोज्य नहीं लिया है। यदि यह एक आवश्यकता है, तो आप वास्तव में एक कदम आगे जा सकते हैं और उदाहरण के लिए एक 'उपयोगकर्ता' मॉड्यूल है जो उपयोगकर्ता मॉडल को इसके नियंत्रक के साथ समूहित करता है, और एक ब्लॉग मॉड्यूल है जो BlogPost और टिप्पणी मॉडल को इसके नियंत्रकों के साथ समूहित करता है। हमेशा की तरह: यह संदर्भ पर निर्भर करता है :-)

— मथियास वेरस

Answer 2

;)

मुझे संयुक्त रूप से MVC / HMVC फ्रेमवर्क के लिए सबसे अच्छी संरचना मिली। मुख्य के लिए आपको आधार नियंत्रक / मॉडल / विचार का उपयोग करने की आवश्यकता है ... लेकिन पाठ्यक्रम मॉड्यूल के व्यक्तिगत घटकों के लिए ...

तो मेरे MVC / HMVC ढांचे की संरचना इस तरह दिखती है:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

इसके अलावा, अगर मुझे जरूरत है कि मैं मॉड्यूल पुस्तकालयों, i18n या सहायकों में जोड़ दूं।

नामकरण सम्मेलन आसान है, नियंत्रकों और मॉडलों के लिए मैं प्रत्यय _Controller और _Model जोड़ता हूं। मॉड्यूल से नियंत्रक और मॉडल के लिए, मैं पूर्व के लिए मॉड्यूल नाम के साथ एक उपसर्ग भी जोड़ता हूं। कंट्रोलर प्रोफाइल इन मॉड्यूल यूजर का नाम User_Profile_Controller होगा।

तो यह आप के लिए क्या जरूरत है खोजने के लिए आसान और तेज verry है।

Answer 3

समस्या: लंबे नाम (Forum_Model_Forum)

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

फाइल सिस्टम सर्च (किस फोल्डर में फोरम मॉडल है?)।

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

यहाँ एक उदाहरण है, मान लीजिए कि मंच घटक का उपयोग किया जाना है:

जानकारी:

• घटक-नाम: मंच

• नियंत्रक-नाम: सूचकांक

  $ नियंत्रक_पथ = आधार। 'मापांक/' । $ घटक_नाम। '/ नियंत्रक /'। $ कंट्रोलर_नाम। '.Php';

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

Comments

सचमुच, बैक-एंड क्लाइंट-साइड ऐप की तरह नहीं हैं, जिन्हें जल्दी से शुरू करने की आवश्यकता होती है, वे रन समय को ठीक से कॉन्फ़िगर करने के लिए आवश्यक समय ले सकते हैं। अच्छी बात।

— पैट्रिक ह्यूजेस

Answer 4

मेरे पास उन वेबसाइटों के साथ काम है जो पहले "मानक एमवीसी" के साथ शुरू हुए थे, लेकिन अंततः "मॉड्यूलर एमवीसी" बन गए।

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

Answer 5

मैं वास्तव में स्वयं एक फ्रेमवर्क पर काम कर रहा हूं और मॉड्यूल आधारित और फ्री-फॉर्म निर्देशिका संरचना दोनों के संयोजन का उपयोग करता हूं। फ्रेमवर्क का उपयोग करके साइट कोड के लिए मेरी डिफ़ॉल्ट संरचना है:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

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

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

Answer 6

इसका उत्तर PSR-0 प्रस्ताव द्वारा निर्धारित किया गया है जिसे सभी बड़ी प्रणालियाँ अनुकूल बनाना शुरू कर रही हैं, या अब अपना चुकी हैं।

संरचना है:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

इसका मतलब है कि कुछ भी नहीं है जो आप लंबे फ़ाइल नामों को ठीक करने के लिए कर सकते हैं:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

इसका मतलब यह भी है कि आपको सभी लोअरकेस के बजाय डंब मिश्रित-केस फ़ाइलों का उपयोग करना होगा (यदि आप तृतीय-पक्ष लाइब्रेरी नहीं करेंगे)।

Answer 7

Mathiases घोल बहुत अच्छा बनाता है और अपने फ़ोल्डर संरचना का उपयोग करने से प्लग करने योग्य सामग्री होने से नहीं रोका जा सकता है, उदाहरण के लिए एक स्वतंत्र / गैलरी को जोड़ना / इसे देख सकते हैं

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

यदि आवश्यक हो तो अब हमारे पास एक साझा "मॉडल" और स्वतंत्र हैं