डिज़ाइन लॉजिक का कार्यान्वयन

कार्यान्वयन दृष्टिकोण दर्शन

झरना दृष्टिकोण

किसी एप्लिकेशन को लागू करने के लिए वॉटरफॉल दृष्टिकोण के लिए एक डिजाइनर को अंतिम-उपयोगकर्ता संगठन के एक या अधिक प्रतिनिधियों के साथ परामर्श करने और एप्लिकेशन के सभी विनिर्देशों को लिखने की आवश्यकता होती है। आमतौर पर, विशिष्टताएँ कार्यात्मक दस्तावेज़ों या उपयोग के मामलों के एक सेट में आती हैं, जो इस तरह से लिखी जाती हैं कि अंतिम उपयोगकर्ता दस्तावेज़ों को आसानी से पढ़ और समझ सके।

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

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

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

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

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

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

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

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

फुर्तीली विकास

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

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

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

वृद्धिशील विकास

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

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

कार्यक्रम प्रवाह नियंत्रण

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

आयोजक कोड

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

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

प्रोजेक्ट बनाना

परतें

पहला कदम तार्किक परतों पर विचार करना है। ध्यान दें कि परतें परतों के समान नहीं होती हैं, अक्सर भ्रमित होती हैं या यहां तक कि उन्हें समान माना जाता है।

परतें बनाम परतें

परतें आपके कोड में सीमाएँ बनाने के बारे में हैं। शीर्ष परत में नीचे की परतों में कोड का संदर्भ हो सकता है, लेकिन किसी परत में कभी भी ऊपर की परत में कोड का संदर्भ नहीं हो सकता है। टियर कई कंप्यूटरों में टियर के भौतिक वितरण को संदर्भित करता है। उदाहरण के लिए, त्रि-स्तरीय एप्लिकेशन में, यूआई को डेस्कटॉप कंप्यूटर पर चलने के लिए डिज़ाइन किया गया है, एप्लिकेशन लॉजिक को एप्लिकेशन सर्वर पर चलाने के लिए डिज़ाइन किया गया है, और डेटाबेस डेटाबेस सर्वर पर चलता है। प्रत्येक में समर्पित डेटा और कोड परत में कई परतें शामिल हो सकती हैं।

चित्र 8-1: बुनियादी त्रिस्तरीय संगठन

परतें अमूर्तता के स्तरों को संदर्भित करती हैं। चित्र 8-1 में दिखाई गई परतें अधिकांश अनुप्रयोगों के लिए सही हैं। इन स्तरों को तीन मुख्य परतों के रूप में भी जाना जाता है और इनके कई अन्य नाम भी हो सकते हैं। एक नियम के रूप में, प्रेजेंटेशन लेयर में कोड एप्लिकेशन लॉजिक लेयर में सेवाओं को कॉल कर सकता है, लेकिन एप्लिकेशन लॉजिक लेयर को प्रेजेंटेशन लेयर में विधि को कॉल नहीं करना चाहिए। प्रेजेंटेशन लेयर को कभी भी सीधे डेटा एक्सेस लेयर को कॉल नहीं करना चाहिए, क्योंकि यह एप्लिकेशन लॉजिक लेयर द्वारा कार्यान्वित जिम्मेदारियों को बायपास कर देगा। डेटा एक्सेस लेयर को कभी भी एप्लिकेशन लॉजिक लेयर को कॉल नहीं करना चाहिए।

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

भौतिक परतें

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

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

परतों में पैटर्न जोड़ना

तीन बुनियादी परतें एक उच्च-स्तरीय अवलोकन प्रदान करती हैं। आइए एक मजबूत उद्यम वास्तुकला बनाने के लिए कुछ संरचनात्मक पैटर्न जोड़ें। परिणाम चित्र 8-2 में दिखाया गया है।

एप्लिकेशन लॉजिक लेयर पर ध्यान दें। चित्र 8-2 से पता चलता है कि एप्लिकेशन लॉजिक तक पहुंच मुखौटा पैटर्न का उपयोग कर रही है। मुखौटा एक ऑब्जेक्ट है जो कोड के बड़े निकाय, जैसे क्लास लाइब्रेरी, को एक सरलीकृत इंटरफ़ेस प्रदान करता है। एक मुखौटा लाइब्रेरी के आंतरिक कामकाज पर बाहरी कोड निर्भरता को कम कर सकता है क्योंकि अधिकांश कोड मुखौटा का उपयोग करते हैं, इस प्रकार सिस्टम विकास में अधिक लचीलेपन की अनुमति मिलती है। ऐसा करने के लिए, मुखौटा बारीक-बारीक वस्तुओं के संग्रह के लिए एक मोटे-दाने वाला इंटरफ़ेस प्रदान करेगा।

निर्णय प्रवाह

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

आपकी सेवाओं को व्यवस्थित करने के दो दृष्टिकोण हैं:

• कार्रवाई उन्मुख
• राज्य संचालित

क्रिया उन्मुख दृष्टिकोण

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

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

