MVC में एक मॉडल सत्यापन को संभालना चाहिए?

Question

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

class AM_Products extends AM_Object 
{
    public function save( $new_data = array() ) 
    {
        // Save code
    }
}

पहला प्रश्न: तो मैं सोच रहा हूं कि क्या मेरे सेव मेथड को $ new_data पर सत्यापन फ़ंक्शन को कॉल करना चाहिए या मान लेना चाहिए कि डेटा पहले से ही मान्य है?

इसके अलावा, यदि यह सत्यापन की पेशकश करने के लिए था, तो मैं सोच रहा हूं कि डेटा प्रकारों को परिभाषित करने के लिए कुछ मॉडल कोड इस तरह दिखाई देंगे:

class AM_Products extends AM_Object
{
    protected function init() // Called by __construct in AM_Object
    {
        // This would match up to the database column `age`
        register_property( 'age', 'Age', array( 'type' => 'int', 'min' => 10, 'max' => 30 ) ); 
    }
}

दूसरा प्रश्न: AM_Object का प्रत्येक बाल वर्ग उस विशिष्ट ऑब्जेक्ट के डेटाबेस में प्रत्येक कॉलम के लिए register_property चलाएगा। मुझे यकीन नहीं है कि यह करने का एक अच्छा तरीका है या नहीं।

तीसरा प्रश्न: यदि मान्यता को मॉडल द्वारा संभाला जाना चाहिए, तो क्या उसे एक त्रुटि संदेश या एक त्रुटि कोड वापस करना चाहिए और क्या किसी उपयुक्त संदेश को प्रदर्शित करने के लिए कोड का उपयोग करना चाहिए?

Answer 1

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

यही है, नियंत्रक को उपयोगकर्ता डेटा का अनुवाद करना होगा (जो कि ज्यादातर समय बस तार है) कुछ सार्थक में। इसके लिए पार्सिंग की आवश्यकता होती है (और लोकेल के रूप में ऐसी चीजों पर निर्भर हो सकता है, यह देखते हुए कि उदाहरण के लिए, विभिन्न दशमलव ऑपरेटर आदि हैं)।
तो वास्तविक सत्यापन, जैसा कि "डेटा अच्छी तरह से बनता है?", नियंत्रक द्वारा किया जाना चाहिए। हालांकि, सत्यापन, "क्या डेटा समझ में आता है?" मॉडल के भीतर प्रदर्शन किया जाना चाहिए।

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

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

दूसरा उत्तर: दृष्टिकोण समझ में आता है, हालाँकि इस पद्धति को और अधिक शक्तिशाली बनाया जा सकता है। अंतिम पैरामीटर एक सरणी होने के बजाय, यह एक उदाहरण होना चाहिए, IContstraintजिसे निम्न के रूप में परिभाषित किया गया है:

interface IConstraint {
     function test($value);//returns bool
}

और संख्या के लिए आपके पास कुछ हो सकता है

class NumConstraint {
    var $grain;
    var $min;
    var $max;
    function __construct($grain = 1, $min = NULL, $max = NULL) {
         if ($min === NULL) $min = INT_MIN;
         if ($max === NULL) $max = INT_MAX;
         $this->min = $min;
         $this->max = $max;
         $this->grain = $grain;
    }
    function test($value) {
         return ($value % $this->grain == 0 && $value >= $min && $value <= $max);
    }
}

इसके अलावा, मैं यह नहीं देखता कि 'Age'ईमानदार होने का क्या मतलब है। क्या यह वास्तविक संपत्ति का नाम है? मान लें कि डिफ़ॉल्ट रूप से एक कन्वेंशन है, पैरामीटर फ़ंक्शन के अंत में सरल जा सकता है और वैकल्पिक हो सकता है। यदि सेट नहीं किया जाता है, तो यह DB कॉलम नाम के to_camel_case को डिफ़ॉल्ट करेगा ।

इस प्रकार उदाहरण कॉल की तरह दिखेगा:

register_property('age', new NumConstraint(1, 10, 30));

इंटरफेस का उपयोग करने का मुद्दा यह है कि आप अधिक से अधिक बाधाओं को जोड़ सकते हैं क्योंकि आप जाते हैं और वे जितना चाहें उतना जटिल हो सकते हैं। एक स्ट्रिंग के लिए एक नियमित अभिव्यक्ति से मेल खाने के लिए। एक तारीख के लिए कम से कम 7 दिन आगे होना चाहिए। और इसी तरह।

