MVC मॉडल को डीबी से शिथिल बनाए रखना?


9

मैं अपने कोड को परीक्षण योग्य रखना पसंद करता हूं और अपने वर्तमान एमवीसी ढांचे के लिए निर्भरता-इंजेक्शन रणनीति के साथ जाने का फैसला किया है, जो निश्चित रूप से शिथिल युग्मित कोड, परीक्षणशीलता और प्रतिरूपकता सुनिश्चित करने का एक शानदार तरीका साबित हुआ है।

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

यह कैसे किया जा सकता है?
जैसा कि मैंने इस प्रश्न के साथ कोई भौतिक कोड प्रदान नहीं किया है, मैं वास्तव में कुछ तर्क / कोड उदाहरण या जानकारी की सराहना करूंगा जो मुझे ऊपर वर्णित समस्या को समझने के लिए एक दिशा में इंगित कर सकते हैं।


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

जवाबों:


6

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

यह पूरी तरह से संभावना है कि आप 90% तक कुछ के साथ समाप्त हो जाएंगे, आप डेटा को कैसे बनाए रखेंगे। कोई बात नहीं। यह युग्मित किए बिना पूरी तरह से समान हो सकता है।

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

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

  1. डेटाबेस - डेटा स्टोर करें, डेटा की अखंडता बनाए रखें, डेटा को आराम से बनाए रखें।
  2. मॉडल - व्यावसायिक तर्क को शामिल करें, समस्या डोमेन को मॉडल करें, गति में डेटा बनाए रखें, व्यवसाय-स्तर की घटनाओं पर प्रतिक्रिया दें, आदि।
  3. दृश्य - उपयोगकर्ताओं के लिए वर्तमान डेटा, उपयोगकर्ता-साइड लॉजिक निष्पादित करें (मॉडल में वास्तविक सत्यापन से पहले मूल सत्यापन किया जाता है, आदि)।
  4. नियंत्रकों - उपयोगकर्ता घटनाओं के प्रति प्रतिक्रिया, मॉडल पर नियंत्रण, मार्ग अनुरोध और वापसी प्रतिक्रियाएं।

हाय डेविड। आपके व्यापक उत्तर के लिए धन्यवाद! ढीले कपलिंग के उच्च स्तर को बनाए रखते हुए, आप मॉडल को डेटाबेस कनेक्टर से कैसे जोड़ेंगे?
औद्योगिक

1
@ इंडस्ट्रियल: मॉडल को दृढ़ता से जोड़ने के कई तरीके हैं, लेकिन अभी तक मैंने जो एकमात्र तरीका पाया है, वह वास्तव में अलग-अलग चिंताओं के लिए मेरी इच्छा को संतुष्ट करता है डोमेन में रिपॉजिटरी इंटरफेस है जो बाहरी रूप से एक डीएएल द्वारा लागू किया जाता है। रिपॉजिटरी तरीके डोमेन मॉडल को स्वीकार करते हैं और वापस करते हैं, और आंतरिक रूप से उन और किसी भी उत्पन्न डेटाबेस संस्थाओं के बीच कनवर्ट करते हैं। (ईमानदार होने के लिए, मैंने PHP में ऐसा नहीं किया है।) इसलिए आप अपने सभी DB CRUD, आदि को ऑटो-जेनरेट करने के लिए एक DAL फ्रेमवर्क का उपयोग कर सकते हैं और फिर उस सामान और आपके मॉडल के बीच एक इंटरफेस के रूप में अपनी रिपॉजिटरी लिख सकते हैं।
डेविड

@ औद्योगिक: उदाहरण के लिए, यदि आप एक ORM का उपयोग करते हैं, तो उस ORM को आपके DAL (जो कि डोमेन मॉडल से अलग-थलग है) द्वारा संदर्भित किया जाएगा और तदनुसार अपने मॉडल को डेटा एक्सेस में बदल देगा। या यदि आप मैन्युअल SQL के साथ सीधे डेटाबेस का उपयोग करते हैं, तो आप ऐसा अपने DAL के रिपॉजिटरी विधियों में करेंगे और SQL क्वेरी के परिणामों को डोमेन मॉडल में वापस करने से पहले उनका अनुवाद करेंगे।
डेविड

@ औद्योगिक: यह भी ध्यान रखें कि रिपॉजिटरी के तरीकों का सिर्फ CRUD होना जरूरी नहीं है। बुद्धि के बहुत से कोड में बेक किया जा सकता है। अधिक जटिल लोगों में बहुत सारे आंतरिक कोड हो सकते हैं जो डेटाबेस से डेटा को बदल देते हैं। या, यदि जटिल डेटाबेस में कई यात्राएं शामिल हैं, तो प्रदर्शन लाभ के लिए आप तर्क को एक संग्रहीत प्रक्रिया में रख सकते हैं और डीएएल विधि बस उस प्रक्रिया से गुजरती है और परिणामों को मॉडल में अनुवाद करती है।
डेविड

हाय डेविड! बस इस जवाब के लिए फिर से धन्यवाद देना चाहता था। निश्चित रूप से सबसे अच्छा मैं StackExchange पर प्राप्त किया है!
औद्योगिक

2

आप दो चीजें करना चाहते हैं।

  1. आपके मॉडल (डीबीएएल के एक्सेसर्स और ऐप लॉजिक के अधिकांश काम कर रहे हैं)।
  2. आपके "डोमेन मॉडल" उर्फ ​​डेटा एंटिटीज, ये आपके सिस्टम की संस्थाओं जैसे उपयोगकर्ता, पोस्ट, उत्पाद आदि का प्रतिनिधित्व करते हैं।

    class PPI_Model_User {
    
        protected $_conn = null;
    
        function __construct(array $options = array()) {
            if(isset($options['dsnData'])) {
                $this->_conn = new PPI_DataSource_PDO($options['dsnData']);
            }
        }
    
        function getAll() {
            $rows = $this->_connect->query("SELECT .....")->fetchAll();
            $users = array();
            foreach($rows as $row) {
                $users[] = new PPI_Entity_User($row);
            }
            return $users;
        }
    
    }

उपयोग कोड

    $model = new PPI_Model_User(array('dsnData' => $dsnData));
    $users = $model->getAll();
    foreach($users as $user) {
        echo $user->getFirstName();
    }

आपके पास यह है, कि आप डोमेन मॉडल (एंटिटी) कैसे बनाते हैं और डीबी कनेक्टिविटी और डेटा हेरफेर करने वाले एमवीसी मॉडल हैं।

यदि आप सोच रहे हैं कि PPI क्या है, तो "PPI फ्रेमवर्क" के लिए Google।

आपकी खोज के लिए शुभकामनाएं।

सादर, पॉल ड्रैगूनिस।


1

याद रखें, MVC स्मालटाक में उत्पन्न हुआ, जिसमें सभी वस्तुओं के लिए स्वचालित दृढ़ता है। इसलिए MVC पैटर्न मॉडल / दृढ़ता पृथक्करण के लिए कोई समाधान नहीं बताता है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.