डोमेन ऑब्जेक्ट को समझना + डेटा मैपर पैटर्न?

Question

मैंने हमेशा अतीत में विभिन्न ओआरएम के साथ काम किया है और मेरे सभी तर्कों को मेरे प्रकृति के बावजूद मेरे मॉडल के अंदर रखा है - एसक्यूएल, मोंगोडीबी प्रश्न & यहां तक ​​कि दूरस्थ JSON ऑब्जेक्ट्स को भी ला रहा है। लेकिन जब उच्च स्तर की टेस्टेबिलिटी की अनुमति देने के लिए ढीले कपलिंग सुनिश्चित करना आवश्यक है, तो इस पद्धति के मुद्दे जल्दी प्रकट होते हैं।

आज मैंने मॉडल को दो भागों में विभाजित करने के बारे में पढ़ा है, Domain objects & Data mappers।
यदि मैं इसे पूरी तरह समझ गया, Domain objects पूरी तरह से उपयोग किए गए संग्रहण से अनजान हैं, और इसके बजाय व्यावसायिक तर्क को संभालने के लिए मौजूद है। Data mappers दूसरी ओर Domain objects में डेटा सेट को सेट डेटा संग्रहण में संग्रहीत करने का ख्याल रखता है।

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

क्या यह (नीचे दिखाया गया कोड) डोमेनओब्जेक्ट्स & डेटामैपर्स के साथ काम करने का उचित तरीका होगा उपयोगकर्ताओं को स्टोर करने के लिए या मेरे सिर में यह सब गलत हो गया है?

$user = new User_DO; 
$userSave = new User_DM; 
$userSave->store($user->add(array('name' => 'John Doe'))); 

class User_DO { 

    function add($array) { 
     if(!isset($array['name'])) { 
      throw new Exception("Name must be set"); 
     } 

     return $array; 

    } 

} 

class User_DM { 

    function store($array) { 
     MyDatabase::execute("INSERT INTO..."); 
    } 

} 

Answer 1

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

class person_DO { 
    public $id; 
    public $firstname; 
    public $lastname; 
    public $addresses; 
} 

इस डोमेन मॉडल के उदाहरण की लोडिंग (डोमेन वस्तुओं) और दृढ़ता डेटा मानचित्रकारों के माध्यम से नियंत्रित किया जाता है - जैसे जैसे n संबंध,:: उपरोक्त व्यक्ति के पते में एक 1 के माध्यम से एक और तालिका में स्थित हो सकता है

TABLE person { 
    id  INTEGER PRIMARY KEY, 
    firstname VARCHAR(32), 
    lastname VARCHAR(32) 
} 

TABLE addresses { 
    id INTEGER PRIMARY KEY, 
    person_id INTEGER FOREIGN KEY ON person.id, --Reference on person-row 
    street  VARCHAR(64), 
    ... 
} 

person_DO उस के बारे में पता करने की जरूरत नहीं है, लेकिन datamapper, करता है के रूप में यह एकत्र करने के लिए है बने दौरान लोड हो रहा है और अलग दौरान डेटा:

class person_DM { 
    /** 
    * @param [integer] $id 
    * @return [person_DO] an instance of a person or null, if no person 
    *      with that id was found. 
    */ 
    public function findById ($id) {...} 

    /** 
    * @return [array of person_DO] 
    */ 
    public function fetchAll() {...} 

    /** 
    * persists a person object 
    * @param [person_DO] an instance of a person 
    */ 
    public function saveOrUpdate(person_DO $person) {...} 
} 

आदेश विभिन्न भागों और भी अधिक दसगुणा करने के लिए, DataMappers आमतौर पर DbTable गेटवे या किसी ऐसे ही पैटर्न का उपयोग विभिन्न डेटाबेस या इसी तरह के कार्यों के उपयोग की अनुमति के लिए। इस तरह, मेरे पास एक ही स्कीमा के साथ कई डेटाबेस हो सकते हैं, लेकिन उदा। विभिन्न संगठनों में एक ही कोड के साथ डेटा वेयरहाउस बनाने के लिए, केवल अलग डेटाबेस ऑब्जेक्ट्स।

एक व्यावहारिक उदाहरण के रूप में, मैं ज़ेंड फ्रेमवर्क के Quickstart Tutorial को देखने का सुझाव दूंगा, जो वास्तव में मैंने संक्षेप में समझाया है।

Answer 2

यहाँ विषय में आपकी रुचि है के बारे में एक अच्छी किताब है आप हठ फ्रेमवर्क अध्याय में डेटा mappers (सार डाटा मानचित्रकारों) के बारे में पा सकते हैं:

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process

Answer 3

अनुमानित रास्ता हाँ। हालांकि मैं अत्यधिक अनुशंसा करता हूं कि पहिया का पुन: आविष्कार न करें और Doctrine 2.x जैसे परिष्कृत ओआरएम का उपयोग करें जो इस तरह के पैटर्न को लागू करता है। इंटरफ़ेस का नमूना देने के लिए आप उनके दस्तावेज़ (Chapter 8: Working with objects) पर एक नज़र डाल सकते हैं।