राज्य संचालित दृष्टिकोण

एप्लिकेशन के निर्णय प्रवाह को अधिक राज्य-उन्मुख तरीके से लागू करना भी संभव है। एप्लिकेशन सर्वर द्वारा दी जाने वाली सेवाएँ प्रकृति में अधिक सामान्य हैं, उदाहरण के लिए BookStoreService.SaveOrder(ऑर्डर ऑर्डर)। यह विधि ऑर्डर की स्थिति की जांच करेगी और निर्णय लेगी कि नया ऑर्डर जोड़ना है या मौजूदा ऑर्डर रद्द करना है।

डेटा संरचना परियोजनाएँ

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

• सेवाएँ डेटा प्रदान करती हैं; डेटा रिलेशनल डेटाबेस का प्रतिबिंब है।
• डेटा को ऑब्जेक्ट्स पर मैप किया जाना चाहिए और सेवाएं ऑब्जेक्ट्स तक पहुंच प्रदान करती हैं।
• सेवाओं द्वारा प्रस्तुत डेटा स्कीमा-आधारित होना चाहिए।

आपके डेटाफ़्लो संरचना के आधार के रूप में तीनों में से किसी एक को चुनना डिज़ाइन प्रक्रिया के प्रारंभिक चरण में किया जाना चाहिए। कई कंपनियों के पास एक कंपनी दिशानिर्देश होता है जो सभी परियोजनाओं पर तीन विकल्पों में से एक को अनिवार्य करता है, लेकिन जहां संभव हो, आपको प्रत्येक परियोजना के लिए विकल्पों का पुनर्मूल्यांकन करना चाहिए, और मौजूदा परियोजना के लिए इष्टतम दृष्टिकोण का चयन करना चाहिए।

डेटा संग्रहण इंजन चुनना

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

• अभिलेख
• ऐप.कॉन्फिग फ़ाइल
• एक्सएमएल फ़ाइलें
• सादा पाठ फ़ाइलें
• डेटाबेस
• संदेश कतार

प्रत्येक दुकान की अपनी विशिष्ट विशेषताएं होती हैं और उन्हें विशिष्ट आवश्यकताओं के अनुरूप बनाया जा सकता है।

डेटा प्रवाह को डिज़ाइन करना

ADO.NET का उपयोग करके डेटा प्रवाह

एप्लिकेशन लॉजिक लेयर में डेटा-केंद्रित सेवाओं को लागू करके, आप ADO.NET का उपयोग करके अपने डेटा प्रवाह को डिज़ाइन करेंगे। .NET फ्रेमवर्क क्लास लाइब्रेरी प्रबंधित कोड में डेटा में हेरफेर करने के लिए एक व्यापक एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई) प्रदान करती है। ADO.NET के रूप में संदर्भित, API System.Data नेमस्पेस में पाया जा सकता है। डेटा कैरियर और डेटा स्टोर का पूर्ण पृथक्करण ADO.NET की एक महत्वपूर्ण डिज़ाइन विशेषता है। डेटासेट, डेटाटेबल और डेटारो जैसी कक्षाएं डेटा संग्रहीत करने के लिए डिज़ाइन की गई हैं, लेकिन डेटा कहां से आया है, इसका कोई ज्ञान नहीं रहता है। उन्हें डेटा स्रोत अज्ञेयवादी माना जाता है। कक्षाओं का एक अलग सेट, जैसे कि SqlConnection, SqlDataAdapter, और SqlCommand, डेटा स्रोत से कनेक्ट करने, डेटा पुनर्प्राप्त करने और डेटासेट, डेटाटेबल और डेटारो को पॉप्युलेट करने का ख्याल रखता है। ये कक्षाएं System.Data.Sql, System.Data.OleDB, System.Data.Oracle इत्यादि जैसे उप-नामस्थानों में स्थित हैं। आप किस डेटा स्रोत से कनेक्ट करना चाहते हैं, इसके आधार पर आप सही नेमस्पेस में कक्षाओं का उपयोग कर सकते हैं, और आपके द्वारा उपयोग किए जा रहे उत्पाद के दायरे के आधार पर, आप पाएंगे कि ये कक्षाएं कम या ज्यादा कार्यक्षमता प्रदान करती हैं।

चूंकि डेटासेट डेटा स्रोत से कनेक्ट नहीं है, इसलिए इसका उपयोग किसी एप्लिकेशन में डेटा के प्रवाह को प्रबंधित करने के लिए काफी सफलतापूर्वक किया जा सकता है। चित्र 8-5 ऐसा करते समय डेटा प्रवाह दिखाता है।

