2010-09-29 16 views
9

का उपयोग करते समय व्यवसाय तर्क कहां रखा जाना चाहिए मेरे पास सिद्धांत 2 और ज़ेंड फ्रेमवर्क से संबंधित एक प्रश्न है।डॉक्ट्राइन 2 और ज़ेंड फ्रेमवर्क

यदि आप डिफ़ॉल्ट रूप से सिद्धांत के बिना ज़ेंड फ्रेमवर्क का उपयोग करते हैं तो आप मॉडल में व्यावसायिक तर्क डालते हैं। लेकिन जैसा कि सिद्धांत 2 में संस्थाएं हैं, जहां व्यापार तर्क रखा जाना चाहिए?

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

 $customerAddress = $this->_model->save($values, $id); 

     $this->_em->persist($customerAddress); 

     // Update default billing address 
     $defaultBilling = $this->_model->saveDefaultBilling($values, $customerAddress); 
     if ($defaultBilling != FALSE) { 
      $this->_em->persist($defaultBilling); 
     } 

     // Update default shipping address 
     $defaultShipping = $this->_model->saveDefaultShipping($values, $customerAddress); 
     if ($defaultShipping != FALSE) { 
      $this->_em->persist($defaultShipping); 
     } 

     $this->_em->flush(); 

किसी कह सकते हैं इस समस्या के लिए सबसे अच्छा अभ्यास क्या:

नीचे कोड एक नियंत्रक कार्रवाई का एक हिस्सा पता चलता है? Thx

+0

मुझे लगता है कि यह सबसे अच्छा है कि सभी सिद्धांत कोड नियंत्रकों के बाहर और डोमेन वर्गों में स्थानांतरित कर दिया जाता है, मेरे ब्लॉग पोस्ट की जाँच करें: http://www.cobbweb.me/2010/11/integrate-doctrine- 2-ज़ेंड-फ्रेमवर्क-एप्लिकेशन/ – Cobby

उत्तर

13

मुझे यकीन नहीं है कि सर्वोत्तम अभ्यास पर सहमति है, लेकिन मुझे डॉक्टर या ज़ेंड फ्रेमवर्क पर चर्चा करते समय सेवा परतों के बारे में बहुत सी बात दिखाई देती है।

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

यदि आप एक सक्रिय रिकॉर्ड दुनिया से आ रहे हैं, तो अपने 'मॉडल' को एक ऑब्जेक्ट के रूप में सोचना आसान है जो डेटाबेस तालिका से मेल खाता है और नियंत्रकों को इन ऑब्जेक्ट्स से बात करनी होती है। यह आमतौर पर बहुत सरल सीआरयूडी अनुप्रयोगों के लिए ठीक है। लेकिन सिद्धांत के दृष्टिकोण के कारण, इसे इस तरह से करना अजीब और निराशाजनक है।

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

मैं सुझाव दूंगा कि आप इस presentation विषय पर देखें।

अद्यतन

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

+0

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

2

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

https://github.com/eddiejaoude/Zend-Framework--Doctrine-ORM--PHPUnit--Ant--Jenkins-CI--TDD-

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