2013-07-01 23 views
12

यह Laravel 4 में मॉडल को मान्य करने आधिकारिक रास्ता की तरह लगता है Controller में Validator के माध्यम से है? क्या कोई यह बता सकता है कि ऐसा क्यों है?Laravel 4 मॉडल सत्यापन बनाम नियंत्रक सत्यापन

यह Model में मान्यता लागू करने के लिए और अधिक मतलब नहीं होता?

+1

मैं आधिकारिक नहीं कहूंगा। एक सभ्य सत्यापन सेवा स्थापित करने के रूप में यह वैधता का प्रदर्शन करने का एक आसान तरीका है थोड़ा और अधिक शामिल है। वहाँ उदाहरणों का एक गुच्छा है साथ ही पैकेज जो मॉडल के भीतर या एक अलग सेवा के रूप में सत्यापन करते हैं। उनको देखो। –

+4

मॉडल सत्यापन के लिए एक लाभ यह है कि बीजिंग भी मान्य है। –

+1

मैं _would_ आधिकारिक दस्तावेज द्वारा सुझाया गया एकमात्र तरीका है। अगर वह आधिकारिक नहीं है, तो और क्या होगा? – igorsantos07

उत्तर

15

मैं मॉडल की प्रमाणीकरण को यथासंभव चिकनी और न्यूनतम के रूप में Ardent पैकेज पसंद करता हूं। मेरे लिए मॉडल में सत्यापन नियमों के साथ-साथ यह अधिक समझ में आता है।

$model->save() कहलाता है और सत्यापन विफल होने पर यह झूठ वापस आ जाएगा, तो आप उदाहरण के लिए $model->errors()->all() के माध्यम से त्रुटि संदेश प्राप्त कर सकते हैं।

+2

मुझे बहुत लारवेलिश लगता है: एक पैकेज का उपयोग करें जो आपके लिए कड़ी मेहनत करता है। –

+0

@NiklasModess क्या आपके पास कोई सुझाव है कि मैं Ardent और अन्य पैकेज का उपयोग कैसे कर सकता हूं जिसका उपयोग मैं कर रहा हूं जो एक मोंगोडीबी ओआरएम की अनुमति देने के लिए इलोकेंट का विस्तार करता है? मेरा मॉडल मॉडल को बढ़ाता है जो इस अन्य पैकेज को बनाया गया है। – Thelonias

+0

@NiklasModess, क्या आप किसी भी पैकेज के बारे में जानते हैं जो मेरे मॉडल को अर्डेंट मॉडल और मोंगोडीबी मॉडल दोनों होने देगी? – Thelonias

5

यह समझ बनाने के मॉडल में सत्यापन के लिए करता है, लेकिन यह मान्यता केवल सुनिश्चित करें कि आप किसी भी भ्रष्ट डेटा को बचाने नहीं करना होना चाहिए।

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

जब नियंत्रक में फ़ॉर्म सत्यापन कर रही है, यदि आप एक मॉडल के प्रयोजन के बदले बिना, सब कुछ आप त्रुटि संदेश के साथ चाहते हैं कर सकते हैं।

और अपने मॉडल में क्या आप वाकई एक गलती है, जो होगा अपने डेटाबेस भ्रष्ट नहीं किया बनाने के लिए एक सत्यापन कर सकते हैं। क्योंकि अगर ऐसा होता है तो आवेदन बंद होना चाहिए।

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

+7

का प्रतिबिंब मुझे लगता है कि केवल एक ही स्थान पर सत्यापन नियमों को परिभाषित करना, और कई स्थानों (मॉडल, नियंत्रक, फ्रंट-एंड फॉर्म) में नहीं, यहां कुंजी है। इस परिदृश्य में मॉडल एक आम बात है। – Jason

+0

मॉडल में "स्वयं नहीं" क्यों होना चाहिए इसके स्वयं के त्रुटि संदेश हैं? यदि आप अपने डीबी के लिए मॉडल के रूप में मॉडल के बारे में सोचते हैं, तो जब आप अपने डीबी एसक्यूएल में अमान्य डेटा डालने का प्रयास करते हैं तो आपको एक त्रुटि संदेश वापस आ जाएगा, जो मॉडल को ऐसा क्यों नहीं करते हैं? –

