2012-02-17 12 views
7

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

- models 
    - DbTables 
     - Blog.php //Extends Zend_Db_Table_Abstract 
    - Blog.php  // Contains methods like validate() and save() 
    - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b) 

इस विशिष्ट संरचना का पालन क्यों किया जाता है? क्या यह ऑब्जेक्ट क्लास और डेटाबेस मॉडल क्लास को अलग करना है?

कृपया समझाएं।

+0

संक्षेप में: हां। उत्तर के रूप में आप क्या उम्मीद करते हैं? (sidenote: जब 'ब्लॉग' में विधियां' सेव() 'होती हैं और इस तरह, यह एक सक्रिय रिकॉर्ड कार्यान्वयन और मॉडल-मैपर-अवधारणा के अर्थ में एक मॉडल कम है) – KingCrunch

+0

@ किंग कंचन, मैं जानना चाहता हूं कि यह क्यों संरचना का उपयोग किया जाता है? डेटा बेस में मूल्यों को स्टोर करने के लिए हम सीधे एक वर्ग का उपयोग नहीं कर सकते? मैंने अभी ज़ेंड के साथ शुरुआत की है, वह वनी है। इस पैटर्न के बारे में कारण नहीं जानते? –

+0

मैंने जवाब नहीं पढ़े, इस प्रकार मुझे लगता है कि इसका कहीं जवाब दिया गया है। संक्षिप्त कारण यह है: व्यवसाय का पृथक्करण- और डेटा-पहुंच-तर्क। – KingCrunch

उत्तर

12

DataMapper is a design pattern from Patterns of Enterprise Application Architecture

डेटा मैपर सॉफ़्टवेयर की एक परत है जो डेटाबेस से इन-मेमोरी ऑब्जेक्ट को अलग करता है। इसकी ज़िम्मेदारी दो के बीच डेटा स्थानांतरित करना और उन्हें एक-दूसरे से अलग करना है। डेटा मैपर के साथ इन-मेमोरी ऑब्जेक्ट्स को यह भी पता नहीं होना चाहिए कि डेटाबेस मौजूद है; उन्हें कोई एसक्यूएल इंटरफ़ेस कोड की आवश्यकता नहीं है, और निश्चित रूप से डेटाबेस स्कीमा का कोई ज्ञान नहीं है।

आप एक रिलेशनल डेटाबेस में डेटा कैसे स्टोर करते हैं, यह आम तौर पर स्मृति में वस्तुओं को कैसे बनाएगा इससे अलग है। उदाहरण के लिए, किसी ऑब्जेक्ट में अन्य ऑब्जेक्ट्स के साथ एक सरणी होगी, जबकि डेटाबेस में, आपकी तालिका के बजाय दूसरी तालिका में एक विदेशी कुंजी होगी। object-relational impedance mismatch की वजह से, आप डोमेन ऑब्जेक्ट और डेटाबेस के बीच मध्यस्थ परत का उपयोग करते हैं। इस तरह, आप दूसरे को प्रभावित किए बिना दोनों विकसित कर सकते हैं।

मैपिंग जिम्मेदारी को अपनी परत में अलग करना Single Responsibility Principle के बाद भी अधिक बारीकी से है। आपकी वस्तुओं को डीबी तर्क और इसके विपरीत के बारे में जानने की आवश्यकता नहीं है। आपका कोड लिखते समय यह आपको अधिक लचीलापन देता है।

जब आप किसी डोमेन मॉडल का उपयोग नहीं करना चाहते हैं, तो आपको आमतौर पर डेटामैपर की आवश्यकता नहीं होती है। यदि आपकी डेटाबेस टेबल सरल हैं, तो आप एक टेबल मॉड्यूल और टेबलडाटा गेटवे या यहां तक ​​कि केवल ActiveRecord के साथ बेहतर हो सकते हैं।

विभिन्न अन्य पैटर्न के लिए

6

एक मॉडल के विचार अपने कोड के अंदर डेटा की तार्किक संग्रह लपेट के लिए है करने के लिए अपने जवाब में देखते हैं।

डेटामैपर का विचार डेटा के इस एप्लिकेशन-स्तर संग्रह से संबंधित है कि आप इसे कैसे संग्रहीत कर रहे हैं।

बहुत सारे सक्रिय रिकॉर्ड कार्यान्वयन के लिए, ढांचा इस इरादे को अलग नहीं करता है और इससे समस्याएं पैदा हो सकती हैं।उदाहरण के लिए, एक ऐसे ब्लॉग पोस्ट मॉडल की तरह

  • शीर्षक एक ब्लॉग पोस्ट की बुनियादी जानकारी लपेट कर सकते हैं
  • लेखक
  • शरीर
  • date_posted

लेकिन हो सकता है आप भी यह करना चाहते हैं इसमें कुछ शामिल है:

  • number_of_reads
  • number_of_likes

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

ब्लॉगपॉस्ट ऑब्जेक्ट्स के उन क्षेत्रों को अपने एप्लिकेशन कोड को बदले बिना किसी भिन्न डेटा स्टोर पर माइग्रेट करने के बारे में आप कैसे जाएंगे?

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