क्या डाटामैपर पैटर्न एमवीसी तोड़ता है?

Question

मैं कई PHP ढांचे, विशेष रूप से ज़ेंड फ्रेमवर्क पर पढ़ रहा हूं लेकिन मैं आगे बढ़ने के उचित तरीके के बारे में उलझन में हूं।

ज़ेंड फ्रेमवर्क सक्रिय रिकॉर्ड्स का उपयोग नहीं करता है बल्कि इसके बजाय टेबल डेटा गेटवे और पंक्ति डेटा गेटवे पैटर्न का उपयोग करता है, और मॉडल डेटा में पंक्ति डेटा गेटवे की सामग्री को मैप करने के लिए डेटामैपर का उपयोग करता है, क्योंकि आपके मॉडल नहीं होने पर ActiveRecord टूट जाता है अपने डेटाबेस टेबल पर 1: 1 मैपिंग है। ज़ेंड क्विकस्टार्ट मार्गदर्शिका में example of this है।

मेरे लिए, उनका उदाहरण पूरे स्थान पर गेटर्स और सेटर्स के टन के साथ बहुत फूला हुआ दिखता है। मैं डोमेन ड्राइव डिज़ाइन के बारे में विभिन्न ब्लॉग पोस्टों में आया था कि बहस करते हुए कि कई गेटर्स और सेटर्स का उपयोग करना बुरा अभ्यास है क्योंकि यह सभी आंतरिक मॉडल डेटा को बाहर निकाल देता है, इसलिए इसका सार्वजनिक गुणों पर कोई फायदा नहीं होता है। Here is one example।

मेरा प्रश्न: यदि आप उन गेटर्स और सेटर्स को हटाते हैं, तो आप अपने विचार कैसे प्रस्तुत करेंगे? किसी बिंदु पर डेटा को दृश्य को हिट करना पड़ता है ताकि आप वास्तव में उपयोगकर्ता को कुछ दिखा सकें। डीडीडी सलाह के बाद एमवीसी में एम और वी के बीच अलगाव तोड़ने लगता है। एमवीसी और ज़ेंड उदाहरण के बाद डीडीडी तोड़ने लगता है और मुझे अपने सभी मॉडलों के लिए बहुत सारे गेटर्स, सेटर्स और डेटामैपर टाइप करना छोड़ देता है। बहुत सारे काम होने के अलावा यह भी DRY का उल्लंघन करता प्रतीत होता है।

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

Answer 1

मूल्य वस्तुओं का उपयोग करके, आप उन सार्वजनिक सेटर विधियों में से कुछ को खत्म कर सकते हैं। यहां the difference between Entity and Value Objects का विवरण दिया गया है। मूल्य वस्तुएं अपरिवर्तनीय हैं और अक्सर एक इकाई से जुड़ी होती हैं। यदि आप कन्स्ट्रक्टर के साथ सभी मानों को पास करते हैं, तो आपको इन गुणों को बाहरी कोड से सेट करने की आवश्यकता नहीं है।

कुछ अतिरिक्त, सीधे एक जवाब से संबंधित नहीं है, लेकिन और अधिक ध्यान केंद्रित DDD पर:

(अस्वीकरण: केवल एक चीज Zend फ्रेमवर्क के बारे में मुझे पता है कि मैं जुड़ा हुआ लेख में पढ़ा है।) ज़ेंड फ्रेमवर्क रिपोजिटरीज के बजाय डेटामैपर का उपयोग कर रहा है। क्या यह वास्तव में डीडीडी-ईश है? खैर, Fowler's interpretation of a Repository कोई नहीं कह सकता है। हालांकि, एरिक इवांस का कहना है कि एक डीडीडी रिपोजिटरी बहुत सरल हो सकती है। अपने सबसे सरल पर, एक रिपोजिटरी डेटामैपर (डीडीडी पुस्तक देखें) है। कुछ और जटिल और अभी भी डीडीडी के लिए, फाउलर आलेख देखें। डीडीडी में एक वैचारिक रिपोजिटरी है जो पैटर्न परिभाषा से भिन्न हो सकती है।

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

Answer 2

आपको सभी गेटर्स/सेटर्स को लागू करने की आवश्यकता नहीं है, आप__get() और __set() का उपयोग कर सकते हैं। तब समस्या क्या है?

Answer 3

पोस्ट के पढ़ने से, प्रश्न व्यावहारिक के बजाय अधिक दार्शनिक है।

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

फिर, यह पोस्ट कुछ उदाहरणों का उपयोग कर सकती है, लेकिन मेरे पास अभी समय नहीं है।

क्या कोई और कुछ उदाहरण प्रदान कर सकता है कि एक्सेसर विधियां बुरा क्यों नहीं हैं?

Answer 4

getters और setters को लागू करने दो फायदे, मेरी आँखों में है:

1. आप जो गुण को सार्वजनिक करने का है, तो आप जरूरी मॉडल के internals के सभी को बेनकाब करने की जरूरत नहीं है चुन सकते हैं
2. आप तो स्वत: पूर्ण के साथ एक आईडीई का उपयोग करें, जब आप "प्राप्त करें" या "सेट" टाइप करना शुरू करते हैं तो सभी उपलब्ध गुण एक टैब दूर होंगे-यह अकेला मेरे लिए पर्याप्त कारण है।

Answer 5

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

class DomainObject { 
    .... 
    public function render(DomainObjectRenderer $renderer) { 
     return $renderer->renderDomainObject(array $thegorydetails); 
    } 
} 

Zend फ्रेमवर्क के संदर्भ में, आप Zend_View उपवर्ग और अपने उपवर्ग इस इंटरफ़ेस को लागू कर सकते हैं।

मैंने इसे पहले किया है, लेकिन यह थोड़ा सा अनावश्यक है।

दूसरा विकल्प आपके डोमेन मॉडल को एक व्यूमोडेल ऑब्जेक्ट में परिवर्तित कर देता है, जो आपके डेटा के एक सरलीकृत, फ़्लैटेड आउट, "स्ट्रिंग आउट" दृश्य की तरह है, प्रत्येक विशिष्ट दृश्य के लिए अनुकूलित (प्रति दृश्य एक व्यूमोडेल के साथ), और वापस रास्ते पर, पोस्ट डेटा को एक संपादन मॉडल में कनवर्ट करें।

यह एएसपी.नेट एमवीसी दुनिया में एक बहुत ही लोकप्रिय पैटर्न है, लेकिन यह "डीटीओ" पैटर्न के समान है जो किसी एप्लिकेशन में "परतों" के बीच डेटा स्थानांतरित करने के लिए उपयोग किया जाता है। आपको अपने लिए गंदे काम करने के लिए मैपर बनाने की आवश्यकता होगी (वास्तव में डेटामैपर के विपरीत नहीं)। PHP 5.3 में, आप निजी गुणों को बदलने के लिए प्रतिबिंब का उपयोग कर सकते हैं, इसलिए आपके DomainObject को स्वयं को बेनकाब करने की भी आवश्यकता नहीं है!