state managementدرasp.net(بخش یازدهم ودوازدهم وپایانی)

State Management در ASP. NET 2.0 (بخش يازدهم)

Timeout
يكی ديگر از تنظيمات مهم در ارتباط با session state ، مشخص كردن مدت زمان timeout است . مقدار در نظر گرفته شده برای خصلت فوق ( تعريف شده در فايل web.config ) ، مدت زمان انتظار ASP.NET قبل از حذف session را مشخص می كند ( عدم دريافت هيچگونه درخواست در بازه زمانی مشخص شده ) .
در نمونه كد زير به ASP.NET اعلام شده است كه اگر پس از گذشت 20 دقيقه درخواستی از سرويس گيرنده دريافت نگرديد ، session آن را حذف كن .
<sessionState
timeout="20" />

خصلت فوق يكی از مهمترين پارامترهای مديريت session در برنامه های وب است كه عدم مقداردهی مناسب آن می تواند نتايج نامطلوبی را در ارتباط با كارآئی يك برنامه وب به دنبال داشته باشد . در زمان مقداردهی پارامتر فوق می بايست به اين نكته دقت شود كه اولا" زمان در نظر گرفته شده به اندازه ای كوتاه باشد كه سرويس دهنده بتواند پس از سپری شدن مدت زمان اندكی كه كاربر از برنامه استفاده نمی نمايد ، منبع ارزشمند حافظه را آزاد نمايد و ثانيا" كاربر بتواند بدون نگرانی در خصوص از دست دادن session خود با خيالی آسوده از برنامه استفاده نمايد .
در صورت نياز ، می توان مقداردهی پارامتر فوق را از طريق كد نيز انجام داد . به عنوان نمونه در مواردی كه يك session حاوی يك حجم غيرمتعارف از اطلاعات باشد ، می توان مدت زمان حيات session را محدودتر كرد . كد زير نحوه تغيير مقدار پارامتر فوق را به 10 دقيقه نشان می دهد .
Session.Timeout = 10

Mode
با استفاده از خصلت mode می توان نحوه ذخيره سازی اطلاعات session را مشخص كرد . به اين خصلت می توان مقاديری نظير InProc ، off ، StateServer ، SQLServer و Custom را نسبت داد . در واقع به كمك خصلت فوق ، استراتژی ذخيره سازی اطلاعات session مشخص می گردد .
در ادامه با هر يك از موارد فوق بيشتر آشنا خواهيم شد . قبل از آن لازم است به يك نكته مهم اشاره گردد . در صورتی كه برنامه ASP.NET بر روی بيش از يك سرويس دهنده وب هاست شده باشد ( كه از آن با نام web farm ياد می شود ) ، می بايست دامنه پيكربندی را گسترش داد تا اين اطمينان ايجاد شود كه سرويس دهندگان وب همساز می باشند . در غيراينصورت ، ممكن است يك سرويس دهنده اطلاعات موجود در session را با روشی متفاوت نسبت به سرويس دهنده ديگر ، رمز نمايد . بديهی است در چنين مواردی اگر كاربر از يك سرويس دهنده به سرويس دهنده ديگر هدايت شود ، در session وی اختلال ايجاد خواهد شد . برای حل اين مشكل می بايست با مراجعه به بخش <machineKey> فايل machine.config تنظميات مورد نظر را بگونه ای انجام داد كه شيوه رمزنگاری session بر روی يك سرويس دهنده با سرويس دهنده ديگر يكسان و سازگار باشد .

InProc
مقدار پيش فرض خصلت mode می باشد و عملكرد آن همانند ذخيره سازی session state در نسخه های قديمی ASP است . در اين روش اطلاعات در پردازه مشابه ASP.NET worker threads ذخيره می گردند . اين روش بالاترين كارآئی و كمترين ماندگاری را دارد . در صورتی كه سرويس دهنده به هر دليلی راه اندازی مجدد گردد ، اطلاعات session از بين خواهند رفت . روش فوق برای اكثر وب سايت های كوچك مناسب است . در مواردی كه برنامه وب در يك web farm هاست شده باشد ، از اين روش نمی توان استفاده كرد . در چنين مواردی و به منظور به اشتراگ گذاشتن اطلاعات session بين چندين سرويس دهنده ، می بايست از گزينه Out-of-Process و يا سرويس SQL Server state استفاده كرد .
در برخی موارد ممكن است برنامه نويسان به اين نتيجه رسيده باشند كه كاربران اطلاعات session خود را بدون هيچگونه دليلی از دست می دهند . همين امر باعث می شود كه آنان استفاده از گزينه ای غير از InProc را در دستور كار قرار دهند . در ASP.NET ، حوزه برنامه ها به دلايل متعددی ممكن است راه اندازی مجدد گردد ( نظير اعمال تغييرات در پيكربندی ، بهنگام سازی صفحات ) .
توجه داشته باشيد ، در زمان استفاده از StateServer و يا SQLServer ، اشيائی می توانند در session state ذخيره گردند كه قابليت سريال شدن را داشته باشند . در غيراينصورت ، ASP.NET قادر به انتقال و يا ارسال اشياء به state service و يا ذخيره آنها در بانك اطلاعاتی نخواهد بود .

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

