2011-12-02 19 views
5

मैंने देखा है कि मेरे सभी मॉडल बहुत समान दिखते हैं। उनमें से अधिकतर एक पैटर्न का पालन करते हैं जहां वे सक्रिय रिकॉर्ड कोड वाले विधियों का संग्रह होते हैं जो एक-दूसरे पर थोड़ी सी भिन्नताएं हैं। यहां एक उदाहरण दिया गया है:मेरे मॉडल सभी एक ही दिखते हैं

class Site extends CI_Model { 

    public function get_site_by_id($id) 
    { 
     // Active record code to get site by id 
    } 

    public function get_sites_by_user_id($user_id) 
    { 
     // ... 
    } 

    // ... 

    public function get_site_by_user_id_and_url_string($user_id, $url_string) 
    { 
     // ... 
    } 

    // Non active record methods and business logic 
    // ... 

} 

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

+1

यह पूर्ण कार्यान्वित मोड परत के विकल्प के रूप में [सक्रिय रिकॉर्ड] (http://martinfowler.com/eaaCatalog/activeRecord.html) के समूह का उपयोग करने का दुष्प्रभाव होगा। आपको [यह] (http://stackoverflow.com/a/11943107/727208) रिफैक्टरिंग के विकल्पों के लिए प्रासंगिक मिल सकता है। "Purist" बनाम "व्यावहारिक" के लिए –

उत्तर

2

कड़ाई से अपने अनुरोध के बाद, आप एक मध्यवर्ती वर्ग मुख्य मॉडल वर्ग (CI_Model) और अपने वर्ग (साइट), कुछ के बीच की तरह

class MyCommonMethodsClass extends CI_Model { 
} 

जोड़ सकते हैं और आप अपनी कक्षाओं में यह विस्तार (साइट) होगा , उस पर सामान्य कोड डालने के दौरान। यह काम करेगा और किसी भी तरह से सुरुचिपूर्ण हो सकता है। वास्तव में अंत में आप अपने मूल क्रूड, साइट अनुकूलित क्रियाओं को जोड़ना समाप्त कर देंगे।

अब, अगर यह 'साफ' है, तो यह एक और बात है। फिर, मॉडल को सख्ती से बोलते हुए वह करता है। यह आम और 'उन्नत' गेटर्स का ख्याल रखता है। और हां, वे लगभग हमेशा आपकी वेबसाइट के आसपास एक ही कोड रखने की प्रवृत्ति रखते हैं। समस्या यह है कि, हालांकि यह आपके कोड (कम कोड) में अच्छा लग रहा है, लेकिन आप तकनीकी रूप से अपने व्यापार तर्क और डीबी के बीच अमूर्त बलिदान कर रहे हैं। क्या आप एक मॉडल शुद्धवादी या व्यावहारिक हैं?

+0

+1 - कई बार, लोग खुद को "सही" तरीके से करने की कोशिश करने के लिए और अधिक काम करते हैं। – swatkins

+0

हाँ सही है, एक आवेदन को एक साथ थप्पड़ मारने और समस्याओं को खटखटाए जाने की प्रतीक्षा करें। –

1

मुझे लगता है कि यह राय का विषय है, लेकिन मुझे लगता है कि सर्वोत्तम अभ्यास बनाना, पुनर्प्राप्ति, अद्यतन, हटाएं (सीआरयूडी) मॉडल बनाना है जो कई बुनियादी एसक्यूएल फ़ंक्शंस जैसे GetID, UpdateByID, GetById और इसी तरह के बनाता है।

सीआरयूडी मॉडल केवल मॉड्यूलर प्रश्नों के साथ आपकी सहायता करने में ही जा सकते हैं। लेकिन यह GetId नामक फ़ंक्शन को कॉल करने और प्रत्येक तालिका के लिए अलग-अलग फ़ंक्शंस के मुकाबले कुछ पैरामीटर पास करने के लिए समझ में आता है।

जैसा कि मैंने कहा है, सीआरयूडी केवल इतना ही जा सकता है। उदाहरण के लिए यह एक ऐसा कार्य करने का एहसास होगा जो डेटाबेस उपयोगकर्ता तालिका से पूछता है कि उपयोगकर्ता ने सत्यापित किया है और उपयोगकर्ता नाम & पासवर्ड मिलान है या नहीं। चूंकि यह एक अद्वितीय और एक अमूर्त कार्य नहीं है, इसलिए यह स्वयं का कार्य परिभाषित होना चाहिए।

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

0

इस तरह के डेटा को संभालने के लिए अलग-अलग तरीकों के लिए यह सामान्य अभ्यास है। Single Responsibility Principal बताता है कि प्रत्येक ऑब्जेक्ट को केवल एक ही चीज़ करना चाहिए, जो कई विधियों को बनाकर बहुत विशिष्ट डेटा प्राप्त कर रहे हैं जो आप बहुत ही बनाए रखने योग्य और कोड डीबग करने में आसान बना रहे हैं।

+0

शायद उन कार्यों के लिए जो विशिष्ट चीजें करते हैं लेकिन बहुत ही अमूर्त कार्यों के लिए नहीं जो कई अलग-अलग स्थितियों पर लागू हो सकते हैं। –

+0

मुझे यह भी लगता है कि आप 'एकल जिम्मेदारी' से क्या मतलब समझते हैं, इसका मतलब है कि फ़ंक्शन में एक एक्शन है, जो एक एकल कनेक्शन है जो डेटाबेस कनेक्शन को सक्रिय करता है, लेकिन फिर भी इसका उपयोग किया जा सकता है। 'एकल जिम्मेदारी' ओओपी में encapsulation का एक हिस्सा है, encapsulation पुनः उपयोग करने योग्य कोड का सिद्धांत है। –

+0

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

0

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

इस दृष्टिकोण का लाभ हैं:

  • आप काम को दोहरा नहीं कर रहे हैं (स्पॉट, सूखी)
  • कोड है कि कक्षाओं में एक अधिक सामान्य तरीके से लिखा जा सकता है साथ सूचना का आदान और किसी भी वस्तु संभाल कर सकते हैं जो सुपरक्लास (प्रतिस्थापन) से प्राप्त होता है
0

मुझे नहीं लगता कि आपको 'बेस' मॉडल वर्ग बनाने के साथ कोई अन्य चीज़ गलत है, जिससे आप अन्य मॉडलों का विस्तार कर सकें। यदि यह ठोस और अच्छी तरह से परीक्षण किया जाता है, तो यह आपको जीवन को आसान बना सकता है। एक ही सीआरयूडी कार्यों को बार-बार बनाने का क्या मतलब है?

ऐसा करने का एक अन्य लाभ यह है कि आप एक आधार विकास भंडार प्राप्त कर सकते हैं जिसे आपने सभी नई परियोजनाओं को शुरू करने के लिए क्लोन किया है।

यदि आपको ऐसा करने का उदाहरण चाहिए तो इसे question देखें जिसे मैंने पहले पूछा था।

आप अपने controllers के साथ भी ऐसा ही कर सकते हैं।

संबंधित मुद्दे