सीधे एमवीसी में नियंत्रक से ओआरएम कक्षाओं का उपयोग, बुरा अभ्यास?

Question

मैंने हाल ही में अपने कोडइग्निटर एप्लिकेशन में एक ओआरएम का उपयोग करने में प्रवेश किया है और एक जिसे मैं चला गया हूं वह है। अब यह मुझे मूल रूप से 'मॉडल' के रूप में प्रोपल्स कक्षाओं का उपयोग करने की शक्ति देता है लेकिन क्या यह बुरा व्यवहार है?

<?php 
    class Page extends Controller { 
     function __construct() { 
      parent::__construct(); 
     } 

     function index() { 
      $foo = FooQuery::create()->limit(10)->find(); 
      $data['content'] = array('foo'=>$foo); 
      $this->load->view('home', $foo);  
     } 
    } 
?> 

मैं इस समस्या को हल करने के लिए इससे पहले कि मैं अपने आवेदन के विकास पर ले जाने के लिए चाहते हैं:

तो मेरी नियंत्रक कोड इस प्रकार होगा। अगर आप इसे खराब अभ्यास मानते हैं तो मुझे यह कैसे करना चाहिए इसका एक उदाहरण बहुत उपयोगी होगा।

अग्रिम धन्यवाद

Answer 1

हाँ, यह बुरा अभ्यास है।

मॉडल में आपके सभी डेटा तर्क शामिल होना चाहिए और इसे बाकी कार्यक्रम से दूर करना चाहिए। शेष एप्लिकेशन के लिए, मॉडल को काले बक्से की तरह दिखना चाहिए, जिनमें से इसका डेटा प्राप्त हो जाता है। यदि आप अपने मॉडल के रूप में ओआरएम का उपयोग करते हैं, तो आप leaking the abstraction हैं और अपने कंट्रोलर को अपनी डेटा परत पर कसकर जोड़ते हैं।

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

Answer 2

जब मैंने आपका ORM Active Row पैटर्न का पालन किया है तो मुझे यह कभी-कभी आवश्यक बुराई मिलती है।

समस्या जो मैं हमेशा चलता हूं वह यह है कि एक मॉडल केवल डेटा संरचना का एक उदाहरण प्रस्तुत करता है। मॉडल में संग्रह पुनर्प्राप्ति विधियों को जोड़ने का कोई मतलब नहीं है।

यह वह जगह है जहां मैंने ऐतिहासिक रूप से मॉडलों के संग्रह में खींचने के लिए एक सेवा परत का उपयोग किया है। यद्यपि हाल ही में ईमानदार होने के लिए मैंने बस एक नियंत्रक सहायक वस्तु लिखा है जो सिर्फ मेरी तालिका वस्तु को सार तत्वित करता है।

Answer 3

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

लेकिन याद रखें कि Query कक्षाएं वास्तविक वस्तु की तरह महसूस करने के लिए बनाई गई हैं, और वे जितना संभव हो सके संबंधपरक हिस्से को छुपा सकते हैं। आप इसे अपने लाभ के लिए उपयोग कर सकते हैं। this article about rewriting your SQL queries with Query methods देखें, विशेष रूप से तीसरा उत्तर: अपने Query कक्षा में अधिक से अधिक स्थानांतरित करें, इसलिए आपके नियंत्रक को ऐसा लगता है कि यह डेटाबेस का उपयोग नहीं करता है।

// Instead of this code in your controller, 
// tightly coupled to your database logic 
$books = BookQuery::create() 
    ->filterByTitle('%war%') 
    ->filterByPrice(array('max' => 10) 
    ->filterByPublishedAt(array('max' => time())) 
    ->leftJoin('Book.Author') 
    ->where('Author.Name > ?', $fameTreshold); 

// You would use this code in your controller 
// and create small methods with the business logic in the BookQuery class 
$books = BookQuery::create() 
    ->titleContainsWord('war') 
    ->cheap() 
    ->published() 
    ->writtenByFamousAuthors(); 

Answer 4

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

मैं कहूंगा कि सीमाएं, ऑर्डर और ऑफसेट अक्सर व्यावसायिक तर्क नहीं होते हैं। यहां तक ​​कि एक साधारण जहां मामला के आधार पर हो सकता है या नहीं।यदि वहां कोई जुड़ाव है, तो यह एक संकेत है कि कुछ गलत है।

जन फैब्रिक का उदाहरण अधिकतर अच्छा है। filterBontTitle मेरे बारे में शीर्षकContainsWord के रूप में मेरे बारे में दिखता है। filterByPublishedAt (सरणी ('अधिकतम' => समय())) -> प्रकाशित() से भी बदतर है। आम तौर पर, कम नियंत्रकों को आंतरिक डेटा संरचना के बारे में जानने की आवश्यकता होती है, बेहतर।