तीसरा उत्तर: प्रत्येक मॉडल इकाई की तरह एक विधि होनी चाहिए Result checkValue(string property, mixed value)। डेटा सेट करने से पहले नियंत्रक को इसे कॉल करना चाहिए । Resultचाहे जांच में विफल बारे में सभी जानकारी होनी चाहिए, और मामले यह किया है,, कारण बता तो नियंत्रक को देखने के लिए उन तदनुसार प्रचार कर सकते हैं।
यदि मॉडल के लिए एक गलत मान पारित किया गया है, तो मॉडल को केवल एक अपवाद बढ़ाकर जवाब देना चाहिए।

Comments

इस लिखने के लिए धन्यवाद। इसने MVC के बारे में बहुत सी बातें स्पष्ट कीं।

— AmadeusDrZaius

Answer 2

मैं "back2dos" से पूरी तरह सहमत नहीं हूं: मेरी सिफारिश हमेशा एक अलग रूप / सत्यापन परत का उपयोग करने की है, जिसे नियंत्रक मॉडल में भेजे जाने से पहले इनपुट डेटा को मान्य करने के लिए उपयोग कर सकता है।

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

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

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

इसे भी देखें: https://lastzero.net/2015/11/why-im-using-a-separate-layer-for-input-data-validation/

Comments

