प्रसंग:ASP.NET Postbacks भर में डाटा हठ
मैं अक्सर स्थितियों में, जहां हमारे ASP.NET पृष्ठों एक GridView पर उपयोगकर्ता के लिए डेटा दिखाने के लिए होता है में किया गया है, उसे इसे बदलने के रूप में वह प्रसन्न करते हैं (कोशिकाओं पर टेक्स्टबॉक्स) और केवल डेटाबेस को सहेजते हैं जब वह वास्तव में "सहेजें बटन" हिट करता है। यह डेटा आमतौर पर पृष्ठ पर जानकारी का आभासी स्थिति होता है, जिसका अर्थ यह है कि जब तक वह "सहेजें बटन" हिट नहीं करता तब तक उपयोगकर्ता इसे सहेजने के बिना सब कुछ बदल सकता है। उन मामलों में, हमेशा डेटा की सूची होती है जिसे एएसपी.NET पोस्टबैक में जारी रखने की आवश्यकता होती है। यह डेटा DataTable या बस कुछ List<Someclass> का उदाहरण हो सकता है।
मैं अक्सर इसे लागू करने वाले लोगों को देखता हूं और Session पर डेटा को कायम रखता हूं। उन मामलों पर मैं आमतौर पर समस्याओं को भी देखता हूं जब कुछ उपयोगकर्ता एक ही पृष्ठ पर खुले कई टैब खोलने के साथ आते हैं। जहां दो अलग-अलग टैबों का डेटा विलय हो जाएगा और जानकारी की समस्याएं खराब हो जाएंगी।
कैसे सत्र अक्सर प्रयोग किया जाता है का उदाहरण: जब दो टैब पहले से ही भरा हुआ है और उपयोगकर्ता कर रहे हैं के बारे में
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
DataList = null
}
else
{
FillGridView(DataList);
}
}
लेकिन क्या:
private List<SomeClass> DataList
{
get
{
return Session["SomeKey"] as List<SomeClass>;
}
set
{
Session["SomeKey"] = value;
}
}
लोग अक्सर कुछ इस तरह करने से इसे हल करने की कोशिश करता है GridView मानों को बदल रहा है और कुछ अजीब कारणों से वह दूसरे पृष्ठ पर सहेजें बटन को मारकर डेटा को सहेजने का प्रयास करता है? मैं व्यक्तिगत रूप से इस विकल्प को नापसंद करता हूं।
ऐसा करने के अन्य तरीके डेटा को ViewState पर रखना होगा। हालांकि, जब बड़ी संख्या में बड़ी सूचियां बनी रहती हैं, तो यह पेज पर संग्रहीत होने पर पेज को बहुत प्रभावित कर सकती है (HiddenField)।
लेकिन, यह काम करने का सबसे अच्छा तरीका क्या है? एक बार, मैंने Session का उपयोग ViewState के साथ करने में सोचा था जहां ViewState एक अद्वितीय पहचानकर्ता होगा जो Session सहेजे गए डेटा को इंडेक्स करेगा। दूसरी ओर
private List<SomeClass> DataList
{
get
{
if (ViewState["SomeKey"] == null)
{
ViewState["SomeKey"] = Guid.NewGuid().ToString();
}
return Session[ViewState["SomeKey"].ToString()] as List<SomeClass>;
}
set {
if (ViewState["SomeKey"] == null)
{
ViewState["SomeKey"] = Guid.NewGuid().ToString();
}
Session[ViewState["SomeKey"].ToString()] = value;
}
}
यह सत्र के लिए हर उपयोगकर्ता द्वारा पृष्ठ में प्रवेश करती है डेटा की एक नई सूची संग्रहीत करेंगे: यह ब्राउज़र पर टैब के बीच डेटा साझा रोका जा सके। जो सर्वर मेमोरी को प्रभावित करेगा। शायद वे किसी भी तरह से मिटा दिया जा सकता है।
प्रश्न:
क्या, Postbacks भर में डेटा उस तरह बने ब्राउज़र पर अनेक टैब के संदर्भों पर विचार का सबसे अच्छा तरीका हो सकता है, सर्वर के लिए और रखरखाव कोडिंग टीम के लिए कम लागत के साथ ?
अद्यतन:
के रूप में अच्छी तरह से तैनात @nunespascal, एक ही विकल्प SessionPageStatePersister का उपयोग कर Session में ViewState स्टोर करने के लिए किया जाएगा। लेकिन दुर्भाग्य से यह मेरे मामले पर एक विकल्प नहीं है। और फिर भी यह मेरे अंतिम उदाहरण से बहुत अलग नहीं है, व्यूस्टेट पर संग्रहीत एक अद्वितीय आईडी द्वारा अनुक्रमित सत्र पर डेटा को सहेज रहा है।
क्या कोई अन्य विकल्प होगा?
दूसरा दृष्टिकोण कुछ tweaks के साथ काम करने योग्य है: 1) ViewState के बजाय एक छिपे हुए क्षेत्र का उपयोग करें। यह पृष्ठ पर व्यूस्टेट उपलब्ध होने से पहले इसे एक्सेस करने की अनुमति देता है (कभी-कभी उपयोगी)। 2) एक प्रबंधक के साथ लपेटें सत्र जो कि एक ही समय में कितनी वस्तुओं को संग्रहीत किया जा सकता है और सबसे पुरानी वस्तुओं को फेंक देता है। बेशक, यह स्मृति समस्या को पूरी तरह से ठीक नहीं करता है, लेकिन उपयोगकर्ताओं को आपके आवेदन में व्यवस्थित रूप से काम करने की दिशा में एक लंबा रास्ता तय कर सकता है, इस बात की चिंता किए बिना कि एक व्यस्त उपयोगकर्ता के पास स्मृति में सैकड़ों बड़ी वस्तुएं/सेट होंगे। –