वेब देव - खरीदारी-कार्ट जैसी वस्तु की स्थिति कहां से स्टोर करें?

इसे डेटाबेस में स्टोर करें।

मैंने सोचा है कि आप क्या सुझाव दे रहे हैं लेकिन अभी तक इसका प्रयास करने के लिए क्लाइंट प्रोजेक्ट नहीं है। निकटतम वास्तव में एक शॉपिंग सूची है जिसे आप यहां पा सकते हैं ...

http://www.scottcommonsense.com/toolbox.aspx

विंडो खोलने के लिए किराना चेकलिस्ट पर क्लिक करें। यह एएसपीएक्स का उपयोग करता है, लेकिन केवल पृष्ठ पर रखे जेएस संदर्भों का प्रबंधन करने के लिए। बाकी वेब सेवाओं का उपयोग कर AJAX के माध्यम से किया जाता है।

पहले मैंने एक वाणिज्य साइट के लिए एक एएसपी.NET 2.0 साइट बनाई थी जो स्वचालित रूप से एनन/ऑथ कुकीज़ का उपयोग करती थी। प्रत्येक आपको एक GUID मान प्रदान करता है जिसका उपयोग आप किसी उपयोगकर्ता को पहचानने के लिए कर सकते हैं जो उसके डेटाबेस में डेटा से जुड़ा होता है। मैं ऑथ कुकीज़ चाहता था ताकि उपयोगकर्ता विभिन्न कंप्यूटरों पर जा सके; काम, घर, इत्यादि। मैंने प्रोफ़ाइल फ़ील्ड का उपयोग जटिल कॉम्प्लेक्सबास्केट ऑब्जेक्ट पर रखने के लिए किया जो कि सभी एएसपी.नेट 2.0 किताबों के दौरान लोकप्रिय था। मैं "जादू" धारावाहिक मुद्दों से निपटना नहीं चाहता था क्योंकि डेटा संरचना समय के साथ बदल गई थी। मैं सॉफ़्टवेयर परिवर्तनों के साथ समन्वयित अद्यतन/परिवर्तन स्क्रिप्ट के साथ डीबी स्कीमा परिवर्तनों को प्रबंधित करना पसंद करता हूं।

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

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

यदि आपको छोड़े गए कार्ट के बारे में परवाह नहीं है और क्लाइंट साइड पर डेटा के साथ गड़बड़ करने वाले किसी चीज़ के लिए चीजें हैं ... मुझे लगता है कि एक कुकी अच्छी होगी - खासकर यदि यह सिर्फ JSON डेटा की कुकी है।

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

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

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

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

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

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

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

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

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

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

यदि आपको लंबे समय तक दृढ़ता की आवश्यकता है (कहें कि कुछ उपयोगकर्ता छोड़ना चाहते हैं और अगले दिन वापस आना चाहते हैं), तो उसे एक कुकी में स्टोर करें जो छेड़छाड़ वाला है (एन्क्रिप्शन या हैश का उपयोग करें)।

Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.

Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in

डीबी में जो कुछ भी आप सत्रों (डीबी/मेमकेचे सत्र, हस्ताक्षरित कुकीज़) या किसी प्रमाणीकृत उपयोगकर्ता के लिए उपयोग कर रहे हैं उससे बंधे हैं।

यदि आप जावास्क्रिप्ट सक्षम किए बिना उपयोगकर्ताओं को समर्थन देने की परवाह करते हैं, तो सर्वर साइड सत्र आपको यूआरएल रीराइटिंग का उपयोग करने देगा।

क्या आप लोगों को एक मशीन (जैसे उनके काम पीसी) पर शुरू करने में सक्षम होने की कल्पना करते हैं, लेकिन एक अलग मशीन (जैसे होम पीसी) से जारी/फिनसिह करते हैं? यदि हां, तो जवाब स्पष्ट है।

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

अंत में इसका मतलब है कि आपको क्लाइंट-साइड कुकी से डेटा को डी/सीरियलाइज करने के लिए कोड लिखने के बारे में चिंता करने की ज़रूरत नहीं है, जबकि बाद में उस डेटा को डेटाबेस में डालने के बारे में चिंता करने पर चिंता होती है जब यह ऑर्डर में परिवर्तित हो जाती है (बहुत से मेरी पसंद के लिए विफलता के अंक) ..