सादगी के लिए, हमें मान लेना चाहिए कि एक मान्य वर्ग परिवार है, और यह सभी मान्यताएँ एक रणनीतिक पदानुक्रम के साथ की जाती हैं। कंक्रीट सत्यापनकर्ता बच्चे भी विशेष सत्यापनकर्ताओं से बने हो सकते हैं: ई-मेल, फोन नंबर, फॉर्म टोकन, कैप्चा, पासवर्ड, और अन्य। नियंत्रक इनपुट सत्यापन दो प्रकार के होते हैं: 1) एक नियंत्रक और विधि / कमांड के अस्तित्व को सत्यापित करना, और 2) डेटा की प्रारंभिक परीक्षा (यानी HTTP अनुरोध विधि, कितने डेटा इनपुट? (बहुत सारे? बहुत कम?)

— एंथनी रटलेज

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

— एंथनी रटलेज

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

— एंथनी रटलेज

कहा जा रहा है कि, अधिकतम इनपुट आकार के मुद्दों को संबोधित करने से पहले, एन्कोडिंग अच्छा होना चाहिए। सभी बातों पर विचार किया जाता है, यह मॉडल के काम करने के लिए बहुत अधिक है, भले ही काम समझाया जाए। दुर्भावनापूर्ण अनुरोधों को अस्वीकार करना अनावश्यक रूप से महंगा हो जाता है। सारांश में, नियंत्रक को मॉडल को भेजने के लिए अधिक जिम्मेदारी लेने की आवश्यकता है। नियंत्रक स्तर की विफलता घातक होनी चाहिए, जिसमें 200 ओके के अलावा अन्य आवश्यक जानकारी नहीं है। गतिविधि लॉग करें। एक घातक अपवाद फेंको। सभी गतिविधि समाप्त करें। जितनी जल्दी हो सके सभी प्रक्रियाओं को रोकें।

— एंथनी

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

— एंथनी रटलेज ने

Answer 3

हां, मॉडल को सत्यापन करना चाहिए। UI को इनपुट को भी मान्य करना चाहिए।

यह स्पष्ट रूप से मान्य मूल्यों और राज्यों को निर्धारित करने के लिए मॉडल की जिम्मेदारी है। कभी-कभी ऐसे नियम अक्सर बदल जाते हैं। उस स्थिति में मैं मॉडल को मेटाडेटा और / या से सजाता हूँ।

Comments

उन मामलों के बारे में जिनमें उपयोगकर्ता का इरादा स्पष्ट रूप से दुर्भावनापूर्ण है, या गलती से? उदाहरण के लिए, एक विशेष HTTP अनुरोध में सात (7) इनपुट मानों से अधिक नहीं होना चाहिए, लेकिन आपका नियंत्रक सत्तर (70) मिलता है। क्या आप वास्तव में अनुरोध को स्पष्ट रूप से भ्रष्ट होने पर मॉडल को हिट करने के लिए अनुमत मूल्यों की संख्या को दस गुना (10x) की अनुमति देने जा रहे हैं? इस मामले में, यह संपूर्ण अनुरोध की स्थिति है जो किसी विशेष मूल्य के राज्य की नहीं, बल्कि प्रश्न में है। गहराई की रणनीति में एक बचाव यह सुझाव देगा कि मॉडल से डेटा भेजने से पहले HTTP अनुरोध की प्रकृति की जांच की जानी चाहिए।

— एंथनी रटलेज

(जारी) इस प्रकार, आप जाँच नहीं कर रहे हैं कि विशेष उपयोगकर्ता द्वारा दिए गए मान और राज्य मान्य हैं, लेकिन अनुरोध की समग्रता मान्य है। अभी तक, नीचे ड्रिल करने की कोई आवश्यकता नहीं है। तेल पहले से ही सतह पर है।

— एंथनी रटलेज

(जारी) फ्रंट-एंड सत्यापन को मजबूर करने का कोई तरीका नहीं है। किसी को इस बात पर विचार करना चाहिए कि स्वचालित टूल का उपयोग आपके वेब एप्लिकेशन के साथ किया जा सकता है।

— एंथोनी रटलेज 21

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

— एंथनी

Answer 4

बड़ा अच्छा सवाल!

विश्व व्यापी वेब विकास के संदर्भ में, यदि आपने निम्नलिखित प्रश्न पूछे हों, तो भी।

"यदि खराब यूजर इनपुट को यूजर इंटरफेस से कंट्रोलर को सप्लाई किया जाता है, तो क्या कंट्रोलर को एक प्रकार के चक्रीय लूप में व्यू को अपडेट करना चाहिए, कमांड और इनपुट डेटा को प्रोसेस करने से पहले सटीक होना चाहिए ? कैसे? सामान्य के तहत अपडेट कैसे देखा जाता है? शर्तें? क्या किसी मॉडल को कसकर देखा जा सकता है? क्या उपयोगकर्ता इनपुट मॉडल के सत्यापन का मुख्य व्यवसाय तर्क है, या क्या यह इसके लिए प्रारंभिक है और इस प्रकार नियंत्रक के अंदर होना चाहिए (क्योंकि उपयोगकर्ता इनपुट डेटा अनुरोध का हिस्सा है)?

(जब तक अच्छा इनपुट हासिल न हो जाए, तब तक किसी मॉडल को तुरंत तैयार करने में देरी हो सकती है?)

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

सारांश।

1) अपने मार्ग को मान्य करें (URL से पार्स किया गया), क्योंकि नियंत्रक और विधि मौजूद होना चाहिए इससे पहले कि कुछ और आगे बढ़ सके। यह वास्तविक नियंत्रक के सामने आने से पहले फ्रंट-कंट्रोलर दायरे (राउटर क्लास) में निश्चित रूप से होना चाहिए। ओह। :-)

2) एक मॉडल में इनपुट डेटा के कई स्रोत हो सकते हैं: एक HTTP अनुरोध, एक डेटाबेस, एक फ़ाइल, एक एपीआई और हां, एक नेटवर्क। यदि आप अपने सभी इनपुट सत्यापन को मॉडल में रखने जा रहे हैं, तो आप प्रोग्राम के लिए HTTP अनुरोध इनपुट सत्यापन को व्यावसायिक आवश्यकताओं का हिस्सा मानते हैं । मामला समाप्त।

3) फिर भी, अगर HTTP अनुरोध इनपुट अच्छा नहीं है , तो बहुत सी वस्तुओं को तत्काल खर्च करने के माध्यम से जाना मैओपिक है ! आप यह जान सकते हैं कि क्या ** HTTP अनुरोध इनपुट ** अच्छा है ( यह अनुरोध के साथ आया था ) मॉडल और उसकी सभी जटिलताओं (हां, शायद एपीआई और डीबी इनपुट / आउटपुट डेटा के लिए और भी अधिक सत्यापनकर्ता) को सत्यापित करने से पहले इसे सत्यापित करके।

निम्नलिखित का परीक्षण करें:

