प्रत्येक नियंत्रक के लिए बजाय अलग-अलग मॉडल के सभी नियंत्रकों

Question

तो मैं देखा है के लिए एक एकल crud मॉडल का उपयोग ususally एक मॉडल डेटाबेस में एक मेज के प्रतिनिधित्व है जैसे उपयोगकर्ताओं तालिका के लिए यह कुछ प्रकार है:

class user_model { 

    public $id ; 
    public $username ; 
    public $password ; 
    public $email ; 


    public function save(){ 
    $db->query(" insert into `users` (username , email , password) values ('$this->username' , '$this->email' , '$this->password') "); 
    } 

    public function delete(){ 
    $db->query(" delete from users where id = $this->id "); 
    } 

} 

लेकिन इस प्रक्रिया बहुत धीमी है और क्या मॉडल के सबसे अधिक है बुनियादी CRUD आपरेशन है ... तो मैं लगभग सभी मेरी नियंत्रकों की तरह के लिए एक एकल crud मॉडल का उपयोग करें: ध्यान दें कि यह एक बहुत ही सरलीकृत संस्करण है

class crud_model { 

    public function save($tbl , $data){ 
    $db->query(" insert into $tbl (".explode(',' , array_keys($data)).") values (".explode(',' , $data).") "); 
    } 

    public function delete( $tbl , $data){ 
    $db->query(" delete from $tbl where $data['column'] = $data['val'] "); 
    } 

} 

दलीलों मेरा मॉडल और मूल रूप से इसकी तरह कुछ भी नहीं मूल कोड (मूल कोड में सक्रिय रिकॉर्ड का उपयोग कर रहा हूं और यह जटिल परिदृश्यों को संभाल सकता है) इसलिए वाक्यविन्यास और तकनीकी त्रुटियों को अनदेखा करें

इसलिए मैं जानना चाहता हूं कि इस दृष्टिकोण में कोई समस्या है या नहीं? क्या मैं कुछ भूल रहा हूँ ?

क्या मॉडल के बहुत सारे होने की बात जब आप एक CRUD मॉडल के साथ द्वारा प्राप्त कर सकते हैं .... यह सिर्फ समय

Answer 1

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

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

पैटर्न के संदर्भ में आपके वर्तमान दृष्टिकोण के साथ, आपकी तालिका का प्रतिनिधित्व करने के लिए मॉडल रखने के लिए, आप वास्तव में एक सामान्य सीआरयूडी कक्षा के साथ व्यक्तिगत तालिकाओं का प्रतिनिधित्व नहीं कर सकते हैं। मॉडल कक्षाओं में अक्सर अतिरिक्त श्रेणी गुण होते हैं जो तालिका के प्रतिनिधित्व के लिए विशिष्ट होते हैं। यह आपको अपनी कक्षाओं को डिजाइन करने की अनुमति देता है ताकि अगर उनका पुन: उपयोग किया जाए, तो डेवलपर को अंतर्निहित डेटा संरचना की बेहतर समझ हो। अपने मूल प्रश्न में User कक्षा का अपना उदाहरण देखें। उस वर्ग में $id, $username और $password जैसी गुण हैं। एक डेवलपर इसे देख सकता है और पता कर सकता है कि नया उपयोगकर्ता बनाने के लिए क्या आवश्यक है।