आप अपना सत्यापन कहां करते हैं?

Question

उम्मीद है कि आप नीचे दी गई परिदृश्य में बताई गई समस्या को देखेंगे। यदि यह स्पष्ट नहीं है, तो कृपया मुझे बताएं।

आप एक आवेदन है कि तीन स्तरों में टूट गया है मिल गया है,

• सामने के छोर यूआई परत, asp.net वेबफ़ॉर्म, या खिड़की (संपादन व्यक्ति डेटा के लिए प्रयोग)
• मध्य स्तरीय व्यापार सेवा हो सकता है परत, एक dll में संकलित (PersonServices)
• डेटा का उपयोग परत, एक dll (PersonRepository)

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

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

तो, सादगी के लिए, मैं निम्नलिखित सत्यापन जांच प्रदर्शन करने के लिए PersonService.AddPerson विधि को अपडेट कर देंगे - देखें कि क्या प्रथम नाम और अंतिम नाम खाली नहीं हैं - इस नए व्यक्ति पहले से ही अपने भंडार में मौजूद नहीं है सुनिश्चित करें

और यह विधि सही हो जाएगी यदि सभी सत्यापन पास हो जाते हैं और व्यक्ति जारी रहता है, तो गलत होने पर वैधता विफल होती है या यदि व्यक्ति जारी नहीं रहता है।

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

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

• इसके बजाय AddPerson एक बूलियन लौटने का

  , यह एक पूर्णांक लौट सकते हैं (यानी 0 = सफलता, गैर शून्य विफलता के बराबर होती है और संख्या का कारण यह दर्शाता क्यों यह असफल।

• AddPerson में, सत्यापन विफल होने पर कस्टम अपवाद फेंक दें। प्रत्येक प्रकार के कस्टम अपवाद का अपना त्रुटि संदेश होगा। इसके अलावा, प्रत्येक कस्टम अपवाद डब्ल्यू पर्याप्त अद्वितीय यूआई परत में पकड़ने के लिए हो ould

• Have AddPerson का संकेत सत्यापन पारित कर दिया या असफल है कि क्या गुण होता है कि कस्टम वर्ग के कुछ प्रकार वापसी, और अगर यह असफल क्यों हुआ, कारणों

• नहीं हैं कि क्या थे सुनिश्चित करें कि यह वीबी या सी # में किया जा सकता है, लेकिन व्यक्ति और उसके अंतर्निहित गुणों को किसी प्रकार की संपत्ति संलग्न करें।यह "संलग्न" संपत्ति बातें सत्यापन की जानकारी

• की तरह हो सकता है एक और यहाँ घना प्रश्न के लिए

क्षमा याचना को रख सकती अपने विचार या यहाँ पैटर्न

डालें और, लेकिन मैं निश्चित रूप से इस पर आपकी राय सुनना पसंद करता हूं।

धन्यवाद!

Answer 1

बहु-परत ऐप्स के साथ सत्यापन की कई परतें अच्छी तरह से चलती हैं।

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

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

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

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

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

Answer 2

इनमें से बहुत से पदार्थ की तुलना में अधिक शैली है। मैं व्यक्तिगत रूप से एक लचीला और एक्स्टेंसिबल समाधान के रूप में लौटने की स्थिति वस्तुओं का पक्ष लेता हूं। मैं कहूंगा कि मुझे लगता है कि खेल में सत्यापन के कुछ वर्ग हैं, पहला "क्या यह व्यक्ति डेटा किसी व्यक्ति के अनुबंध के अनुरूप है?" और दूसरा "क्या यह व्यक्ति डेटा डेटाबेस में बाधाओं का उल्लंघन करता है?" मुझे लगता है कि पहला सत्यापन क्लाइंट पर किया जा सकता है। दूसरा मध्य स्तर पर किया जाना चाहिए। इस प्रभाग के साथ, आप पाएंगे कि सहेजने में विफल होने का एकमात्र कारण 1) एक विशिष्टता बाधाओं का उल्लंघन करता है, या 2) कुछ विनाशकारी। फिर आप पहले मामले के लिए झूठी वापसी कर सकते हैं, और दूसरे के लिए अपवाद फेंक सकते हैं।

Answer 3

केवल महत्वपूर्ण बिंदु हैं:

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

में करने की जगह लेना चाहिए

Answer 4

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

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

** मोबाइल देव, Silverlight, आवाज एक्सएमएल, जो कुछ भी - नाटक आप अपने 'नई' यूआई परत की तकनीक नहीं जानते कि तुम अपनी चिंताओं सार और कम कार्यान्वयन विवरण में फंस गई हो मदद करता है।

Answer 5

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

यह आपके डेटाबेस को पूरी तरह से आपके नियंत्रण में मानता है। यदि नहीं, तो आपको बड़ी समस्याएं हैं।

Answer 6

इसके अलावा, आप यूआई को किसी प्रकार की व्यक्ति बिल्डर ऑब्जेक्ट के माध्यम से किसी व्यक्ति ऑब्जेक्ट को बनाने के लिए आवश्यक डेटा पास कर सकते हैं, ताकि ऑब्जेक्ट सृजन डोमेन/व्यवसाय परत में समेकित हो, और आप व्यक्ति वस्तु को किसी राज्य में रख सकें यह हमेशा सुसंगत है। यह अधिक जटिल इकाइयों के लिए अधिक समझ में आता है, हालांकि सरल लोगों के लिए भी, ऑब्जेक्ट सृजन को केंद्रीकृत करना अच्छा होता है, जैसे आप दृढ़ता को केंद्रीकृत करते हैं, आदि

Answer 7

प्रमाणीकरण सभी तीन स्तरों पर किया जाना चाहिए।

मैं जब मैं एक परियोजना में हूँ मान मैं एक रूपरेखा है, जो समय के सबसे अधिक मामला नहीं है बनाने रहा हूँ।प्रत्येक परत अलग होती है और ऑपरेशन करने से पहले सभी परतों इनपुट को जांचना चाहिए

प्रत्येक स्तर के पास ऐसा करने का एक अलग तरीका हो सकता है, यह आवश्यक नहीं है कि वे सभी इसका उपयोग करें, लेकिन आदर्श रूप से उन्हें सभी के साथ समान सत्यापन का उपयोग करना चाहिए इसे अनुकूलित करने की क्षमता।

आप कभी भी डेटाबेस में खराब डेटा नहीं देना चाहते हैं। तो आप व्यापार परत से प्राप्त डेटा पर भरोसा नहीं कर सकते हैं। इसे जांचने की जरूरत है।

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

Answer 8

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