डेटा बचाने के लिए सक्रिय रिकॉर्ड बनाम डेटा मैपर

ये 2 डिज़ाइन पैटर्न मार्टिन फाउलर की पुस्तक "एंटरप्राइज एप्लीकेशन टेम्प्लेट्स" में वर्णित हैं और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में डेटा की बचत के साथ काम करने के तरीकों का प्रतिनिधित्व करते हैं।

उदाहरण सक्रिय रिकॉर्ड टेम्पलेट

class Foo { protected $db; public $id; public $bar; public function __construct(PDO $db) { $this->db = $db; } public function do_something() { $this->bar .= uniqid(); } public function save() { if ($this->id) { $sql = "UPDATE foo SET bar = :bar WHERE id = :id"; $statement = $this->db->prepare($sql); $statement->bindParam("bar", $this->bar); $statement->bindParam("id", $this->id); $statement->execute(); } else { $sql = "INSERT INTO foo (bar) VALUES (:bar)"; $statement = $this->db->prepare($sql); $statement->bindParam("bar", $this->bar); $statement->execute(); $this->id = $this->db->lastInsertId(); } } } //Insert $foo = new Foo($db); $foo->bar = 'baz'; $foo->save(); 

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

सक्रिय रिकॉर्ड के लाभ

• सक्रिय रिकॉर्ड के साथ कोड लिखना त्वरित और आसान है, जब ऑब्जेक्ट के गुण डेटाबेस में सीधे कॉलम से संबंधित होते हैं।
• बचत एक जगह होती है, जिससे यह सीखने में आसानी होती है कि यह कैसे काम करता है।

सक्रिय रिकॉर्ड के नुकसान

• सक्रिय रिकॉर्ड मॉडल SOLID सिद्धांतों का उल्लंघन करते हैं। विशेष रूप से, एकल जिम्मेदारी का सिद्धांत ( एसआरपी - "एसआईएल" एसओएलआईडी सिद्धांतों में)। सिद्धांत के अनुसार, एक डोमेन ऑब्जेक्ट में ज़िम्मेदारी का केवल एक क्षेत्र होना चाहिए, अर्थात, केवल अपना व्यावसायिक तर्क। डेटा को सहेजने के लिए इसे कॉल करके, आप इसमें एक अतिरिक्त ज़ोन की जिम्मेदारी जोड़ते हैं, जिससे ऑब्जेक्ट की जटिलता बढ़ जाती है, जो इसके समर्थन और परीक्षण को जटिल बनाता है।
• डेटा स्टोरेज का कार्यान्वयन व्यावसायिक तर्क से निकटता से संबंधित है, जिसका अर्थ है कि यदि आप बाद में डेटा को बचाने के लिए किसी अन्य एब्स्ट्रक्शन का उपयोग करना चाहते हैं (उदाहरण के लिए, एक्सएमएल फ़ाइल में डेटा स्टोर करने के लिए, और डेटाबेस में नहीं), तो आपको कोड रीफैक्टरिंग करना होगा।

डेटा मैपर उदाहरण

 class Foo { public $id; public $bar; public function do_something() { $this->bar .= uniqid(); } } class FooMapper { protected $db; public function __construct(PDO $db) { $this->db = $db; } public function saveFoo(Foo &$foo) { if ($foo->id) { $sql = "UPDATE foo SET bar = :bar WHERE id = :id"; $statement = $this->db->prepare($sql); $statement->bindParam("bar", $foo->bar); $statement->bindParam("id", $foo->id); $statement->execute(); } else { $sql = "INSERT INTO foo (bar) VALUES (:bar)"; $statement = $this->db->prepare($sql); $statement->bindParam("bar", $foo->bar); $statement->execute(); $foo->id = $this->db->lastInsertId(); } } } //Insert $foo = new Foo(); $foo->bar = 'baz'; $mapper = new FooMapper($db); $mapper->saveFoo($foo); 

इस मामले में, फू वर्ग बहुत सरल है और केवल अपने व्यावसायिक तर्क के बारे में चिंता करनी चाहिए। इतना ही नहीं उसे अपना डेटा भी नहीं बचाना है, उसे पता भी नहीं है और उसे इस बात की परवाह नहीं है कि उसका सारा डेटा बच गया है या नहीं।

