State Management در ASP. NET 2.0 (بخش هشتم)
آنچه تاكنون گفته شده است :

در اين بخش به بررسی Session State  خواهيم پرداخت .

مفاهيم و چالش ها
در مدت زمان حيات يك برنامه به مواردی برخورد می كنيم كه لازم است جهت ذخيره سازی اطلاعات از امكانات پيشرفته تری استفاده گردد . به عنوان مثال ، يك برنامه ممكن است به ذخيره اطلاعات پيچيده ای نظير اشياء سفارشی داده و استفاده از آنها در ساير صفحات نياز داشته باشد . ارسال اينگونه اطلاعات از طريق كوكی و يا يك query string مشكل و يا غيرممكن است . علاوه بر اين ، در برخی موارد ملاحظات امنيتی در رابطه با داده وجود دارد  و نمی توان اطلاعات مربوط به يك سرويس گيرنده را در view state و يا كوكی ذخيره كرد .
در چنين مواردی می توان از امكانات از قبل تعبيه شده session state در ASP.NET استفاده كرد .
مديريت session state يكی از ويژگی های برجسته ASP.NET است كه به كمك آن می توان هر نوع داده ئی را در حافظه سرويس دهنده ذخيره كرد . بدين ترتيب ، يك سطح حفاظتی مطلوب در خصوص داده ايجاد خواهد شد چراكه اطلاعات برای سرويس گيرنده ارسال نخواهند شد و برای هر جلسه كاری منحصربفرد می باشند .
هر سرويس گيرنده ای كه به برنامه دستيابی داشته باشد دارای يك session متفاوت و مجموعه ای از اطلاعات متمايز و مختص به خود است . session state برای ذخيره اطلاعاتی نظير آيتم های خريداری شده توسط كاربر از يك سايت و استقرار آنها در سبد خريد در زمان حركت از يك صفحه به صفحه ديگر بسيار مفيد و موثر واقع می شود .
با استفاده از session state می توان اطلاعات مورد نظر را از طريق يك صفحه ذخيره و در ساير صفحات از آنها استفاده كرد .
با اين كه session state بسياری از مشكلات در ارتباط با ساير روش های مديريت state را برطرف نموده است ولی خود نيز دارای چالش های مختص به خود است . به عنوان مثال ، با بكارگيری روش فوق در برنامه های وب ، سرويس دهنده وب ملزم به ذخيره اطلاعات بيشتری در حافظه سرويس دهنده خواهد شد.  اين موضوع می تواند همزمان با افزايش كاربران يك برنامه بر روی كارآئی آن تاثير بگذارد . چراكه درصد استفاده از يك منبع محدود ( حافظه ) افزايش خواهد يافت .  بنابراين ، لازم است استفاده از session state  با دقت و بررسی تمامی جوانب كار صورت پذيريد .

معماری session
 مديريت session به عنوان بخشی از استاندارد HTTP محسوب نمی گردد . بنابراين لازم است كه ASP.NET عمليات بيشتری را به منظور پيگيری اطلاعات session انجام دهد .
ASP.NET هر session را از طريق يك شناسه 120 بيتی منحصربفرد پيگيری و از يك الگوريتم اختصاصی برای توليد آن استفاده می نمايد .  بنابراين حداقل اين تضمين از لحاظ تئوری ايجاد می گردد كه عدد توليد شده منحصر بفرد بوده و به اندازه كافی تصادفی است  تا امكان و يا احتمال تشخيص و حدس آن توسط مهاجمان به حداقل مقدار خود برسد ( مهاجمان با بكارگيری روش هائی موسوم به مهندسی معكوس در تلاش جهت آگاهی از اين موضوع هستند كه يك سرويس گيرنده خاص از چه شناسه ای برای session استفاده می نمايد ) . 
شناسه ، تنها اطلاعات مبادله شده بين سرويس دهنده وب و سرويس گيرنده است . زمانی كه سرويس گيرنده شناسه session خود را  ارائه می نمايد ، ASP.NET  در اولين اقدام جستجو جهت يافتن session متناظر با آن را انجام می دهد . در صورتی كه ماحصل فرآيند فوق مثبت باشد ، داده از state server بازيابی و به اشياء مورد نظر تبديل می گردد . در ادامه ، اشياء فوق در يك مجموعه خاص استقرار می گردند تا امكان دستيابی به آنها از طريق كد وجود داشته باشد . فرآيند فوق بطور اتوماتيك انجام می شود . 
شايد برای شما اين سوال مطرح شده باشد كه ASP.NET ، اطلاعات مربوط به session را در چه مكانی ذخيره و چگونه آنها را serialize و deserialize می نمايد ؟ در  ASP كلاسيك ، session state به عنوان يك شی COM پياده سازی شده است كه در كتابخانه asp.dll  مستقر می گردد . در ASP.NET ، اينترفيس برنامه نويسی تقريبا" يكسان است ولی نحوه پياده سازی آن با ASP كلاسيك كاملا" متفاوت است .
زمانی كه ASP.NET يك درخواست HTTP را بررسی می نمايد ، آن را از طريق مجموعه ای از مدول های مختلف كه قادر به واكنش در خصوص رويدادهای برنامه می باشند ، به حركت در می آورد . SessionStateModule ، يكی از مدول های موجود در اين زنجيره است ( موجود در namespace با نام  System.Web.SessionState ) . مدول فوق شناسه session را توليد ، داده session را از ارائه دهندگان خارجی state بازيابی و داده را  به درخواست مورد نظر نسبت می دهد . همچنين مدول فوق ، اطلاعات مربوط به session را پس از اتمام پردازش صفحه ، ذخيره می نمايد.
توجه داشته باشيد كه مدول SessionStateModule عملا" داده session را ذخيره نمی نمايد . در واقع ، داده session در عناصر مجزاء نگهداری می گردد كه به آنها state provider می گويند .
شكل 1 معماری session state در ASP.NET را نشان می دهد .  

