एमवीसी में मॉडल की सरणी - स्वादिष्ट और कठोर?

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


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

if ($row['status'] == 3) { // do something ... } 

 class Post { const AUTH_ONLY = 3; public $status; public function isAuthOnly() { return $this->status == self::AUTH_ONLY; } } if ($post->isAuthOnly()) { // do something ... } 

यदि आपको समस्या को जल्दी और आसानी से हल करने की आवश्यकता है - पहला विकल्प अच्छा है। हालांकि, यदि आपका कोड आपके बाद रहेगा, तो न केवल आपके द्वारा पढ़ा जाता है, बल्कि विकास और विस्तार भी करता है, तो अक्सर दूसरे विकल्प का कार्यान्वयन बेहतर होता है।

समस्या का सार:
अपने आप से, डेटा मॉडल बड़ी संख्या में पाए जाते हैं, आमतौर पर डेटाबेस से रिकॉर्ड का चयन करते समय। डेटाबेस (ORM) में रिकॉर्ड पर अमूर्तता को अपने तर्क के साथ एक मॉडल के कार्यान्वयन की आवश्यकता होती है, हालांकि, प्रत्येक चयनित रिकॉर्ड के लिए मॉडल बनाना अत्यंत संसाधन-गहन है।

सबसे अधिक बार आप निम्नलिखित अनुशंसा सुन सकते हैं:
यदि आपको कुछ रिकॉर्ड की आवश्यकता है, तो आप मॉडल का उपयोग कर सकते हैं, यदि कई हैं, तो आपको पहले से ही अपने तर्क के साथ डेटाबेस को एक अलग क्वेरी के साथ संसाधित करना चाहिए। हालांकि, एक अलग क्वेरी के साथ, हम आंशिक रूप से तालिका में अमूर्त की परत खो देते हैं और मॉडल तर्क का उपयोग करने की क्षमता खो देते हैं।

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

 $post = new Post; $result = mysqli_query('SELECT * FROM posts'); while ($row = mysqli_fetch_array($result)) { $post->setAttributes($row); //     if ($post->isAuthOnly()) { // do something ... } // do something ... } 

इस प्रकार, कुछ भार की कीमत पर, हम बड़े पैमाने पर नमूने के लिए मेमोरी की खपत को बढ़ाए बिना मॉडल के सभी फायदे प्राप्त करते हैं। यह कहे बिना जाता है कि हमें वास्तव में मॉडल के तर्क की आवश्यकता है।

हालांकि, यह समाधान, हालांकि पारदर्शी, पर्याप्त सुरुचिपूर्ण नहीं है, क्योंकि जब इसे फिर से लागू किया जाता है, तो महत्वपूर्ण कोड दोहराव होगा। हम Iterator'a की शक्ति में मदद करने के लिए कहते हैं:

 class PostIterator implements Iterator { private $_model; private $_result; private $_row_num = 0; private $_total_rows = 0; public function __construct(Post $model) { $this->_model = $model; } public function selectAll() { //     $this->_result = mysqli_query('SELECT * FROM posts'); $this->_total_rows = mysqli_num_rows($this->_result); } public function current () { //      mysqli_data_seek($this->_result, $this->_row_num); $data = mysqli_fetch_array($this->_result); $this->_model->setAttributes($data); return $this->_model; } public function next () { //     ++$this->_row_num; } public function key () { //    return $this->_row_num; } public function valid () { //     return ($this->_row_num < $this->_total_rows); } public function rewind () { //     mysqli_data_seek($this->_result, 0); $this->_row_num = 0; } } class Post { // ... public function getIterator() { return new PostIterator($this); } } //    $post_model = new Post; $post_iterator = $post_model->getIterator(); $post_iterator->selectAll(); foreach ($post_iterator as $post) { if ($post->isAuthOnly()) { // do something ... } // do something ... } 

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

हालाँकि, उपरोक्त कोड में कई नुकसान और अड़चनें हैं:
1. हमारे पास केवल एक मॉडल (ऑब्जेक्ट) है जिसे हम चक्र के अंदर छद्म लिंक द्वारा स्थानांतरित करते हैं, परिणामस्वरूप, चक्र के अंदर इसका परिवर्तन पूरे बाद के चक्र को प्रभावित करेगा।
2. डेटाबेस (mysqli_data_seek) से एक क्वेरी के परिणाम को नेविगेट करने का संचालन संसाधनों के अपने हिस्से का उपभोग करता है, और अगर हमें "असाधारण सही" पुनरावृत्ति कार्यान्वयन की आवश्यकता नहीं है, तो हम "इसे थोड़ा आसान बना सकते हैं"। चूंकि ट्रैवर्सेबल इंटरफ़ेस mysqli_result में केवल PHP 5.4 में दिखाई देता है, इसलिए हम सीधे Iterator में इसके कार्यान्वयन की जिम्मेदारी mysqli_result में स्थानांतरित नहीं कर सकते। हालांकि, परिणाम संसाधन में ही, यह इंटरफ़ेस अंतर्निहित रूप से लागू किया गया है, जिसका उपयोग किया जा सकता है।
3. इसके अतिरिक्त, हमें इट्रेटर प्राप्त करने के लिए प्रत्येक बार पहले से एक मॉडल (पोस्ट) नहीं बनाना पड़ता है। इसे स्थैतिक विधि के माध्यम से लागू किया जा सकता है।
4. आमतौर पर, एक इटरेटर के साथ संयोजन में, कभी-कभी ArrayAccess इंटरफ़ेस को लागू करना सुविधाजनक होता है, हालाँकि, यदि आवश्यक हो तो आप आसानी से इस बिंदु को स्वयं कार्यान्वित कर सकते हैं (mysqli_data_seek आपकी मदद करने के लिए)।

उपरोक्त टिप्पणियों के संदर्भ में, हम निम्नलिखित थोड़ा अनुकूलित कोड प्राप्त कर सकते हैं:

 class PostIterator implements Iterator { private $_model; private $_result; private $_row_num = 0; private $_total_rows = 0; private $_current_data = null; //      public function __construct($model) { $this->_model = $model; } public function selectAll() { $this->_result = mysqli_query('SELECT * FROM posts'); $this->_total_rows = mysqli_num_rows($this->_result); $this->_current_data = mysqli_fetch_array($this->_result); //  return $this; //  MethodChaining } public function current () { $model = clone $this->_model; //   $model->setAttributes($this->_current_data); return $model; } public function next () { ++$this->_row_num; $this->_current_data = mysqli_fetch_array($this->_result); //  } public function key () { return $this->_row_num; } public function valid () { return ($this->_row_num < $this->_total_rows); } public function rewind () { mysqli_data_seek($this->_result, 0); $this->_row_num = 0; $this->_current_data = mysqli_fetch_array($this->_result); //  } } class Post { // ... public static function getIterator() { $class_name = __CLASS__; return new PostIterator(new $class_name); } } //    $post_iterator = Post::getIterator()->selectAll(); foreach ($post_iterator as $post) { if ($post->isAuthOnly()) { // do something ... } // do something ... } 

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

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

पुनश्च:
उपरोक्त सभी कोड किसी विशेष कार्य से काफी सार है। यह केवल सिद्धांत का एक सामान्य विचार प्राप्त करने के लिए दिया जाता है, जिसे स्वतंत्र रूप से व्यवहार में लागू किया जा सकता है। और, ज़ाहिर है, पूर्णता की कोई सीमा नहीं है।