2011-11-19 9 views
5

मैं PHP में एक एमवीसी अनुप्रयोग पर काम कर रहा हूं जो किसी भी ढांचे का उपयोग नहीं कर रहा है। मैं अपने ओआरएम के लिए RedBean का उपयोग कर रहा हूं, जो डेटामैपर पैटर्न लागू करता है और doctrine से काफी समान काम करता है।क्या मुझे एमवीसी में मॉडल और ओआरएम को पूरी तरह से अलग करना चाहिए?

इस question के अनुसार, मैं समझता हूं कि मॉडल ओआरएम ऑब्जेक्ट नहीं है।

  • "जटिल" मॉडल जो डेटाबेस में तालिकाओं का एक बहुत कुछ के साथ बात करने की आवश्यकता:

    • इन मॉडलों में से एक RBAC अनुमतियाँ की तरह कुछ हो सकता है अपने प्रोजेक्ट में मैं निम्न परिदृश्यों है प्रणाली। यह निर्धारित करने के लिए कि उपयोगकर्ता को अनुरोधित कार्रवाई करने की अनुमति है या नहीं, एक नियंत्रक $permission->isAllowed($controller, $action, $resource) जैसे कुछ कॉल करने में सक्षम होना चाहिए। इसके अलावा, उपयोगकर्ता के पास अनुमतियों की सूची प्राप्त करने के लिए वह $permission->getPermissions() पर कॉल कर सकता है।
  • "सरल" मॉडल जहां मॉडल आम तौर पर डेटाबेस में 1 टेबल द्वारा दर्शाया जा सकता:

    • एक ऐसी मॉडल User मॉडल होगा। उदाहरण के लिए $user->changeRank(), $user->addPoints() और इसी तरह।

समस्या मैं अब का सामना करना पड़ रहा विभिन्न चौखटे के लिए सबसे प्रलेखन को देखते हुए, मुझे लगता है कि देख सकते हैं कि उदाहरण में है, ORM के साथ सीधे नियंत्रक बात करती है।

public function createAction() 
{ 
    $product = new Product(); 
    $product->setName('A Foo Bar'); 
    $product->setPrice('19.99'); 
    $product->setDescription('Lorem ipsum dolor'); 

    $em = $this->getDoctrine()->getEntityManager(); 
    $em->persist($product); 
    $em->flush(); 

    return new Response('Created product id '.$product->getId()); 
} 

एक ORM नहीं मॉडल, क्यों नियंत्रक इसके साथ सीधे बातचीत करने के लिए अनुमति दी है है, तो: उदाहरण के लिए, यहाँ symfony2 से एक उदाहरण नियंत्रक है? क्या ऐसा मॉडल दिखने वाला मॉडल नहीं होना चाहिए?

class ProductModel{ 
    public function newProduct($name, $price, $description){ 
     $product = new Product(); 
     $product->setName('A Foo Bar'); 
     $product->setPrice('19.99'); 
     $product->setDescription('Lorem ipsum dolor'); 

     $em = $this->getDoctrine()->getEntityManager(); 
     $em->persist($product); 
     $em->flush(); 
    } 
} 

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

+1

शानदार सवाल। –

उत्तर

2

मॉडल फ़ाइलों को उत्पन्न करने के लिए एक ओआरएम (ऑब्जेक्ट रिलेशनल मैपर) का उपयोग किया जाता है। मॉडल फ़ाइलों का उपयोग एप्लिकेशन और डेटाबेस (मॉडल) के बीच संवाद करने के लिए किया जाता है। ऐसा लगता है कि आप ओआरएम प्रक्रियाओं से अवगत हैं, लेकिन एक त्वरित पुनः-टोपी (उदाहरण के रूप में सिद्धांत का उपयोग करके), जो हो सकता है, और मैं भाग्यशाली हो सकता हूं और आपके प्रश्न का उत्तर दे सकता हूं।

आप अपने डेटाबेस स्कीमा का निरीक्षण करने के लिए ओआरएम का उपयोग करते हैं, जो स्कीमा फ़ाइल उत्पन्न करता है। अब इस स्कीमा फ़ाइल के साथ आप इसे अपने आवेदन की जरूरतों के अनुसार बदल सकते हैं। उदाहरण के लिए, आप actAs: { Timestampable ~}, या actAs: NestedSet: hasManyRoots: true जोड़ सकते हैं। साथ ही, आप इस स्कीमा फ़ाइल का उपयोग करना चाहते हैं कि आप ऑब्जेक्ट्स के बीच संबंधों को कैसे व्यवहार करना चाहते हैं (यानी 1: एम, एम: एम refClass इत्यादि का उपयोग कर)

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

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

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

संपादित करें ---

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

+0

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

+0

@phpdev: क्या आप विशेष रूप से सिद्धांत का जिक्र कर रहे हैं? –

+0

हां। मेरे पास कुछ मॉडल हैं जो डेटाबेस से बिल्कुल संपर्क नहीं करते हैं, इसलिए उन्हें इकाई प्रबंधक की आवश्यकता नहीं होगी। – F21

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