RVC को MVC डिज़ाइन पैटर्न के मूल रूप में देखना सबसे अच्छा विचार नहीं हो सकता है। कहा फ्रेमवर्क कुछ अंतर्निहित कमियों के साथ बनाया गया था (मैं एक अलग पोस्ट में इस पर विस्तृत रूप से विस्तार किया गया है ) और समुदाय ने अब केवल नतीजों को संबोधित करना शुरू कर दिया है। आप पहले प्रमुख कदम के रूप में DataMapper2 विकास को देख सकते हैं ।
कुछ सिद्धांत
उस सलाह को देने वाले लोग काफी आम गलत धारणा से पीड़ित हैं। तो मुझे इसे साफ करने से शुरू करें: मॉडल, आधुनिक एमवीसी डिजाइन पैटर्न में, एक वर्ग या वस्तु नहीं है। मॉडल एक परत है।
एमवीसी पैटर्न के पीछे मूल विचार सेपरेशन ऑफ कंसर्न है और इसमें पहला कदम प्रेजेंटेशन लेयर और मॉडल लेयर्स के बीच का विभाजन है। जैसे प्रस्तुति परत नियंत्रकों (उदाहरणों, उपयोगकर्ता इनपुट से निपटने के लिए जिम्मेदार), विचार (उदाहरण, UI तर्क के लिए जिम्मेदार) और टेम्पलेट्स / लेआउट में टूट जाती है, वैसे ही मॉडल परत भी करती है।
मॉडल परत के प्रमुख भाग निम्न हैं:
डोमेन ऑब्जेक्ट
डोमेन संस्थाओं, व्यावसायिक वस्तुओं या मॉडल ऑब्जेक्ट के रूप में भी जाना जाता है (मैं उस बाद वाले नाम को नापसंद करता हूं क्योंकि यह सिर्फ भ्रम में जोड़ता है)। ये संरचनाएं हैं जिन्हें लोग आमतौर पर "मॉडल" कहते हैं। वे व्यावसायिक नियमों (सभी गणित और डोमेन तर्क की विशिष्ट इकाई के लिए सत्यापन) के लिए जिम्मेदार हैं।
संग्रहण सार:
आमतौर पर डेटा मैपर पैटर्न का उपयोग करके लागू किया जाता है ( ORMs के साथ भ्रमित न करें , जिन्होंने इस नाम का दुरुपयोग किया है)। इन उदाहरणों को आमतौर पर सूचना संग्रहण से और डोमेन ऑब्जेक्ट में पुनर्प्राप्ति-के साथ सौंपा जाता है। प्रत्येक डोमेन ऑब्जेक्ट में कई मैपर्स हो सकते हैं, जैसे स्टोरेज (डीबी, कैश, सेशन, कुकीज, / देव / मल) के कई रूप हैं।
सेवाएं:
एप्लिकेशन लॉजिक के लिए जिम्मेदार संरचनाएं (यानी, डोमेन ऑब्जेक्ट्स के बीच इंटरैक्शन और डोमेन ऑब्जेक्ट्स और स्टोरेज एब्स्ट्रक्शन के बीच इंटरेक्शन)। उन्हें "इंटरफ़ेस" की तरह कार्य करना चाहिए जिसके माध्यम से प्रस्तुति परत मॉडल परत के साथ बातचीत करती है। यह आमतौर पर क्या होता है रेल-जैसे कोड नियंत्रकों में समाप्त होता है।
कई संरचनाएं भी हैं जो इन समूहों के बीच रिक्त स्थान में हो सकती हैं: डीएओ , काम की इकाइयां और रिपॉजिटरी ।
ओह ... और जब हम MVC एप्लिकेशन के साथ सहभागिता करने वाले उपयोगकर्ता के बारे में (वेब के संदर्भ में) बात करते हैं , तो यह एक इंसान नहीं है। "उपयोगकर्ता" वास्तव में आपका वेब ब्राउज़र है।
तो देवताओं के बारे में क्या?
साथ काम करने के लिए कुछ डरावना और अखंड मॉडल होने के बजाय, नियंत्रकों को सेवाओं के साथ बातचीत करनी चाहिए। आप किसी विशिष्ट सेवा (उदाहरण के लिए करने के लिए उपयोगकर्ता इनपुट से डेटा पास MailServiceया RecognitionService)। इस तरह से नियंत्रक मॉडल परत की स्थिति को बदल देता है, लेकिन यह एक स्पष्ट एपीआई का उपयोग करके और आंतरिक संरचनाओं के साथ खिलवाड़ किए बिना किया जाता है (जो एक टपका हुआ अमूर्त का कारण होगा)।
इस तरह के परिवर्तन या तो कुछ तत्काल प्रतिक्रिया का कारण बन सकते हैं, या केवल उस डेटा को प्रभावित कर सकते हैं जो दृश्य परत मॉडल परत, या दोनों से अनुरोध करता है।
प्रत्येक सेवा डोमेन ऑब्जेक्ट और स्टोरेज एब्स्ट्रक्शन के किसी भी नंबर (हालांकि, यह आमतौर पर केवल एक मुट्ठी भर) के साथ बातचीत कर सकती है। उदाहरण के लिए, RecogitionServiceलेखों के लिए भंडारण सार के बारे में कम परवाह नहीं कर सकता।
नोट बंद करना
इस तरह से आपको एक आवेदन मिलता है जो किसी भी स्तर पर इकाई-परीक्षण किया जा सकता है, इसमें कम युग्मन (यदि सही ढंग से लागू किया गया है) और स्पष्ट रूप से समझने योग्य वास्तुकला है।
हालांकि, ध्यान रखें: MVC छोटे अनुप्रयोगों के लिए नहीं है। यदि आप MVC पैटर्न का उपयोग करते हुए एक गेस्टबुक पेज लिख रहे हैं, तो आप इसे गलत कर रहे हैं। यह पैटर्न बड़े पैमाने पर अनुप्रयोगों के लिए कानून और व्यवस्था को लागू करने के लिए है ।
जो लोग PHP को प्राथमिक भाषा के रूप में उपयोग कर रहे हैं, उनके लिए यह पोस्ट प्रासंगिक हो सकती है। यह कोड के कुछ स्निपेट्स के साथ मॉडल परत का थोड़ा लंबा वर्णन है।