मल्टी-स्तरीय एप्लिकेशन

Question

के लिए इनपुट डेटा को सत्यापित करने के लिए सर्वोत्तम अभ्यास हमारे आवेदन में हमारे पास विभिन्न परतें हैं। सेवा परत, डीएओ परत और क्रियाएं (स्ट्रैट अनुप्रयोग)।

डेटा एक परत से दूसरे परत तक पारित हो जाता है।

हमें आदर्श रूप से इनपुट सत्यापन क्यों रखना चाहिए?

कहें, उपयोगकर्ता आईडी, यूआई से फोन नंबर आ रहा है, वे अनिवार्य हैं। तो हम पहले से ही ग्राहक पक्ष में सत्यापन कर रहे हैं।

अब, मेरी राय के अनुसार, आपको बस इतना कुछ चाहिए। कहीं और इसे मान्य नहीं किया जाना चाहिए।

लेकिन मेरे सहयोगी में से एक तर्क देता है कि क्या ग्राहक सीधे अनुरोध करता है। इसलिए हमें क्रियाओं में भी जोड़ना होगा।

अब, दाव पर साथ ही साथ, एक ही विधि का किसी अन्य कार्रवाई में इस्तेमाल किया जा रहा है और tht, मान्यता नहीं है

या, सेवा परत, यह के रूप में सामने आ रहा हो सकता है कहते हैं, वेब सेवा के रूप में कहते हैं, तो वहाँ आप भी shd प्रमाणीकरण है।

तो अनिवार्य रूप से, वह सुझाव दे रहा है कि हम shd के पास हर जगह मान्य हैं। जो मेरे लिए समझ में नहीं आता है। परत में इसकी नकल।

इसके लिए आदर्श दृष्टिकोण क्या है? मान लें कि प्रमाणीकरण सरल शून्य जांच या कुछ जटिल सत्यापन हो सकता है।

Answer 1

पेंजे के साथ सहमत हैं, आपको निश्चित रूप से ग्राहक और सेवा अंतराल में सत्यापन होना चाहिए।

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

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

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

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

Answer 2

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

हालांकि, व्यावसायिक सत्यापन हैं जो आपकी डोमेन परत से संबंधित होनी चाहिए और उन्हें आपकी डोमेन सेवा परत या डोमेन ऑब्जेक्ट्स में रहना चाहिए।

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

Answer 3

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