एसओए सिर्फ वेब क्लाइंट को JSON भेजने से कहीं अधिक है।
कल्पना कीजिए कि आपके पास बिक्री, सूची, रिपोर्टिंग इत्यादि जैसी चीजों के लिए डेटाबेस संचालित सॉफ्टवेयर सिस्टम के साथ एक व्यवसाय है। अधिकांश सिस्टम केवल क्लाइंट या वेब ऐप डेटाबेस से बात करते हुए छोटे से शुरू होते हैं ... और यह है ठीक है।
हालांकि, जैसे ही सिस्टम बढ़ता है, कुछ ऐसी चीजें हैं जो आपको मिलेंगी जो इस मॉडल के अंदर अच्छी तरह से फिट नहीं होती हैं: लंबे समय से चलने वाली बैच प्रक्रियाएं जो ऐप या वेब पेज को लॉक करती हैं, नियत नौकरियां जिनमें बस से अधिक शामिल है डेटाबेस सर्वर, बाहरी स्रोतों में रहने वाले डेटा को शामिल करने वाली प्रक्रियाओं, या जटिल रिपोर्ट जो आपके डीबी को चलाने के दौरान दबाती हैं। इस बिंदु पर, आप इनमें से कुछ कार्यों को संभालने के लिए एक एप्लिकेशन सर्वर जोड़ने के बारे में सोचना चाहेंगे। एक एप्लिकेशन सर्वर आपके ग्राहकों के उस वर्कलोड को बंद कर सकता है। यह कुछ समय से अधिक लोड ले सकता है जो इस समय तक अधिक काम करने वाले डेटाबेस होने की संभावना है, जैसे कि एप्लिकेशन सर्वर डीबी से और उसके लिए कच्चे डेटा का अनुरोध करता है या आपके आवेदन अनुरोध/एप्लिकेशन से और उसके द्वारा अनुरोधित डेटा जमा करता है सर्वर।
जैसे ही सिस्टम बढ़ता जा रहा है, आप यह भी पाएंगे कि सिस्टम के विभिन्न हिस्सों में अप्रत्याशित दुष्प्रभाव होते हैं जैसे आप चीजों को बनाए रखते हैं। यहां तक कि सरल संवर्द्धन पूर्ण होने के लिए अधिक जटिल हो जाते हैं। विकास धीमा, और बग की संख्या में वृद्धि हुई है। एप्लिकेशन सर्वर अब यह सुनिश्चित करने के लिए डिज़ाइन प्रयासों को केंद्रीकृत करने के लिए एक महान स्थान बन गया है कि एक क्षेत्र में परिवर्तन के परिणामस्वरूप अपेक्षित परिणाम (और केवल अपेक्षित परिणाम) हैं।
इसके आरंभ में, वास्तव में एक एसओए क्या है, तो वह एप्लिकेशन सर्वर ले रहा है (जो http पर जेसन का उपयोग करने के लिए हो सकता है, लेकिन एक पूरी तरह से अलग इंटरफ़ेस भी प्रदान कर सकता है या कई डेटा ट्रांसपोर्ट तकनीकों के बीच स्वचालित रूप से अनुवाद भी कर सकता है) और सभी लागू करने के लिए, कुछ ही नहीं, डेटाबेस एक्सेस इस एप्लिकेशन सर्वर के माध्यम से जाता है: सेवा परत।
एक बार यह पहुंच लागू हो जाने के बाद, और कुछ भी डेटाबेस से सीधे बात नहीं करता है (कम से कम, कुछ भी जो विशेष रूप से जिम्मेदार नहीं है), परत व्यवसाय नियमों और सिस्टम तर्क को लागू करने के लिए भी एक महान जगह बन जाती है। यह आपको यहां पारंपरिक एप्लिकेशन-स्टाइल कोड लिखने की अनुमति देता है जो एसक्यूएल की तुलना में स्रोत नियंत्रण के साथ उपयोग करना आसान है और सिस्टम का उपयोग कर किसी भी एप्लिकेशन के बीच स्वचालित रूप से साझा किया जाएगा। कोड सभी एक ही स्थान पर रहते हैं और इसलिए सिस्टम के माध्यम से बदलावों और उनके प्रभावों को मॉडल करना आसान है। बोनस के रूप में, यह परत अक्सर कई अनावश्यक सर्वरों को स्केल करने में बहुत आसान होती है, और इसलिए यह बड़े एप्लिकेशन के प्रदर्शन और विश्वसनीयता को बेहतर बनाने और प्रबंधित करने का एक तरीका बन सकता है।बैक एंड पर, यह रेडिस जैसे डेटाबेस कैशिंग टूल का उपयोग करने के प्रयासों को सरल और केंद्रीकृत करके प्रदर्शन में भी सुधार कर सकता है, जिससे प्रदर्शन ट्यूनिंग में समर्पित डीबीए को शामिल करना आसान हो जाता है, और आपको कई स्थानों पर मौजूद डेटा तक पहुंच को केंद्रीकृत करने में सहायता मिलती है।
इस बिंदु पर, आपकी एमवीसी वेबसाइट सिर्फ एक और ऐप है जो आपके एसओए सिस्टम में एप्लिकेशन सर्वर से जुड़ती है। आपके पास कुछ डेस्कटॉप पर एक विरासत क्लाइंट-सर्वर ऐप भी स्थापित हो सकता है, या आपका एमवीसी ऐप सार्वजनिक बिक्री हो सकता है जबकि वास्तविक बिक्री और समर्थन प्रतिनिधि कुछ अलग तरीके से उपयोग करते हैं, बिलिंग एक अलग ऐप का उपयोग करता है, और आदेश पूर्ति या खरीद में अभी तक एक और इंटरफ़ेस है ... लेकिन वे सभी एक ही सेवा परत से बात करते हैं। यहां एक अतिरिक्त लाभ यह है कि यह सेवा परत एकाधिक स्रोतों से डेटा को खींचना आसान बनाता है, इसलिए यदि आपके विनिर्माण सिस्टम को बाहरी सिस्टम से भौतिक उपलब्धता की जानकारी की आवश्यकता है, तो सेवा परत यह जान सकती है कि कैसे और फ्रंट-एंड कोड नहीं मिलता है यह जानना नहीं है कि यह डेटा कहीं भी विशेष से आया है।
यह सब बात यह है कि यह या तो या यहां कोई मामला नहीं है। यदि आपके पास एसओए है, तो आप सिस्टम के एक स्तर पर एमवीसी का उपयोग कर सकते हैं, और एसओए की सेवा परत द्वारा प्रदान किया गया इंटरफ़ेस आपके एमवीसी मॉडल की तरह दिखता है और नियंत्रक कैसे व्यवहार करता है, यह निर्धारित करेगा। यदि आपके पास एसओए नहीं है, तो एमवीसी पूरी तरह से काम करने के लिए डेटाबेस से प्रेजेंटेशन तक काम करने के लिए ठीक काम करता है, और वास्तव में काम करता है कि मॉडल एक बड़ी सेवा परत के लिए एक माइक्रोक्रोस बन जाता है।
प्रश्न, फिर, जब JSON बनाम एएसपी.NET एमवीसी का उपयोग करने के लिए उपयोग किया जाए तो सवाल एक नया रूप लेता है। एएसपी.NET एमवीसी एक एसओए आर्किटेक्चर का हिस्सा हो सकता है, और सेवा ढांचे जो जेएसओएन डेटा प्रदान करते हैं अक्सर क्लाइंट-साइड एमवीसी पुस्तकालयों का उपयोग करके लागू किया जाता है। आप वास्तव में जानना चाहते हैं कि सर्वर पक्ष पर अधिक क्लाइंट पक्ष बनाम अधिक करने के लिए यह अधिक उचित है। ईमानदारी से, मुझे लगता है कि यह ज्यादातर व्यक्तिगत वरीयता है, लेकिन व्यापार-बंद हैं जिनके बारे में आपको अवगत होना चाहिए।
अधिक काम करना क्लाइंट पक्ष प्रदर्शन और स्केलेबिलिटी के लिए बहुत अच्छा हो सकता है, क्योंकि यह आपके सभी उपयोगकर्ताओं के कंप्यूटर सिस्टम के बीच आपके एप्लिकेशन का वर्क-लोड फैलता है, और यह वेब सर्वर पर राउंड ट्रिप करके पेश की जाने वाली विलंबता को कम कर सकता है या अनुप्रयोग सर्वर।
दूसरी तरफ, धीमे सार्वजनिक इंटरनेट लिंक पर बड़े डेटा सेट को स्थानांतरित करने में विलंबता से बचने के लिए अधिक काम सर्वर पक्ष करना अच्छा है, अमेरिकी विकलांगता अधिनियम अभिगम्यता जनादेश जैसी चीजों के लिए अनुपालन आवश्यकताओं को पूरा करना आसान बना सकता है, जहां भी अधिक जावास्क्रिप्ट सुलभ ब्राउज़रों के साथ समस्याएं पैदा कर सकता है या क्लाइंट सिस्टम को डेटा धक्का दे सकता है गोपनीयता या सुरक्षा जोखिम का गठन कर सकता है, और जब भी अधिक प्रसंस्करण एक ही परत के भीतर होता है तो नए कोड को विकसित, तैनात और बनाए रखना आसान हो सकता है।
धन्यवाद बहुत बहुत धन्यवाद जोएल, आपका उत्तर इस वैचारिक प्रश्न के लिए एक और स्पष्टता लाता है .. मुख्य बिंदु मुझे प्राप्त हुआ - यह व्यक्तिगत वरीयता है और बिल्कुल विशेष कंडिटन और परियोजना आवश्यकताओं पर निर्भर करता है। – Artem