شكل 1 : معماری session state در ASP.NET

نكته آخر در ارتباط با معماری فوق نحوه پيگيری كوكی از يك درخواست به درخواست ديگر است . برای اين كه session state به درستی كار كند ، سرويس گيرنده می بايست شناسه session خود را همراه با هر درخواست ارائه نمايد . بدين منظور از دو روش مختلف استفاده می گردد .

•  استفاده از  كوكی : در اين حالت ، شناسه session از طريق يك كوكی خاص  (ASP.NET_SessionId) كه ASP.NET بطور اتوماتيك و در زمان استفاده از مجموعه session آن را ايجاد می نمايد ، ارسال می گردد . گزينه فوق به صورت پيش فرض انتخاب می گردد و مشابه رويكردی است كه از آن در نسخه های اوليه ASP  استفاده می گرديد .

•  استفاده از URLs اصلاح شده : در اين حالت ، شناسه session از طريق يك URL اصلاح شده خاص ارسال می گردد . گزينه فوق يك ويژگی جديد در ASP.NET است و به پياده كنندگان اجازه می دهد در مواردی كه سرويس گيرنده از كوكی حمايت نمی نمايد ، از session state در برنامه های وب استفاده نمايند .

استفاده از session state
با استفاده از كلاس  System.Web.SessionState.HttpSessionState  كه در يك صفحه ASP.NET به عنوان شی session از قبل تعبيه شده پيش بينی شده است ، می توان با session state ارتباط برقرار كرد . نحوه اضافه كردن و بازيابی داده در مجموعه session state همانند  view state است .
مثلا" می توان يك Dataset را در session قرار داد . كد زير نحوه انجام اين كار را نشان می دهد .

كد زير نحوه بازيابی و تبديل داده ذخيره شده در session را نشان می دهد .

امكان دستيابی به session state در تمامی برنامه و برای كاربر جاری امكان پذير است . session state به دلايل متعددی ممكن است از بين رود :

• بستن و فعال كردن مجدد مرورگر توسط كاربر

• دستيابی به صفحه مشابه از طريق يك پنجره جداگانه مرورگر توسط كاربر

• اتمام تاريخ اعتبار session به دليل عدم فعاليت كاربر در يك بازه زمانی خاص   ( مقدار پيش فرض 20 دقيقه )

• خاتمه دادن به عمر مفيد يك session از طريق كد و توسط برنامه نويس  ( استفاده از متد Session.Abandon)

در دو مورد اول ، session همچنان در حافظه باقی خواهد ماند چراكه سرويس دهنده وب از بستن مرورگر و يا تغيير پنجره توسط كاربر آگاهی ندارد . در چنين مواردی ، session آخرين لحظات عمر خود را در حافظه طی می نمايد و عملا" غيرقابل دسترس باقی می ماند تا زمانی كه عمر آن به اتمام رسد .
علاوه بر موارد فوق ، زمانی كه application domain مجددا" ايجاد گردد ، session state حذف خواهد شد . فرآيند فوق در زمان بهنگام سازی برنامه و يا تغيير در تنظيمات پيكربندی انجام می شود .
همچنين به منظور حصول اطمينان از صحت عملكرد برنامه ، application domain بطور ادواری بازسازی می شود . در صورتی كه رويكرد فوق باعث بروز مسائلی می گردد ، می توان اطلاعات session state را به صورت out of process ذخيره كرد ( در بخش بعد در اين رابطه توضيح خواهيم داد ) . در مدل نگهداری state به صورت out-of-process ، اطلاعات session حتی با غيرفعال شدن application domain همچنان باقی خواهند ماند .
جدول 1  ، متدها و خصلت های مختلف كلاس  HttpSessionState را نشان می دهد .

جدول 1  : متدها و خصلت های كلاس  HttpSessionState

در بخش نهم بحث خود را در ارتباط با session state  ادامه داده و به بررسی يك نمونه مثال كاربردی خواهيم پرداخت  .