ما يجب وضعه في متغير الجلسة

Question

لقد صادفت مؤخرًا تطبيق ويب ASP 1.1 يضع كومة كاملة من العناصر في متغير الجلسة - بما في ذلك جميع كائنات بيانات قاعدة البيانات وحتى كائن اتصال قاعدة البيانات.وينتهي الأمر إلى أن تكون ضخمة.عندما تنتهي مهلة جلسة الويب (بعد أربع ساعات من انتهاء المستخدم من استخدام التطبيق)، يتم في بعض الأحيان التراجع عن معاملات قاعدة البيانات الخاصة به.أفترض أن السبب في ذلك هو عدم إغلاق اتصال قاعدة البيانات بشكل صحيح عندما يقوم IIS بقتل الجلسة.

على أي حال، سؤالي هو ما ينبغي أن يكون في متغير الجلسة؟من الواضح أن بعض الأشياء يجب أن تكون هناك.يحدد المستخدم الخطة التي يريد تحريرها على الشاشة الرئيسية، لذلك ينتقل معرف الخطة إلى متغير الجلسة.هل من الأفضل محاولة تقليل الحمل على قاعدة البيانات عن طريق تخزين جميع التفاصيل حول المستخدم (ومديره وما إلى ذلك) والخطة التي يقومون بتحريرها في متغير الجلسة أم يجب أن أحاول تقليل الأشياء الموجودة في متغير الجلسة و الاستعلام عن قاعدة البيانات لكل ما أحتاجه في حدث Page_Load؟

Answer 1

من الصعب جدًا الإجابة على هذا السؤال لأنه خاص بالتطبيق، ولكن إليك بعض الإرشادات التي أستخدمها:

1. ضع أقل قدر ممكن في الجلسة.
2. تعتبر التحديدات الخاصة بالمستخدم والتي يجب أن تستمر فقط أثناء زيارة معينة خيارًا جيدًا
3. في كثير من الأحيان، من الجيد أيضًا وضع المتغيرات التي يجب أن تكون متاحة لصفحات متعددة طوال زيارة المستخدم لموقعك (لتجنب تمريرها من صفحة إلى أخرى) في الجلسة.

من القليل الذي قلته عن تطبيقك، ربما سأختار بياناتك من قاعدة البيانات وأحاول إيجاد طرق لتقليل تأثير تلك الاستعلامات بدلاً من تحميل الجلسة.

Answer 2

يفعل لا وضع معلومات اتصال قاعدة البيانات في الجلسة.

فيما يتعلق بالتخزين المؤقت، سأتجنب استخدام الجلسة للتخزين المؤقت إن أمكن - ستواجه مشكلات حيث يقوم شخص آخر بتغيير البيانات التي يستخدمها المستخدم، بالإضافة إلى أنه لا يمكنك مشاركة البيانات المخزنة مؤقتًا بين المستخدمين.استخدم ASP.NET Cache، أو أي أداة مساعدة أخرى للتخزين المؤقت (مثل Memcached أو Velocity).

بقدر ما يجب الذهاب في الدورة، أي شيء ينطبق على الجميع يجب أن تكون نوافذ المتصفح التي فتحها المستخدم على موقعك (تسجيل الدخول، وإعدادات الأمان، وما إلى ذلك) موجودة في الجلسة.يجب أن تكون أشياء مثل الكائن الذي يتم عرضه/تحريره عبارة عن متغيرات GET/POST يتم تمريرها بين الشاشات حتى يتمكن المستخدم من استخدام نوافذ متصفح متعددة للعمل مع التطبيق الخاص بك (إلا إذا كنت ترغب في منع ذلك).

Answer 3

لا وضع كائنات واجهة المستخدم في الجلسة.

أبعد من ذلك، أود أن أقول أنه يختلف.قد يؤدي الإفراط في الجلسة إلى إبطائك إذا كنت لا تستخدم الجلسة قيد التشغيل لأنك ستقوم بإجراء تسلسل كثيرًا + سرعة الموفر.يجب استخدام ذاكرة التخزين المؤقت والجلسة بشكل مقتصد وبعناية.لا تدخل في الجلسة فقط لأنك تستطيع ذلك أو تشعر بالراحة.اجلس وقم بالتحليل إذا كان ذلك منطقيًا.

Answer 4

من الناحية المثالية، يجب أن تقوم الجلسة في ASP بتخزين أقل قدر من البيانات التي يمكنك التخلص منها.يعد تخزين مرجع لأي كائن يبقي موارد النظام مفتوحة (خاصة اتصال قاعدة البيانات) بمثابة قاتل واضح لقابلية التوسع.كما أن تخزين البيانات غير الملتزم بها في متغير الجلسة يعد فكرة سيئة في معظم الحالات.بشكل عام، يبدو أن التطبيق الحالي يستخدم بشكل مسيء كائنات الجلسة لمحاولة محاكاة تطبيق ذي حالة في بيئة من المفترض أنها عديمة الحالة.

على الرغم من أنه ضار كثيرًا، إلا أن نموذج ASP.NET لإدارة الحالة تلقائيًا من خلال الحقول المخفية يجب أن يلغي غالبية الحاجة إلى الاحتفاظ بأي شيء في متغيرات الجلسة.