क) HTTP अनुरोध विधि (GET, POST, PUT, PATCH, DELETE ...)

बी) न्यूनतम HTML नियंत्रण (क्या आपके पास पर्याप्त है?)।

c) अधिकतम HTML नियंत्रण (क्या आपके पास बहुत अधिक है?)।

डी) सही HTML नियंत्रण (क्या आपके पास सही हैं?)।

ई) इनपुट एन्कोडिंग (आमतौर पर, एन्कोडिंग UTF-8 है?)।

च) अधिकतम इनपुट आकार (किसी भी इनपुट की सीमा से बाहर है?)।

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

मैंने यहां जो कुछ भी वर्णित किया है, वह नियंत्रक के माध्यम से आने वाले अनुरोध के इरादे से हिट होता है। आशय के सत्यापन को स्वीकार करने से आपका आवेदन अधिक कमजोर हो जाता है। इरादा केवल अच्छा हो सकता है (आपके मूलभूत नियमों से खेलना) या बुरा (आपके मूलभूत नियमों के बाहर जाना)।

एक HTTP अनुरोध के लिए इरादा एक सब या कुछ नहीं प्रस्ताव है। सब कुछ गुजरता है, या अनुरोध अमान्य है । मॉडल को कुछ भी भेजने की आवश्यकता नहीं है।

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

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

4) इसका मतलब यह है कि HTTP अनुरोध इनपुट डेटा एप्लिकेशन के व्यावसायिक तर्क का हिस्सा नहीं है? नहीं, इसका मतलब यह है कि कंप्यूटर परिमित उपकरण हैं और संसाधनों का बुद्धिमानी से उपयोग किया जाना चाहिए। यह जल्द ही नहीं बल्कि दुर्भावनापूर्ण गतिविधि को रोकने के लिए समझ में आता है। आप बाद में इसे रोकने के लिए प्रतीक्षा करने के लिए गणना संसाधनों में अधिक भुगतान करते हैं।

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

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

6) तो, मेरे पैसे के लिए, HTTP अनुरोध (METHOD, URL / मार्ग, और डेटा) या तो सभी अच्छे हैं, या कुछ और नहीं आगे बढ़ सकते हैं। एक मजबूत मॉडल में पहले से ही अपने आप को चिंता करने के लिए सत्यापन कार्य हैं, लेकिन एक अच्छा संसाधन चरवाहा कहता है "मेरा तरीका है, या उच्च तरीका है। सही आओ, या बिल्कुल मत आओ।"

हालांकि यह आपका कार्यक्रम है। "इसे करने का एक से अधिक तरीका है।" कुछ तरीके दूसरों की तुलना में समय और धन में अधिक खर्च होते हैं। HTTP (बाद में मॉडल में) डेटा का अनुरोध करना एक आवेदन के जीवनकाल में अधिक खर्च करना चाहिए (खासकर अगर ऊपर या बाहर स्केलिंग)।

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

कुछ इसे पूरी तरह से गलत नेतृत्व के रूप में देखते हैं, लेकिन जब चार के गैंग ने डिज़ाइन पैटर्न: रि-यूजेबल ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर के तत्वों को लिखा था, तो HTTP अपनी प्रारंभिक अवस्था में था ।

================================================== ========================

अब, चूंकि यह सामान्य उपयोगकर्ता इनपुट सत्यापन (HTTP अनुरोध के बाद वैध माना गया है) से संबंधित है, यह उपयोगकर्ता को गड़बड़ करने के बारे में सोचने के लिए अद्यतन कर रहा है! इस प्रकार के उपयोगकर्ता इनपुट सत्यापन मॉडल में होने चाहिए।

आपके सामने के छोर पर जावास्क्रिप्ट की कोई गारंटी नहीं है। इसका मतलब है कि आपके पास त्रुटि स्थितियों के साथ अपने एप्लिकेशन के UI के अतुल्यकालिक अपडेट की गारंटी देने का कोई तरीका नहीं है। सच प्रगतिशील वृद्धि तुल्यकालिक उपयोग के मामले को भी कवर करेगी।

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

अद्यतन : आरेख में, मैं कहता हूं कि Viewसंदर्भ देना चाहिए Model। नहीं, आपको ढीले युग्मन को संरक्षित करने के लिए Viewसे डेटा पास करना चाहिए Model।