प्रपत्र प्रसंस्करण तर्क एक एमवीसी वेब अनुप्रयोग में कहां से संबंधित है?

Question

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

इस अवधारणा का सबसे अच्छा तरीका क्या है? मॉडल और नियंत्रकों के बीच रूपों का एक प्रकार का गोंद है? या एम या सी शिविर में फॉर्म तर्क स्क्वायर से संबंधित है?

संपादित करें: मैं एक एमवीसी अनुप्रयोग में जानकारी के मूल प्रवाह को समझता हूं (सारांश के लिए chills42 के जवाब देखें)। मेरा सवाल यह है कि प्रपत्र प्रसंस्करण तर्क संबंधित है - नियंत्रक में, मॉडल में, या कहीं और?

Answer 1

मैं कहना चाहता हूँ कि यह शायद 2 अलग कार्रवाई के रूप में देखा जाना चाहिए ...

1. पर्चे को जमा (वी -> सी)
2. प्रविष्टि को संसाधित करने (सी -> एम)

जेनरिक में बात हो रही है, मैं वर्गों के बीच संदेश के रूप में प्रत्येक कार्रवाई के रूप में सोचने के लिए करते हैं। संदेशों के पूर्ण श्रृंखला कुछ इस तरह होगा ...

• प्रदर्शन फॉर्म (सी -> वी)
• उपयोगकर्ता (वी -> सी) द्वारा प्रस्तुत
• प्रक्रिया सामग्री (सी -> एम)
• प्रसंस्करण समाप्त हो गया (एम -> सी)
• प्रदर्शन परिणाम (सी -> वी)

Answer 2

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

Answer 3

मॉडल प्रसंस्करण मॉडल में होना चाहिए, क्योंकि यह उस एप्लिकेशन की परत है जो विचारों के माध्यम से नियंत्रकों से डेटा प्राप्त और प्रसंस्करण कर रहा है। नियंत्रक इसे चारों ओर ले जाता है, लेकिन वास्तविक कोड निष्पादन के लिए, यह आपके मॉडल में हो रहा है।

Answer 4

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

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

नियंत्रक में, कोड इस तरह हो जाता है।

class User_controller 
{ 

    function login() 
    { 
     $form = new LoginForm(); // this is the class you would create 
     if ($form->validate()) 
     { 
      $data = $this->user_model->getUserData($form->userid); 
      // form processing complete, use the main "user" model to fetch userdata for display, 
      // or redirect user to another page, update your session, anything you like 
     } else { 
      $form->display(); 
     } 
    } 
} 

फॉर्म क्लास में डिस्प्ले विधि अपना स्वयं का दृश्य लोड करती है, और पोस्ट बैक डेटा वांछित के रूप में पॉप्युलेट करती है। इसके बाद के संस्करण का उपयोग करके, वहाँ कुछ फायदे हैं:

• यदि प्रपत्र प्रदर्शित करने या प्रसंस्करण परिवर्तन की जरूरत है अपने मुख्य नियंत्रक को बदलने की जरूरत नहीं है।

• आप या तो

• नियंत्रक स्वच्छ रहता है अपने उपयोगकर्ता मॉडल बदल सकते हैं और मुख्य पृष्ठ पर तर्क संभाल

• उपयोगकर्ता मॉडल की साफ रहता है और केवल डाटाबेस के साथ सूचना का आदान प्रदान करने की जरूरत नहीं

ढांचे को स्वयं अपडेट किया जा सकता है ताकि वेबफॉर्म को

$ यह-> loa का उपयोग करके लोड किया जा सके। डी> प्रपत्र ("के लिए लॉग इन"); ......

हालांकि, यह केवल एक सुझाव है जो कोडिनेटर टीम के लिए उपयोगी है।