ज़ेंड फ्रेमवर्क में मॉडल को अनुकूलित कैसे करें?

Question

मुझे ज़ेंड फ्रेमवर्क में कुशलतापूर्वक मॉडल का उपयोग करने के लिए सर्वोत्तम अभ्यास करने की आवश्यकता है।

वर्तमान में, मैं Zend_Db_Table_Abstract विस्तार वर्ग है जो प्रत्येक वर्ग 'संबंधित तालिका करने के लिए अपने प्रश्नों को संभालने की है।

जब मुझे नियंत्रक से उन तालिकाओं में से 5 का उपयोग करने की आवश्यकता होती है, तो मुझे लगता है कि मैं प्रत्येक विशिष्ट Zend_Db_Table ऑब्जेक्ट के 5 नए उदाहरण बना रहा हूं। यह वास्तव में अप्रभावी है।

मैं नया उदाहरण बना करने के लिए एक फैक्टरी पैटर्न को लागू करने (या प्रदान मौजूदा स्थिर प्रतिलिपि), लेकिन यकीन नहीं है के बारे में सोचा है। क्या यह इसके बारे में जाने का सबसे अच्छा तरीका है?

अत्यधिक संसाधनों का उपभोग किए बिना गति सुनिश्चित करने के लिए मॉडल को संभालने का सही तरीका क्या है? आलसी लोडिंग यहां खेलना चाहिए?

[संपादित करें] एक उदाहरण के रूप में, मैं एक वर्ग है मैं क्वेरी को पार्स करने के लिए एक कच्चे खोज क्वेरी से स्थान के बारे में जानकारी प्राप्त करने को संभालने के लिए इस्तेमाल करते हैं और आदेश में इन वस्तुओं की आवश्यकता है:

// Initialize database object 
$this->dbLocations = new Model_Locations; 
$this->dbStates = new Model_States; 
$this->dbZipcodes = new Model_Zipcodes; 
$this->dbLookup = new Model_Lookup; 

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

Answer 1

मैं DbTable पर काम करते हैं विन्यस्त किया जा सकता जैसे आप करते हैं।मुझे यह प्रभावी लगता है जब मुझे डीबीटेबल के ऊपर मॉडल की एक और परत बनाने के लिए एक ही क्रिया में एकाधिक तालिकाओं की क्वेरी करने की आवश्यकता होती है। एक सेवा या डोमेन परत के समान। इस तरह मुझे केवल एक मॉडल को कॉल करना है, लेकिन मुझे अभी भी कार्यक्षमता की आवश्यकता है।

<?php 

class Application_Model_TrackInfo 
{ 


    protected $_track; 
    protected $_bidLocation; 
    protected $_weekend; 
    protected $_shift; 
    protected $_station; 

    public function __construct() { 
     //assign DbTable models to properties for convience 
     $this->_track = new Application_Model_DbTable_Track(); 

    } 

    /** 
    * 
    * @param type $trackId 
    * @return type object 
    */ 
    public function getByTrackId($trackId) { 

     $trackData = $this->_track->fetchRow($trackId); 
     //getAllInfo() Application_Model_Row_TRack 
     $result = $trackData->getAllInfo(); 
     //returns std object reflecting data from 3 DbTable classes 
     return $result; 
    } 

    /** 
    *Get Station from trackid through bidlocationid 
    * 
    * @param type $trackId 
    * @return type object 
    */ 
    public function getStation($trackId){ 

     $data = $this->_track->fetchRow($trackId); 
     //This a Application_Model_Row_Track method 
     $result= $data->getStationFromBidLocation(); 

     return $result; 
    } 

} 

मुझे आशा है कि इस मदद करता है:

यहाँ एक सरल उदाहरण है कि अंततः 5 DbTable वर्गों और सबसे अधिक संभावना पंक्ति वर्गों में से एक जोड़ी के रूप में अच्छी तरह से के साथ बातचीत कर सकते हैं।

[संपादित करें] जब से मैं इस सवाल का जवाब मैं डोमेन मॉडल और डेटा mappers के लाभ सीखा है लिखा था। वाह मेरे ऐप में क्या अंतर है। एक जादू बुलेट नहीं, लेकिन एक बड़ा सुधार।
ऐलेजैंड्रो Gervasio से अधिक इस पैटर्न को समझने में Surviving The Deepend

अपने सभी की मदद के लिए

पर Akrabat.com
और
Pádraic ब्रैडी पर PHPMaster.com
रोब एलन पर करने के लिए
धन्यवाद।

Answer 2

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

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

जब आप रिकॉर्ड हटाते हैं (यह स्वचालित है) संबंधित फाइलों से पंक्तियों को निकालने की आवश्यकता नहीं है, तो फाइल सिस्टम सिंक्रनाइज़ेशन सुनिश्चित करने के लिए जटिल और अराजक स्क्रिप्ट लिखने की आवश्यकता नहीं है, आप किसी भी समय लगभग किसी भी डीबी इंजन में माइग्रेट कर सकते हैं (mysql , postgresql, simplesql ..) और अधिक ..

मैं सिम्फनी 2 ढांचे के संयोजन के साथ सिद्धांत 2 का उपयोग कर रहा हूं और मुझे कहना है कि मैं किसी भी चीज़ के लिए ज़ेंड वापस नहीं जाऊंगा। हां, यह जटिल और भारी है, लेकिन वास्तव में परम समाधान है। जब आप एक पल में आते हैं तो आपको कुल मिलाकर लाखों रिकॉर्ड के साथ सैकड़ों तालिकाओं का प्रबंधन करने की आवश्यकता होती है - तो आप अंतर देखेंगे।

तो, अंतिम सारांश: ओआरएम आपको जो चाहिए वह है, कई समाधान हैं, मुझे दो वास्तव में अच्छा पता है: सिद्धांत 1 या 2 और प्रोपेल।

पुनश्च: ORM आपके सिस्टम की एक स्वतंत्र हिस्सा है, तो आप वास्तव में एक विशिष्ट ढांचे का उपयोग करने की जरूरत नहीं, Zend शानदार सिद्धांत के साथ काम करने :)