एएसपी.नेट एमवीसी - दृश्यों में डेटा पास करना

Question

मैं एक एमवीसी अनुप्रयोग बना रहा हूं। मेरे कार्यों में से एक स्टोर बनाना है। मैंने विचारों के सेट की तरह एक "जादूगर" स्थापित किया जो उपयोगकर्ता को कुल 7 चरणों में ऑपरेशन के अंत तक विभिन्न प्रकार के डेटा भरने के लिए लाता है।

मेरा मुद्दा इन सभी विचारों के बीच कुछ डेटा साझा करने के बारे में है।

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

अब मैंने TempData के अंदर किसी भी डेटा को स्थापित करने के लिए सब कुछ संशोधित किया है, और प्रत्येक चरण में सभी डेटा रीफ्रेश कर रहा है और ऐसा लगता है कि यह ठीक से काम करता है।

मैं थोड़ा उलझन में हूँ!

मेरा भ्रम इन सभी संरचनाओं के बारे में है: सत्र (मुझे पता है कि यह एएसपीनेट से आ रहा है), ViewData, TempData और जादू ViewBag।

मैंने बहुत कुछ पढ़ा लेकिन मुझे किसी ऐसे व्यक्ति की आवश्यकता है जो स्पष्ट रूप से मुझे बताए कि इस मामले में मेरे लिए और अधिक उपयुक्त क्या है।

Answer 1

मैं कहूंगा कि व्यूबैग इस तरह के कुछ के लिए बिल्कुल सही है। अब, आप व्यूबैग को "मैजिक" व्यूबैग के रूप में संदर्भित कर रहे हैं, लेकिन हकीकत में यह सिर्फ <string,object>

व्यूबैग काम करता है यह तरीका है कि यह व्यूडेटा के आस-पास एक गतिशील रैपर है, इसलिए जब आप कुछ मांगते हैं, तो देखते हैं ViewBag.ShoppingCart, यह मूल रूप से अंतर्निहित शब्दकोश पूछता है यदि उसके पास "शॉपिंगकार्ट" नामक प्रविष्टि है, और आइटम लौटाता है।

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

जब तक आप ShoppingCart (या जादूगर प्रगति) एक डेटाबेस में संग्रहीत किए जाने की जरूरत है, मैं अपने मामले :)

में के लिए ViewBag TempData जाना चाहते हैं तुम भी से इस लेख पर एक नज़र ले सकता है तीन पर थोड़ा अधिक जानकारी के लिए राहेल एप्पल:

http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications

(पीएस मैं कुछ और अधिक निष्पक्ष राय प्राप्त करने के लिए उस पोस्ट पर साथ ही टिप्पणियों को पढ़ने की सलाह देते हैं।)

Answer 2

आपके पास यहां कई विकल्प हैं: सत्र, व्यूडेटा (या व्यूबैग) का उपयोग करें, लेकिन छिपे हुए फ़ील्ड या कुकीज़ का उपयोग करके इसे पास करने की आवश्यकता है।

व्यूडाटा में समस्या है जो अधिक काम करेगी।

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

किसी सर्वर का उपयोग करके इस समस्या को हल करें जो सभी सर्वरों के लिए सत्र रखता है या कुकीज़ का उपयोग करता है (यदि जानकारी महत्वपूर्ण नहीं है)।

Answer 3

छिपे हुए फ़ील्ड का उपयोग करने में कुछ भी गलत नहीं - कम से कम मेरी पुस्तक में।

मैं समस्या के आसपास कोड लिखने की बजाय सत्र समस्या को ठीक कर दूंगा। एक साधारण परीक्षण चलाएं: अपने सत्र प्रदाता को SQL में बदलें, छुपा फ़ील्ड अक्षम करें और देखें कि आपका ऐप ठीक से काम करता है या नहीं। यदि ऐसा नहीं होता है, तो आपके बारे में चिंता करने के लिए अन्य (बड़े) मुद्दे हैं।

क्या यह ऐप एक लोड-बैलेंसर के पीछे एक वेब फार्म/"क्लाउड"/में काम करना चाहिए? यदि ऐसा है, तो आपको या तो:

• सत्र प्रदाता को किसी और चीज़ में बदलें: SQL, StateServer, memcache, आदि। कई कोड परिवर्तन आवश्यक नहीं हैं।

http://msdn.microsoft.com/en-us/library/ms178587.aspx और http://memcachedproviders.codeplex.com/

या

• फिर से डिजाइन अपने विज़ार्ड चरणों और विचारों के बीच साझा मूल्यों पर अपनी निर्भरता को कम। सत्र आईडी की आपको आवश्यकता है और आप किसी अन्य चीज़ के लिए डीबी से पूछ सकते हैं। बहुत तेज़ लेकिन सुरक्षित और स्थिर नहीं है।

अनुकूलित: के रूप में आप लेकिन (इस के साथ कुछ भी गलत नहीं है कि मैं ने कहा,) आम तौर पर एक क्षेत्र डीबी प्रश्नों की संख्या को कम करना चाहते के रूप में कई छिपा खानों का उपयोग अनुरोधों के बीच अपने धारावाहिक राज्य रखने के लिए पर्याप्त है: http://blog.maartenballiauw.be/post/2009/10/08/Leveraging-ASPNET-MVC-2-futures-ViewState.aspx।

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

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

उम्मीद है कि यह मदद करता है!