قاعدتي الأساسية هي أنه كلما كان التطبيق أكثر قابلية للتطوير (من حيث عدد المستخدمين/النقرات)، قلَّت إمكانية الإفلات من استخدام حالة الجلسة.ومع ذلك، هناك مقايضة.بالنسبة لتطبيقات الويب حيث يصل المستخدم بشكل متكرر إلى نفس البيانات ويكون لديه عادةً جلسة طويلة إلى حد ما لكل استخدام للموقع، فإن بعض التخزين المؤقت (إذا لزم الأمر في كائنات الجلسة) يمكن أن يساعد في الواقع في قابلية التوسع عن طريق تقليل الحمل على خادم قاعدة البيانات.الفكرة هنا هي أن زراعة طبقة العرض أرخص بكثير وأقل تعقيدًا من قاعدة البيانات الخلفية.بالطبع، مع كل الأمور، يجب أن تؤخذ هذه النصيحة باعتدال ولا تنطبق في جميع المواقف، ولكن بالنسبة لتطبيق CRUD الداخلي البسيط إلى حد ما، يجب أن يخدمك جيدًا.

Answer 5

أ سؤال مشابه جدا تم سؤالنا بخصوص جلسات PHP سابقًا.في الأساس، تعد الجلسات مكانًا رائعًا لتخزين البيانات الخاصة بالمستخدم والتي تحتاج إلى الوصول إليها عبر عمليات تحميل متعددة للصفحات.الجلسات ليست مكانًا رائعًا لتخزين مراجع اتصال قاعدة البيانات؛من الأفضل استخدام نوع ما من برامج تجميع الاتصالات أو فتح/إغلاق اتصالك عند كل تحميل للصفحة.فيما يتعلق بالتخزين المؤقت للبيانات في الجلسة، فإن هذا يعتمد على كيفية تخزين بيانات الجلسة، ومقدار الأمان الذي تحتاجه، وما إذا كانت البيانات خاصة بالمستخدم أم لا.الرهان الأفضل هو استخدام شيء آخر للتخزين المؤقت للبيانات.

Answer 6

يعد تخزين إشارات التنقل في الجلسات أمرًا صعبًا.يمكن أن يكون لدى المستخدم نفسه عدة نوافذ مفتوحة ثم يتم نشر التغييرات بطريقة مربكة.يجب أن تكون اتصالات قاعدة البيانات قطعاً لا يتم تخزينها.يحتفظ ASP.NET بمجمع الاتصال لك، فلا داعي للجوء إلى السحر الخاص بك.إذا كنت بحاجة إلى تخزين العناصر مؤقتًا لفترات قصيرة وكان حجم مجموعة البيانات صغيرًا نسبيًا، فابحث في ViewState كخيار محتمل (على حساب تحميل المزيد من الحجم على حجم الصفحة)

Answer 7

أ:البيانات المتعلقة بمستخدم واحد فقط.أي:اسم المستخدم، معرف المستخدم.في معظم كائن يمثل المستخدم.في بعض الأحيان تكون البيانات المتعلقة بعنوان URL (مثل مكان اصطحاب شخص ما) أو مجموعة رسائل الخطأ مفيدة لدفعها إلى الجلسة.

إذا كنت ترغب في مشاركة الأشياء بين مستخدمين مختلفين، فاستخدم متجر التطبيقات أو ذاكرة التخزين المؤقت.إنهم متفوقون بكثير.

Answer 8

ستيفن,
هل تعمل في شركة تبدأ بـ "I"، ولديها موقع ويب يبدأ بـ "BC"؟يبدو هذا تمامًا مثل ما فعلته عندما بدأت التطوير في .net لأول مرة (وكنت شابًا وغبيًا) - لقد حشرت كل ما يمكنني التفكير فيه في الجلسة والتطبيق.وغني عن القول أن ذلك كان سيئًا ومضاعفًا.
بشكل عام، تجنب الجلسة قدر الإمكان.بالتأكيد، لا ينبغي تخزين الكائنات غير القابلة للتسلسل هناك (اتصالات قاعدة البيانات وما شابه)، ولكن حتى الكائنات الكبيرة القابلة للتسلسل لا ينبغي أن يتم تخزينها أيضًا.أنت فقط لا تريد النفقات العامة.

Answer 9

سأحتفظ دائمًا بالقليل جدًا من المعلومات في الجلسة.تستخدم الجلسات موارد ذاكرة الخادم وهي باهظة الثمن.يؤدي حفظ عدد كبير جدًا من القيم في الجلسة إلى زيادة الحمل على الخادم وفي النهاية سينخفض ​​أداء الموقع.عند استخدام خوادم موازنة التحميل، قد يواجه استخدام الجلسة مشكلات.لذا فإن ما أفعله هو استخدام الحد الأدنى من الجلسات أو عدم استخدام أي جلسات على الإطلاق، واستخدام ملفات تعريف الارتباط إذا لم تكن المعلومات بالغة الأهمية، واستخدام الحقول المخفية بشكل أكبر وجلسات قاعدة البيانات.