डेटा मैपर के लाभ

• प्रत्येक वस्तु की अपनी जिम्मेदारी का क्षेत्र होता है, जिससे SOLID सिद्धांतों का पालन किया जाता है और प्रत्येक वस्तु को सरल और बिंदु पर रखा जाता है।
• व्यावसायिक तर्क और डेटा संग्रहण शिथिल रूप से युग्मित होते हैं, और यदि आप डेटा को XML फ़ाइल या किसी अन्य प्रारूप में सहेजना चाहते हैं, तो आप बिना डोमेन ऑब्जेक्ट को छुए बस एक नया मैपर लिख सकते हैं।

डेटा मैपर का नुकसान

• कोड लिखने से पहले आपको कुछ और सोचना होगा।
• नतीजतन, आपके पास प्रबंधित करने के लिए अधिक ऑब्जेक्ट हैं, जो कोड और इसके डीबगिंग को थोड़ा जटिल करता है।

सेवा वस्तु

डेटा मैपर डिज़ाइन पैटर्न का उपयोग करते समय, कॉलर को मैपर और व्यावसायिक ऑब्जेक्ट का चयन करना होगा और उन्हें एक साथ जोड़ना होगा। यदि यह नियंत्रक में कॉल कोड है, तो अंततः आपका मॉडल नियंत्रक में लीक हो जाता है, जो समर्थन और इकाई परीक्षण के साथ बड़ी समस्याएं पैदा कर सकता है। सेवा ऑब्जेक्ट को पेश करके इस समस्या को हल किया जा सकता है। सेवा नियंत्रक और मॉडल के बीच का प्रवेश द्वार है और आवश्यकतानुसार डोमेन ऑब्जेक्ट को मैपर से जोड़ता है।

ध्यान रखें कि एमवीसी में एम एक मॉडल ऑब्जेक्ट की एक परत है, न कि मॉडल ऑब्जेक्ट। तो एक मॉडल में कई प्रकार की वस्तुएं हो सकती हैं (उपरोक्त उदाहरण में, आपके पास एक सेवा ऑब्जेक्ट, एक डोमेन ऑब्जेक्ट और एक सिंगल मॉडल के रूप में काम करने वाला मैपर ऑब्जेक्ट हो सकता है)। दूसरी ओर, यदि आप सक्रिय रिकॉर्ड मॉडल का उपयोग करते हैं, तो आपका मॉडल केवल एक ऑब्जेक्ट द्वारा दर्शाया जा सकता है।

मामलों का उपयोग करें

सक्रिय रिकॉर्ड ऑब्जेक्ट ऐतिहासिक रूप से बहुत लोकप्रिय रहे हैं क्योंकि वे सरल, समझने में आसान और लिखने में तेज़ हैं, यही वजह है कि कई फ्रेमवर्क और ओआरएम डिफ़ॉल्ट रूप से सक्रिय रिकॉर्ड का उपयोग करते हैं।

यदि आप सुनिश्चित हैं कि आपको डेटा स्टोरेज लेयर को बदलने की आवश्यकता नहीं होगी (यदि आप एक ऐसी वस्तु के साथ काम कर रहे हैं जो एक INI फ़ाइल है, उदाहरण के लिए), या आप बहुत ही साधारण वस्तुओं के साथ काम कर रहे हैं जिसमें बहुत अधिक व्यावसायिक तर्क नहीं है, या बस सब कुछ छोटी कक्षाओं में रखना पसंद करते हैं, तो सक्रिय रिकॉर्ड टेम्पलेट वह है जो आपको चाहिए।

डेटा मैपर का उपयोग, हालांकि यह एक क्लीनर की ओर जाता है, कोड का परीक्षण करने और बनाए रखने में आसान है, और अधिक लचीलापन प्रदान करता है, - इसके लिए कीमत - बढ़ी हुई जटिलता। यदि आपने इसका उपयोग करने की कोशिश नहीं की है, तो इसे एक मौका दें - आपको इसे पसंद करना चाहिए।

यह रसेल वॉकर के एक लेख का अनुवाद है।