एमवीसी आर्किटेक्चर में डेटा और फॉर्म सत्यापन

Question

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

हालांकि, मैं "पतला नियंत्रक, वसा मॉडल" रेखा सुन रहा हूं - और मुझे आश्चर्य है कि मॉडल के अंदर इन सत्यापन जांचों को रखा जाना चाहिए या नहीं।

जब मैं इस दृष्टिकोण का उपयोग करने के बारे में सोचता हूं तो तीन चीजें मुझे हड़ताल करती हैं।

1. उपयोगकर्ता को अलग-अलग त्रुटि संदेश कैसे दिखाए जा सकते हैं, इन मॉडल फ़ंक्शंस से प्रतीत होता है बदसूरत सरणी या ऑब्जेक्ट्स लौटने के बिना? उदाहरण के लिए साइन अप करने पर एक डुप्लिकेट ईमेल। क्या मॉडल में उपयोगकर्ता को जोड़ने के लिए ज़िम्मेदार विधि को सरणी या ऑब्जेक्ट वापस करना होगा यह इंगित करने के लिए कि क्या सम्मिलन सफल हुआ था, और कोई त्रुटि संदेश?

2. मॉडल में सत्यापन जांच करके, नियंत्रक (POST डेटा नहीं) से विधियों की आपूर्ति की गई चर की जांच करके, मैं फॉर्म प्रमाणीकरण कक्षा का उपयोग खो दूंगा, एक वर्ग जो मुझे मेरी परियोजनाओं में बहुत उपयोगी लगता है । क्या आप सुझाव देंगे कि मैं एक वर्ग, या लाइब्रेरी लिखता हूं जिसे सीआई लाइब्रेरी की तरह फॉर्म वैलिडेशन क्लास की नकल करने के लिए इस्तेमाल किया जा सकता है, लेकिन आपूर्ति किए गए चर के लिए, और पोस्ट डेटा तक ही सीमित नहीं है?

3. उस चिंता के बाद ... चूंकि मॉडल को पारित होने से पहले POST डेटा को अस्तित्व (isset($_POST['myvar'])) के लिए मान्य किया जाना चाहिए, शेष प्रमाणीकरण को नियंत्रक में भी नहीं रखा जाना चाहिए?

कोई सुझाव, सलाह, राय की सराहना की जाएगी!

Answer 1

आपका मूल मुद्दा तथ्य से आता है कि कोडइग्निटर की एमवीसी की व्याख्या काफी भयानक है। यह ढांचा दिखाता है कि व्यू सिर्फ एक टेम्पलेट है, और मॉडल सिर्फ एक ओआरएम (which some say, should be classified as anti-pattern) है। जो पूरी तरह गलत है, और कंट्रोलर के अंदर बॉट व्यवसाय और प्रेजेंटेशन लॉजिक को मजबूर करता है।

लेकिन छोड़ दें छोड़ दें।

एमवीसी में मॉडल कक्षा या वस्तु नहीं है। मॉडल एक परत है, जिसमें सभी व्यावसायिक तर्क शामिल हैं। यह वास्तव में कक्षाओं की भीड़ से उदाहरणों में शामिल है। दो सबसे अधिक प्रचलित समूहों डोमेन   ऑब्जेक्ट्स   ^{[1]   [2]} हैं (यह है लोगों को लोगों को आमतौर पर क्या कहते हैं "मॉडल") और सूचना भंडारण और पुनर्प्राप्ति के लिए जिम्मेदार आपत्ति - आम तौर पर DataMappers। मॉडल परत में स्टैंडअलोन घटक भी होते हैं (आपकी अपनी और तीसरी पार्टी दोनों) और उच्च स्तरीय अवशोषण - सेवाएं।

Validation वर्ग के रूप में, एक स्टैंडअलोन घटक, जो या तो डोमेन वस्तु द्वारा इस्तेमाल किया जा सकता सत्यापन करते हैं, या उम्मीद एक डोमेन वस्तु सत्यापन के लिए पास होने के लिए करने के लिए माना जा सकता है कि आप क्या है .. निर्भर करता है आपके कार्यान्वयन पर

आपकी स्थिति में मैं इसे सेवा परत पर संभाल दूंगा। जो या तो वैध डोमेन ऑब्जेक्ट के साथ View कक्षा का उदाहरण प्रदान करेगा, या एक ऑब्जेक्ट, जो त्रुटि का प्रतिनिधित्व करता है।में रुचि

कुछ पठन सामग्री यू हो सकता है:

• GUI Architectures
• AnemicDomainModel
• Tell, Don't ask

फिर .. क्या नरक मैं यह सब के बारे में पता ..