समस्याओं से बचने के लिए सॉफ्टवेयर कैसे डिज़ाइन करें: वेब फॉर्म डेटा प्रोसेसिंग

इस प्रश्न का उत्तर देते समय, सॉफ़्टवेयर विकास के प्रश्न को पूछना हमेशा आवश्यक होता है। सिस्टम का कौन सा हिस्सा सबसे अधिक बदलने की संभावना है, और जो स्थिर रहने की संभावना है?

हम इस मुद्दे पर उदाहरणों के साथ विचार करेंगे। कई कार्यों पर विचार करें जो नियमित रूप से अधिक या कम बड़ी प्रणालियों में होते हैं। इस प्रकार के कार्य के कारण इस पद के दायरे से बाहर हैं, यहां हम कार्यान्वयन पर ध्यान केंद्रित करते हैं।

वेब फॉर्म डाटा प्रोसेसिंग

प्रपत्र समान हैं: एक फ़ील्ड जोड़ा गया, एक और निकाला गया, संख्याओं के संभावित मानों को काट दिया, केवल लोगों के बजाय कई विकल्प बनाए, आदि। प्रतिनिधित्व के दृष्टिकोण से - एक मामूली बदलाव। आंतरिक तर्क कैसे बदलता है?


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

हम विचार विकसित करेंगे।

आइए रूपों के विकास को देखें। एक नियम के रूप में, (किसी भी संयोजन संभव हैं) की ओर प्रवृत्ति है:

• नई फ़ील्ड्स जोड़ना
• वैकल्पिक फ़ील्ड हटाएं
• प्रसंग परिवर्तन
• अनिवार्य भरना (दोनों दिशाओं में)
• आवश्यक फ़ील्ड हटाएं (= अनिवार्य रूप से बदलें + वैकल्पिक फ़ील्ड हटाएं)
• संभव फ़ील्ड मानों को बदलना, जिसमें मानों के प्रकार को बदलना शामिल है

यहां से निम्नलिखित समस्याएं उत्पन्न हो सकती हैं:

• नया क्षेत्र जोड़ा गया। पहले समान रूपों के लिए फ़ील्ड का सेट समय के साथ पूरी तरह से अलग हो सकता है।
• एक वैकल्पिक फ़ील्ड हटा दिया गया है। बस इस पैरामीटर के हैंडलर को हटा दें। इस क्षेत्र के साथ काम करने के लिए डेटाबेस और कोड में तालिका को साफ करना अच्छा होगा, लेकिन महत्वपूर्ण नहीं।
• क्षेत्र की आवश्यकता थी, वैकल्पिक बन गया। अशक्त के लिए जाँच जीवन को पूरी तरह से बिगाड़ देती है।
• क्षेत्र वैकल्पिक था, अनिवार्य हो गया। समस्या मौजूदा डेटा के साथ है: यदि कोई मूल्य नहीं है, तो इसे कैसे संसाधित किया जाए, लेकिन ऑपरेशन के लिए यह आवश्यक है?
• संभव फ़ील्ड मानों को बदलना, जिसमें मानों के प्रकार को बदलना शामिल है। मुझे लगता है कि समस्याएं स्पष्ट हैं, क्षेत्र के प्रकार पर निर्भर सभी निर्भरताओं को बदलने की आवश्यकता है।

निष्कर्ष क्या हैं?

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

PS निम्नलिखित विषयों में हम रिपोर्ट पीढ़ी, नेटवर्क प्रोटोकॉल के कच्चे डेटा के विश्लेषण और अन्य समस्याओं के बारे में विचार करेंगे।