डेटा एक्सेस लेयर एक वेब सेवा के रूप में - क्या यह एक अच्छा विचार है?

Question

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

धन्यवाद।

Answer 1

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

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

सुरक्षितता काफी सरल हो सकती है। आप अपने सार्वजनिक सेवा इंटरफ़ेस के लिए आईआईएस प्रमाणीकरण के साथ एसएसएल का उपयोग कर सकते हैं।

तो, उन मेरी $ 0.03

Answer 2

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

यदि आप एडी के साथ इंट्रानेट वातावरण में तैनात हैं, तो एकीकृत विंडोज प्रमाणीकरण यह नियंत्रित करने का एक शानदार तरीका है कि सेवा के साथ कौन बातचीत कर सकता है और नहीं कर सकता है। यह उपभोक्ता भूमिकाओं द्वारा समूह सेवा वर्गों के लिए सहायक है, ताकि permissions can be controlled declaratively in the Web.config। मैं अपडेट को सम्मिलित करने और विधियों को हटाने के बजाय एक अलग सेवा वर्ग में पढ़ने के तरीकों को रखना चाहता हूं

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

मुझे आशा है कि ये विचार मदद करेंगे।

Answer 3

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

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

Answer 4

आइए नज़र:

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

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