2

मैंने थोड़ी देर के लिए इसके साथ कुश्ती की और this की लाइनों के आधार पर कुछ सत्यापन के आधार पर मेरी अधिकांश सत्यापन को संभालने पर बस गए। इसके बाद संदर्भ के आधार पर अलग-अलग सत्यापन नियम हो सकते हैं।

निको उल्लेख के रूप में, मॉडल में सत्यापन भ्रष्ट डेटा से बचने के लिए अच्छा है, लेकिन मैं पतली नियंत्रकों को पसंद करते हैं तो मैं कार्यक्षमता है कि सेवा में नियंत्रक में बैठते हैं गुजरती हैं। यह विभिन्न नियंत्रकों/विधियों में सत्यापन का पुन: उपयोग करने में सक्षम होने का लाभ भी है।

0

मैं क्यों पसंद करते हैं इन-मॉडल मान्यता: मैं दोनों शैलियों के साथ काम किया है और प्रत्येक pluses और minuses है, लेकिन मैं इन-मॉडल सत्यापन पसंद करते हैं। हमारे वर्तमान ऐप में मुझे एक विकल्प के रूप में इन-कंट्रोलर सत्यापन दिखाई नहीं देता है, क्योंकि हम अपने डेटा को इतने सारे स्थानों में बदल रहे हैं (समर्पित फॉर्म, इनलाइन संपादन, थोक संपादन, थोक अपलोड, एपीआई आदि)। मैंने वास्तव में सत्यापन सेवाओं के साथ वास्तव में कभी काम नहीं किया है (हालांकि वे एक विकल्प हो सकते हैं) लेकिन मैं व्यक्तिगत रूप से यथासंभव मॉडल के करीब तर्क रखना चाहता हूं, इस तरह से मुझे पता है कि एक और डेवलपर इसे बाईपास नहीं करेगा। मैं एमवीसी और मूल पुस्तकालय फ़ोल्डर के शीर्ष पर बहुत सी अतिरिक्त फाइलें भी जोड़ना पसंद नहीं करता क्योंकि यह ऐसा लगता है कि आपको ठीक से व्यवस्थित करने के बारे में सोचना है।

इन-मॉडल सत्यापन के साथ मुद्दे: ये कुछ चीजें हैं जिन्हें आपको इन-मॉडल काम को अच्छी तरह से बनाने के लिए विचार करने की आवश्यकता है। इनमें से कुछ पहले प्लगइन द्वारा विचार-विमर्श में लिया गया है। मुझे लगता है कि अन्य ढांचे (केकेपीएचपी) पहले से ही इनसे निपटते हैं, लेकिन लैरावेल वास्तव में नहीं है।

  1. मान जिन्हें सत्यापित किया जाएगा लेकिन डीबी में सहेजा नहीं जाएगा (उदाहरण के लिए, "स्वीकृत_गॉबिटी")।
  2. कई लोगों के लिए कई या कई रिश्तों
  3. सशर्त चूक (महत्वपूर्ण नहीं लेकिन एक ही समय में के बारे में सोचना चाहते हो सकता है)
  4. विभिन्न प्रपत्र परिदृश्यों की स्थापना के अंतर्गत आता है - कभी कभी आप अलग अलग मान्यता जो के आधार पर आवश्यकता हो सकती है फॉर्म इसे प्रस्तुत करता है। प्रपत्र संदर्भ प्रमाणीकरण के लिए शुद्ध करने योग्य विशेषता हो सकता है?
  5. कैसे आपको त्रुटि संदेश वापस मिल जाएगा (सभी में मॉडल सत्यापन प्लगइन्स यह आपके लिए संभाल)
  6. विभिन्न मान्यता rulesets। ड्राफ्ट निर्माण बनाम "असली" सृजन। (अधिकांश आप के लिए इस संभाल)

अंत में, सरल अनुप्रयोगों मॉडल के साथ बातचीत करने के तरीके, मैं कहेंगे नियंत्रक सत्यापन आसान हो सकता की बहुत सारी की जरूरत नहीं है कि के लिए, अन्य तो मैं में पसंद करते हैं कि -आदर्श।

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