आइए इस प्रोजेक्ट पर एक नज़र डालें और कल्पना करें कि किसी ने आपकी किताबों की दुकान में लॉग इन किया है और तीन किताबें ऑर्डर की हैं। प्रेजेंटेशन परत शॉपिंग कार्ट की स्थिति को प्रबंधित करती है। ग्राहक ऑर्डर देने के लिए तैयार है और उसने सभी आवश्यक डेटा उपलब्ध करा दिया है। वह ऑर्डर भेजना चुनता है। वेब पेज सभी डेटा को एक डेटासेट में बदल देता है जिसमें दो डेटाटेबल्स होते हैं, एक ऑर्डर के लिए और एक ऑर्डर के लिए; ऑर्डर के लिए डेटारो सम्मिलित करता है; और ऑर्डर पंक्तियों के लिए तीन डेटा पंक्तियाँ सम्मिलित करता है। वेब पेज इस डेटा को एक बार फिर उपयोगकर्ता को प्रदर्शित करता है, डेटा नियंत्रण को डेटासेट के विरुद्ध बाध्य करता है और पूछता है क्या आप निश्चित हैं? उपयोगकर्ता अनुरोध की पुष्टि करता है और इसे एप्लिकेशन की तार्किक परत पर सबमिट किया जाता है। एप्लिकेशन लॉजिक लेयर यह देखने के लिए डेटासेट की जांच करता है कि क्या सभी आवश्यक फ़ील्ड का कोई मान है और यह देखने के लिए जांच करता है कि उपयोगकर्ता के पास 1000 US$ से अधिक है या नहीं। बकाया बिल पर 00 रु. यदि सब कुछ ठीक रहता है, तो डेटासेट को डेटा एक्सेस लेयर में भेज दिया जाता है, जो डेटाबेस से जुड़ता है और डेटासेट जानकारी से सम्मिलित विवरण उत्पन्न करता है।

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

ऑब्जेक्ट रिलेशनल मैपिंग का उपयोग करके डेटा प्रवाह

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

चित्र 8-6 चित्र 8-5 के समान डेटा प्रवाह दिखाता है, सिवाय इसके कि अब आपने ऑब्जेक्ट रिलेशनल मैपिंग परत जोड़ दी है और डेटासेट ऑब्जेक्ट को विभिन्न डेटा वाहक के साथ बदल दिया है।

अब चरण दर चरण पहले जैसा ही करें; कल्पना करें कि कोई व्यक्ति आपकी किताबों की दुकान से जुड़ा और उसने तीन किताबें ऑर्डर कीं। प्रेजेंटेशन परत शॉपिंग कार्ट की स्थिति को प्रबंधित करती है। ग्राहक ऑर्डर देने के लिए तैयार है और उसने सभी आवश्यक डेटा उपलब्ध करा दिया है। वह ऑर्डर भेजना चुनता है। वेब पेज सभी डेटा को एक डीटीओ में बदल देता है, एक ऑर्डर के लिए डेटा रखता है और तीन ऑर्डर लाइनों के साथ, आवश्यकतानुसार ऑब्जेक्ट बनाता है। वेब पेज इस डेटा को एक बार फिर उपयोगकर्ता को प्रदर्शित करता है, ASP.NET 2.0 में ऑब्जेक्टडेटासोर्स का उपयोग करके DTO के विरुद्ध डेटा बाइंडिंग नियंत्रण करता है और पूछता है क्या आप निश्चित हैं? उपयोगकर्ता पसंद की पुष्टि करता है और डीटीओ को एप्लिकेशन की तार्किक परत पर सबमिट किया जाता है। एप्लिकेशन लॉजिक परत डीटीओ को तीन ऑर्डरलाइन ऑब्जेक्ट वाली संपत्ति के साथ ऑर्डर प्रकार के व्यावसायिक ऑब्जेक्ट में बदल देती है। आदेश विधि. ऑर्डर को मान्य करने और यह सत्यापित करने के लिए Validate() को कॉल किया जाता है कि सभी आवश्यक फ़ील्ड का एक मान है, और यह पहचानने के लिए जांच की जाती है कि उपयोगकर्ता के पास लंबित पर्चियों में R$ 1,000.00 से अधिक है या नहीं। ऐसा करने के लिए, ऑर्डर order.Customer.GetOutstandBills() को कॉल करेगा। यदि सब कुछ ठीक है, तो ऑर्डर.सेव() विधि को कॉल किया जाता है। अनुरोध ऑब्जेक्ट रिलेशनल मैपिंग लेयर से होकर गुजरेगा, जहां अनुरोध और अनुरोध की पंक्तियों को डेटासेट में डेटाटेबल पर मैप किया जाता है, और डेटासेट को डेटा एक्सेस लेयर में पास किया जाता है, जो डेटाबेस से जुड़ता है और इन्सर्ट स्टेटमेंट उत्पन्न करता है। डेटासेट में जानकारी. बेशक, ऐसे कई तरीके हैं जिनसे ऑब्जेक्ट-रिलेशनल मैपिंग हो सकती है, लेकिन उनमें से सभी में डेटासेट में परिवर्तन शामिल नहीं होगा। कुछ लोग सीधे इन्सर्ट स्टेटमेंट बनाएंगे लेकिन फिर भी उस स्टेटमेंट को निष्पादित करने के लिए डेटा एक्सेस लेयर का उपयोग करेंगे।

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

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

स्कीमा-आधारित सेवाएँ

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

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