'एक ऐप राज्य नहीं होना चाहिए। राज्य को डेटा लेयर में रखा जाना चाहिए जहां डेटाबेस '
ऐसे डिज़ाइन हैं जहां यह मानक है, जिसे' स्टेटलेस आर्किटेक्चर 'कहा जाता है। चाहे हर वास्तुकला स्टेटलेस हो, निश्चित रूप से संदिग्ध होना चाहिए और बहुत ही शब्द बहस के लिए भी खुलता है।
वास्तव में अधिकांश "स्टेटलेस" अनुप्रयोगों में राज्य होता है, लेकिन राज्यों के ऊपर नियम (कोई पन नहीं) यह राज्य एक वैश्विक स्थान पर रखा जाता है; डेटाबेस। जैसा कि पीटर का उल्लेख है, इसके कारणों का रखरखाव और सरलीकरण हो सकता है, लेकिन यह अक्सर सुना जाता है कि यह scalability के लिए है। राज्य के बिना कहीं भी दिखाई देने के बिना, डेटाबेस में, अतिरिक्त फ्रंट-एंड सर्वर, प्रोसेसिंग सर्वर, और आप क्या हैं, जोड़ने के लिए आसान माना जाता है।
हालांकि इसमें कुछ योग्यता है, मुझे लगता है कि हमें अस्थायी राज्य और आधिकारिक राज्य के बीच भेद करना है।
अस्थायी राज्य आपके द्वारा क्रमबद्ध प्रक्रिया में मौजूद स्थान और आपके द्वारा पहले से दर्ज किए गए विवरण की तरह कुछ हो सकता है। जावा ईई में, आप इसे आसपास में रख सकते हैं उदा। @ ConconationScoped सेम, या @Stateful सेम।इस प्रकार यह राज्य है कि आप वेब परत resp resp अंदर के अंदर रहते हैं। व्यापार परत
इसका लाभ उपयोग, प्रदर्शन और आपके एकल केंद्रीय डेटाबेस को उतारने में आसानी है। निश्चित रूप से, आप अपने केंद्रीय डेटाबेस में अस्थायी स्थिति भी संग्रहीत कर सकते हैं, लेकिन शायद आप इसे नियमित, अस्थायी डेटा से दूर रखना चाहते हैं, जिसका अर्थ है कि कुछ अतिरिक्त प्रोग्रामिंग जटिलता की आवश्यकता है। वेब परत से डेटा पुनर्प्राप्त करने के लिए यह आमतौर पर बहुत तेज होता है, और यह डेटाबेस से कुछ लोड हटा देता है।
कई प्रणालियों में केवल एक ही मास्टर डेटाबेस (डेटाबेस स्वीकार करने वाला डेटाबेस) होता है, इसलिए यह एकल डेटाबेस उस सेटअप में एक बड़ी बाधा बन सकता है।
आपके वास्तविक आर्किटेक्चर और सेटअप के आधार पर, डेटाबेस में अस्थायी स्थिति रखने से - वास्तव में स्केल करने की आपकी क्षमता में सुधार होता है।
नुकसान यह है कि आपको अपने क्लाइंट को एक सर्वर से चिपकने की आवश्यकता है जिस पर अस्थायी स्थिति वर्तमान में रखी गई है। यह ठेठ 'चिपचिपा सत्र' कहा जाता है। यदि एक सर्वर जहां यह क्लाइंट विफल रहता है या फिर से शुरू करने की आवश्यकता है या जो भी हो, तो ग्राहक इस अस्थायी डेटा को खो देगा। क्लस्टर में या आसपास के नोड्स (दोस्त प्रतिकृति) में सभी नोड्स को राज्य की प्रतिलिपि बनाने जैसी कुछ योजनाएं हैं, लेकिन यह चीजों को फिर से जटिल बना रही है और नेटवर्क को अधिभारित कर सकती है (यदि सभी नोड लगातार एक-दूसरे के प्रति प्रतिकृति कर रहे हैं)।
आधिकारिक राज्य का अर्थ यह साझा डेटा का प्रतिनिधित्व करता है जो जानकारी का एकमात्र स्रोत है। इस तरह का राज्य ऐसा कुछ है जो हम लगभग हमेशा केंद्रीय स्थान पर रखना पसंद करते हैं, लेकिन कभी-कभी आप इसे संग्रहीत करते हुए देख सकते हैं। एक वेब नोड।
उदाहरण के लिए, मान लीजिए कि हमारे पास हाल की कीमतों की एक सूची है, और इसे केंद्रीय स्थान पर रखने के बजाय हम इसे वेब नोड पर रखते हैं जहां इसे दर्ज किया गया था। अब "एक और एकमात्र" वेब नोड की एक अवधारणा है जिसमें यह जानकारी है और अन्य सर्वर यह मानना शुरू कर सकते हैं कि केवल यह "एक और एकमात्र" वेब नोड है। अतिरिक्त नोड्स जोड़ना अब असंभव है, क्योंकि यह इस धारणा को तोड़ देता है।
ठीक है, मेरे कोड की समीक्षा करने वाले व्यक्ति ने कहा कि ऑब्जेक्ट निर्माण वेब परत में महंगा है। सीपीयू लागत के बावजूद, हम इसे बहुत वैचारिक रखते हैं। जबकि उपर्युक्त दृष्टिकोण का उपयोग डिजाइन को सरल बनाने के लिए किया जा सकता है - मुझे नहीं लगता कि वास्तव में इसका मतलब था। व्यक्ति ने मुझे बताया "हर बार जब उपयोगकर्ता वेबपेज पर जाता है, तो आप व्यक्ति के प्रोफाइल मैनेजर को नए कर रहे हैं और वहां से प्रोफाइल डेटा प्राप्त कर रहे हैं। यह बहुत महंगा है। प्रबंधक को केवल एक बार तत्काल चालू किया जाना चाहिए और शेष वेब ऐप घटक बाद में इसे एप्लिकेशन विशेषता से प्राप्त करके इसे एक्सेस करें। " app.setAttribute (m) – MrStack
क्या किसी प्रकार का डीएओ या सेवा "प्रोफ़ाइल प्रबंधक" है? आम तौर पर, प्रति अनुरोध वस्तुओं की एक छोटी निश्चित संख्या बनाना शायद ही कभी "बहुत महंगा" होता है। ऑब्जेक्ट आवंटित करना एक आधुनिक जेवीएम पर अविश्वसनीय रूप से तेज़ है। बेशक अगर इसकी पूरी तरह से आवश्यकता नहीं है, क्योंकि यह प्रबंधक प्रभावी रूप से एक सिंगलटन है, तो एक न बनाएं (लेकिन उस स्थिति में मुझे आश्चर्य है, क्या आप लोग स्थिर विधियों का भी उपयोग नहीं कर सकते हैं, यहां तक कि 1 उदाहरण भी क्यों हो सकता है यदि आप कर सकते हैं प्रतीत होता है कि 0 उदाहरणों के साथ भी?) –
एक साधारण वस्तु बनाने का कार्य लगभग 10 एनएस खर्च कर सकता है। उनमें से बड़ी संख्या में निर्माण करना जोड़ सकता है लेकिन यहां तक कि एक लाख भी स्वीकार्य हो सकता है। जहां लागत अधिक हो सकती है, जब आपको बाहरी स्रोत के आधार पर जानकारी बनाना होता है। एक एकल डेटाबेस क्वेरी 10 एमएस खर्च/ले सकती है, और यदि आपको उनमें से कई को एक प्रोफ़ाइल के लिए करना है, तो यह जल्दी से लगभग एक सेकंड बन सकता है जो हर बार करने का अच्छा विचार नहीं है। –