StateServer
با در نظر گرفتن مقدار فوق برای خصلت mode ، از يك سرويس ويندوز جداگانه برای مديريت state استفاده می گردد . سرويس فوق بر روی سرويس دهنده مشابه اجراء می گردد ولی در خارج از پردازه اصلی ASP.NET قرار می گيرد . رويكرد فوق دارای مزايا و معايب مختص به خود می باشد . مهمترين مزيت استفاده از يك سرويس دهنده ديگر برای ذخيره اطلاعات session ، عدم وابستگی آن به پردازه ASP.NET است . در چنين مواردی با راه اندازی مجدد پردازه ASP.NET ( به هر دليل ) ، اختلالی در داده ذخيره شده در session ايجاد نخواهد شد چراكه آنها در يك سرويس دهنده جداگانه نگهداری شده اند . از مهمترين معايب و يا بهتر بگوئيم محدوديت های رويكرد فوق ، افزايش تاخير زمانی در زمان ارسال اطلاعات session بين دو پردازه است . بديهی است در صورتی كه فركانس دستيابی و تغيير اطلاعات ذخيره شده در session بالا باشد ، سرعت و كارآئی يك برنامه وب كاهش می يابد.
در زمان استفاده از StateServer ، می بايست مقدار stateConnectionString را مشخص كرد . پارامتر فوق ، آدرس IP كامپيوتری را كه بر روی آن سرويس StateServer اجراء شده است را به همراه شماره پورت مربوطه مشخص می نمايد ( شماره پورت توسط ASP.NET تعيين می گردد و معمولا" لزومی به تغيير آن وجود ندارد ) . بدين ترتيب ، می توان StateServer را بر روی كامپيوتر ديگر هاست كرد . در صورتی كه قصد تغيير تنظيمات پيش فرض را نداشته باشيم ، از سرويس دهنده محلی استفاده خواهد شد ( با آدرس IP : 127.0.0.1 ) .
قبل از اين كه برنامه وب بتواند از سرويس فوق استفاده نمايد ، می بايست آن را اجراء كرد . ساده ترين روش برای انجام اين كار انتخاب گزينه Services از طريق Control Panel است . با مشاهده ASP.NET State Service در ليست سرويس ها ، می توان نحوه اجراء آن را مشخص نمود ( بطور اتوماتيك ) .
در مواردی كه از StateServer استفاده می گردد ، می توان برای خصلت اختياری stateNetworkTimeout يك مقدار را مشخص نمود . پارامتر فوق ، حداكثر مدت زمان انتظار برای پاسخ سرويس دهنده بر حسب ثانيه را مشخص می نمايد . مقدار گزينه پيش فرض ، 10 ثانيه است .

SQLServer
با در نظر گرفتن مقدار فوق برای خصلت mode ، از يك بانك اطلاعاتی SQL Server برای ذخيره اطلاعات session استفاده می گردد . بانك اطلاعاتی مورد نظر توسط خصلت sqlConnectionString مشخص می گردد . روش فوق متداولترين مكانيزم برای ذخيره state در برنامه های وب می باشد ولی در مقايسه با روش های ديگر از سرعت كمتری برخوردار است .
برای استفاده از روش فوق می بايست از يك سرويس دهنده SQL استفاده شود . مقدار خصلت sqlConnectionString ، همانند الگوی استفاده شده جهت دستيابی به داده توسط ADO. NET است و شامل مشخص كردن يك منبع داده ( آدرس سرويس دهنده ) ، يك رمزعبور و شناسه كاربر ( مگر اين كه از integrated security استفاده شده باشد ) است . علاوه بر اين ، می بايست stored procedures و session موقت بانك اطلاعاتی نصب گردند . stored procedures مسئوليت ذخيره و بازيابی اطلاعات session را برعهده دارند .
ASP.NET شامل يك اسكريپت Transact-SQL برای اين هدف خاص با نام InstallSqlState.sql است كه در
مسير [ C:\[WinDir]\Microsoft.NET\Framework\[Version قرار دارد . برای اجرای اسكريپت فوق می توان از يك برنامه كاربردی SQL Server نظير SQL Server Management Studio يا sqlcmd.exe ( برای سرويس SQL 2005 ) و يا OSQL.exe و Query Analyze ( برای نسخه های قبلی ) استفاده كرد . اسكريپت فوق صرفا" يك مرتبه و به منظور ايجاد بانك ، جداول و stored procedures مورد نياز اجراء خواهد شد .
نام بانك اطلاعاتی معمولا" ASPState می باشد .در واقع ، connection string موجود در فايل web.config با صراحت نام بانك اطلاعاتی را مشخص نخواهد كرد بلكه صرفا" مكان سرويس دهنده و نوع تائيديه مشخص می گردد . كد زير نحوه انجام اين كار را نشان می دهد .
<sessionState
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"
...
/>

در صورتی كه قصد استفاده از يك بانك اطلاعاتی با نام ديگر و ساختار مشابه را داشته باشيم ، كافی است مقدار خصلت CustomSqlDatabase برابر با true در نظر گرفته شود .
<sessionState
allowCustomSqlDatabase="true"
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI;Initial Catalog=CustDatabase"
...
/>


زمانی كه از يك بانك اطلاعاتی SQL Server برای ذخيره اطلاعات session استفاده می گردد ، می توان از گزينه اختياری sqlCommandTimeout است كرد . پارامتر فوق ، حداكثر مدت زمان انتظار برای پاسخ سرويس دهنده بر حسب ثانيه را مشخص می نمايد . مقدار گزينه پيش فرض ، 30 ثانيه است .

Custom
زمانی كه برای خصلت mode مقدار custom در نظر گرفته می شود ، می بايست session state provider را با استفاده از خصلت customProvider مشخص كرد . خصلت فوق به نام يك كلاس كه بخشی از برنامه وب موجود در دايركتوری App_Code است و يا يك اسمبلی كمپايل شده موجود در دايركتوری BIN و يا GAC ، اشاره می نمايد .
ايجاد يك provider سفارشی ، مسائل مختص به خود را دارد و می بايست با دقت پياده سازی گردد تا بتواند اهدافی نظير امنيت و قابليت توسعه را به خوبی تامين نمايد . بحث بر روی provider سفارشی خارج از حوصله اين مقاله است .
برخی توليد كنندگان ممكن است نسخه هائی خاص از state provider را ارائه نمايند كه در صورت نياز و تمايل می توان از آنها استفاده كرد . به عنوان مثال ، اوراكل ممكن است يك provider سفارشی را ارائه نمايد كه امكان ذخيره اطلاعات session را در يك بانك اطلاعاتی اوراكل فراهم نمايد .
________________________________________
State Management در ASP. NET 2.0 (بخش دوازدهم)


با استفاده از application state می توان اشياء سراسری ( global ) را با هدف دستيابی توسط هر يك از سرويس گيرندگان ذخيره كرد . عملكرد application state بر اساس كلاس System.Web.HttpApplicationState می باشد كه بطور پيش فرض از طريق شی از قبل تعبيه شده Application در تمامی صفحات قابل استفاده است .
طرز كار application state مشابه session state است و از اشيائی با نوع های مشابه ، نگهداری اطلاعات در سمت سرويس دهنده و گرامر مبتنی بر ديكشنری استفاده می نمايد . استفاده از يك شمارنده سراسری به منظور نگهداری تعداد دفعاتی كه يك عمليات خاص توسط تمامی سرويس گيرندگان يك برنامه وب انجام می شود ، يك نمونه متداول استفاده از application state می باشد .
مثلا" می توان يك event handler در فايل global.asax را تعريف كرد تا تعداد session ايجاد شده و يا تعداد درخواست های دريافتی توسط يك برنامه را ثبت كند . همچنين ، می توان از روشی مشابه در Page. Load به منظور تعيين تعداد دفعاتی كه يك صفحه خاص توسط سرويس گيرندگان مختلف درخواست شده است ، استفاده كرد .
كد زير نحوه انجام اين كار را مشخص می كند .
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Dim Count As Integer = CType(Application("HitCounter"), Integer)
Count += 1
Application("HitCounter") = Count
lblCounter.Text = Count.ToString()
End Sub

لازم است مجددا" به اين نكته اشاره گردد كه آيتم های application state به عنوان شی ذخيره می گردند ، بنابراين می بايست در زمان بازيابی آنها را cast كرد . تاريخ اعتبار و يا مصرف آيتم های ذخيره شده در application state هرگز به اتمام نخواهد رسيد و تا زمانی كه برنامه و يا سرويس دهنده راه اندازی مجدد نگردد و يا حوزه برنامه خود را refresh ننمايد ( به علت تنظيمات ادواری اتوماتيك پردازه و يا بهنگام سازی يكی از صفحات و يا عناصر موجود در برنامه ) ، امكان استفاده از آنها وجود خواهد داشت .
امروزه اغلب از application state به دليل عدم كارآئی مناسب استفاده نمی شود . در مثال قبل ، همواره اين احتمال وجود خواهد داشت كه در شمارنده مقدار درستی ذخيره نگردد ( خصوصا" در مواردی كه ترافيك بالا باشد ) . به عنوان مثال ، در صورتی كه دو سرويس گيرنده در يك زمان مشابه صفحه ای را درخواست نمايند ، دارای مجموعه ای از رويدادها به شرح ذيل خواهيم بود :

* كاربر A مقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .
* كاربر B مقدار جاری شمارنده را ( فرضا" عدد 432 ) بازيابی می نمايد .
* كاربر A مقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .
* كاربر B مقدار شمارنده را تغيير و آن را به 433 تغيير می دهد .

به عبارت ديگر ، يكی از درخواست ها باعث افزايش شمارنده نمی گردد ، چراكه دو سرويس گيرنده بطور همزمان به شمارنده دستيابی داشته اند . برای پيشگيری از بروز اين مسئله ، می بايست از متدهای Lock و Unlock استفاده كرد . با استفاده از متدهای فوق در هر لحظه صرفا" به يك سرويس گيرنده اجازه دستيابی به مجموعه application state داده می شود .
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Application.Lock()
Dim Count As Integer = CType(Application("HitCounter"), Integer)
Count += 1
Application("HitCounter") = Count
Application.Unlock()
lblCounter.Text = Count.ToString()
End Sub

ساير سرويس گيرندگانی كه صفحه را درخواست می نمايند می بايست تا زمانی كه مجموعه application state آزاد نشده است ، منتظر بمانند . اين وضعيت می تواند كاهش كارآئی برنامه را به دنبال داشته باشد .
به عنوان يك قانون كلی ، مقاديری كه دائما" و با فركانس بالا تغيير می يابند نمی توانند كانديدی مناسب جهت استفاده از application state باشند .
application state در دنيای دات نت بندرت استفاده می شود چراكه دو كاربرد متداول استفاده از آن با روش های موثرتر ديگر جايگزين شده است .

*

در گذشته ، از application state برای ذخيره ثوابت در سطح برنامه نظير يك connection string بانك اطلاعاتی استفاده می گرديد . هم اينك در دات نت می توان اين نوع ثوابت را به سادگی در فايل web.config كه به مراتب از انعطاف بيشتری برخوردار است ذخيره نمود .
*

در گذشته برای ذخيره اطلاعاتی كه در يك برنامه از آنها بدفعات استفاده می گرديد و برای توليد اين اطلاعات زمان زيادی صرف می گرديد ، استفاده می شد ( نظير يك كاتولوگ كامل از محصولات ) . افزايش حجم كاتالوگ و معتبر سازی داده موجود در اينچنين كاتالوگ هائی ، همواره از مشكلات برنامه نويسان بوده است . هم اينك و با استفاده از دات نت می توان از فنآوری cache كه دارای كارآئی بمراتب بالاتری نسبت به روش های پيشين و بكارگرفته شده در application state است ، استفاده كرد .

فايل Global.asax
با استفاده از فايل global.asax می توان كد مورد نياز جهت برخورد با رويدادهائی در سطح برنامه را ايجاد كرد . رويدادهای فوق در نقاط مختلفی از چرخه حيات يك برنامه وب محقق می گردند ( مثلا" زمانی كه session ايجاد می گردد ) . همين موضوع باعث شده است كه فايل global.asax بتواند در تعامل مناسب با ويژگی های state management قرار بگيرد . مثلا" می توان از فايل global.asax برای مقداردهی اوليه مجموعه ای از اشياء كه قصد داريم آنها را در application state ذخيره نمائيم ، استفاده كرد .
فايل global.asax ، همانند يك فايل aspx . است . با اين تفاوت كه اين نوع فايل ها نمی توانند شامل تگ های HTML و يا ASP. NET باشند . در مقابل می توان در آنها event handler مورد نياز را قرار داد . مثلا" فايل global.asax زير در مقابل رويداد Application.EndRequest از خود واكنش نشان می دهد ( رويدادی كه قبل از ارسال صفحه برای كاربر محقق می گردد ) .
<%@ Application Language="VB" %>
<script runat="server">
Sub Application_EndRequest(ByVal sender As Object, ByVal e As EventArgs)
Response.Write("<hr>This page was served at " & DateTime.Now.ToString())
End Sub
</script>

event handler فوق از متد write شی از قبل تعبيه شده Response برای نوشتن يك footer در پائين صفحه ( تاريخ و زمان ايجاد صفحه ) استفاده می نمايد .
هر برنامه ASP.NET می تواند دارای يك فايل global.asax باشد كه پس از استقرار در دايركتوری مجازی مربوطه ، ASP.NET آن را بطور اتوماتيك تشخيص و از آن استفاده خواهد كرد . مثلا" ، اگر فايل global.asax فوق را در يك دايركتوری مجازی قرار دهيم ، شاهد نمايش يك footer در پائين هر يك از صفحات موجود در برنامه خواهيم بود .
اضافه كردن يك footer اتوماتيك در پائين صفحات ، يك عمليات مفيد برای سايت های حرفه ای نمی باشد . نوشتن يك ركورد در يك بانك اطلاعاتی مختص ثبت وقايع ( log ) ، شايد كاربرد مناسب تری از ويژگی فوق را نشان دهد . هم اينك تعداد زيادی از برنامه نويسان برنامه های وب تمايل به استفاده از فايل global.asax را ندارند . فايل فوق از مدل code-behind حمايت می نمايد .

رويدادهای Application
Application.EndRequest ، صرفا" يكی از رويدادهای موجود جهت استفاده در فايل global.asax است . برای ايجاد يك event handler متفاوت ، می توان يك روتين با نام دلخواه را ايجاد كرد .
برخی از متداولترين رويدادهای application عبارتند از :

*

Application_Start : در زمان آغاز به كار برنامه و دريافت اولين درخواست توسط هر يك از كاربران ، محقق می گردد . رويداد فوق در پاسخ به درخواست های بعدی محقق نخواهد شد . از اين رويداد معمولا" برای ايجاد و يا cache برخی اطلاعات اوليه استفاده می شود.
*

Application_End : رويداد فوق پس از اتمام فعاليت برنامه ، محقق می گردد ( عمدتا" زمانی كه سرويس دهنده وب راه اندازی مجدد می گردد ) . در روتين مربوطه می توان كد مورد نياز برای پاكسازی را درج كرد .
*

Application_BeginRequest : رويداد فوق پس از دريافت هر درخواست توسط برنامه ، محقق می گردد ( قبل از اجرای كد صفحه ) .
*

Application_EndRequest : رويداد فوق پس از دريافت هر درخواست توسط برنامه ، محقق می گردد ( پس از اجرای كد صفحه ) .
*

Session_Start : رويداد فوق زمانی محقق می گردد كه درخواست يك كاربر جديد دريافت و يك session فعاليت خود را آغاز نمايد .
*

Session_End : رويداد فوق زمانی محقق می گردد كه مدت زمان حيات يك session به اتمام رسيده باشد ( از طريق كد و يا بطور اتوماتيك ) .
*

Application_Error : رويداد فوق در پاسخ به يك خطاء غيرقابل پيش بينی، محقق می گردد .
________________________________________
State Management در ASP. NET 2.0 (بخش پايانی)


state management ، فرآيندی است كه به كمك آن می توان اطلاعاتی را بين درخواست های متعدد ، نگهداری كرد . اطلاعات فوق معمولا" شامل دو دسته می باشند :

*

اطلاعات در ارتباط با يك كاربر : نظير ليست كالاهای موجود در يك سبد خريد ، نام كاربر و يا يك سطح دستيابی خاص
*

اطلاعات قابل استفاده در تمامی برنامه : نظير آمارهائی كه فعاليت هائی خاص از يك سايت را ثبت می نمايد .

با توجه به اين كه ASP.NET از يك معماری disconnected استفاده می نمايد ، لازم است كه با هر درخواست اطلاعات state ذخيره و آنها را در زمان مورد نياز بازيابی كرد .
استراتژی انتخاب شده برای ذخيره سازی state می تواند بطرز كاملا" محسوسی بر روی پارامترهائی نظير كارآئی ، قابليت گسترش و امنيت يك برنامه وب تاثيرگذار باشد .
________________________________________