یکی از مهمترین تفاوت های موجود بین برنامه های وب و Desktop ، مدیریت state است که در آن می بایست به این پرسش پاسخ داده شود که نحوه نگهداری اطلاعات در ارتباط با کاربر جاری به چه صورت است ؟
در یک برنامه سنتی ویندوز ، state بطور اتوماتیک مدیریت می گردد . حافظه به حد فراوان یافت می شود و همواره در دسترس است . در برنامه های وب داستان بگونه ای دیگر است . هزاران کاربر ممکن است بطور همزمان برنامه ای مشابه را بر روی کامپیوتری یکسان ( سرویس دهنده وب ) اجراء و هر یک از آنان از طریق پروتکل HTTP ( برگرفته شده از Hypertext Transfer Protocol) که دارای ماهیتی stateless است با سرویس دهنده وب ارتباط برقرار نمایند . مجموعه شرایط فوق باعث شده است که نتوان برنامه های وب را با سناریوئی دقیقا" مشابه با برنامه های سنتی ویندوز طراحی و پیاده سازی کرد .
هیچگونه فریمورک برنامه نویسی وب ، صرفنظر از میزان پیشرفته بودن آن ، نمی تواند ماهیت stateless بودن پروتکل HTTP را تغییر دهد. پس از هر درخواست و پاسخ به آن ، ارتباط منطقی سرویس گیرنده با سرویس دهنده قطع خواهد شد . معماری فوق ، این اطمینان را ایجاد می نماید که برنامه های وب بتوانند به هزاران کاربر بطور همزمان و بدون نگرانی در خصوص حافظه پاسخ دهند . استفاده از روش های مختلف برای ذخیره اطلاعات بین درخواست های متعدد یک کاربر و بازیابی آنها در زمانی که به آنها نیاز است از جمله مشکلات معماری فوق برای پیاده کنندگان برنامه های وب محسوب می گردد .
آشنائی و درک مناسب نسبت به محدودیت های state ، یکی از مفاهیم کلیدی در زمان ایجاد برنامه های وب کارآ و قدرتمند است .
در مجموعه مقالاتی که در این خصوص آماده و بتدریج بر روی سایت منتشر خواهد شد به بررسی موارد زیر خواهیم پرداخت :

* آشنائی با مفاهیم ، جایگاه و لزوم مدیریت state در برنامه های وب
* آشنائی با پتانسیل های ارائه شده در ASP. NET 2.0 برای ذخیره سازی و مدیریت اطلاعات
* آشنائی با گزینه های متفاوت موجود به منظور مدیریت state نظیر View state ، Session state ، کوکی های سفارشی
* نحوه انتقال اطلاعات از یک صفحه به صفحه دیگر

مدیریت state و مسائل در ارتباط با آن
در یک برنامه سنتی ویندوز ، کاربران با یک برنامه در حال اجراء بطور پیوسته ارتباط برقرار می نمایند . بخشی از حافظه موجود بر روی کامپیوتر Desktop برای ذخیره تنظیمات جاری اطلاعات محیط کار کاربر اختصاص داده می شود .
در یک برنامه وب ، داستان کاملا" متفاوت است . شاید از دید کاربران یک سایت حرفه ای اینگونه برداشت شود که یک برنامه بطور مستمر در حال اجراء است و به آنان سرویس های لازم را می دهد . علی رغم این که ظاهر موضوع درست بنظر می آید ولی در پس پرده داستان بگونه ای دیگر دنبال می شود . برنامه های وب از یک الگوی دستیابی غیرمتصل کارآ استفاده می نمایند . در این الگو ، سرویس گیرنده پس از ارتباط با سرویس دهنده از آن درخواست یک صفحه را می نماید . پس از پاسخ به سرویس گیرنده ،ارتباط منطقی ایجاد شده قطع و سرویس دهنده بی خیال هر گونه اطلاعاتی در رابطه با سرویس گیرنده می گردد . پس از دریافت صفحه درخواستی توسط سرویس گیرنده ، برنامه اجراء خود را متوقف و ASP.NET engine اشیاء مربوط به صفحه را دور می اندازد .
با توجه به این که سرویس گیرندگان لازم است در اکثر موارد صرفا" برای چندین ثانیه متصل باشند ، یک سرویس دهنده وب می تواند به هزاران درخواست با کارآئی مطلوب پاسخ دهد .
در صورتی که لازم است اطلاعات بین چندین عملیات کاربر نگهداری شوند ، می بایست از راهکارهای مختلفی به منظور مدیریت state استفاده کرد .

View state
همانگونه که اطلاع دارید کنترل های سرویس دهنده ASP.NET از view state برای بخاطر سپردن state استفاده می نمایند . اطلاعات view state در یک فیلد مخفی نگهداری شده و بطور اتوماتیک پس از هر postback برای سرویس دهنده ارسال می گردد . view state محدود به کنترل های سرویس دهنده نمی گردد و در صورت ضرورت می توان مجموعه ای از اطلاعات مورد نیاز را مستقیما" در مجموعه view state ذخیره تا امکان بازیابی آنها پس از هر postback فراهم شود . نوع های مختلفی را می توان در view state ذخیره نمود . نوع های داده ساده و اشیاء سفارشی نمونه هائی در این زمینه می باشند .
خصلت ViewState صفحه، مجموعه view state را ارائه می نماید . این خصلت یک نمونه از کلاس مجموعه StateBag است .برای اضافه کردن و حذف آیتم هائی در این کلاس ، از گرامری مشابه با یک دیکشنری استفاده می گردد که در آن هر آیتم دارای یک نام منحصر بفرد است .
کد زیر نحوه استفاده از view state را نشان می دهد .

ViewState("Counter") = 1

دستور فوق ، مقدار 1 را در مجموعه view state قرار داده و به آن یک نام منحصربفرد را نسبت می دهد ( Counter ) . در صورتی که آیتم دیگری با همین نام در view state موجود نباشد ، یک آیتم جدید بطور اتوماتیک به آن اضافه می گردد . در صورتی که یک آیتم با نام Counter در view state موجود باشد ، با مقدار فوق جایگزین می گردد .
برای بازیابی آیتم های ذخیره شده در view state از نام نسبت داده شده به هر یک از آنها استفاده می گردد . همچنین ، لازم است که مقدار بازیابی شده را با استفاده از گرامر casting به نوع داده مناسب تبدیل نمود چراکه مجموعه ViewState تمامی آینم ها را به عنوان اشیاء عام ذخیره می نماید تا بتواند با نوع های داده مختلف سرو کار داشته باشد .
کد زیر نحوه بازیابی مقدار نسبت داده شده به Counter از view state و تبدیل آن به یک عدد صحیح را نشان می دهد .

Dim counter As Integer
counter = CType(ViewState("Counter"), Integer)

در صورت عدم وجود اطلاعات مورد نظر در view state با یک NullReferenceException مواجه خواهیم شد . بنابراین ، لازم است که همواره قبل از بازیابی و تبدیل داده ذخیره شده در view state از وجود آن در ساختار فوق اطمینان حاصل نمود .
برای آشنائی بیشتر با نحوه بکارگیری view state در برنامه های وب به بررسی یک نمونه مثال کاربردی خواهیم پرداخت .

مثال : ثبت تعداد دفعاتی که بر روی یک دکمه کلیک می گردد
کد زیر یک برنامه ساده شمارنده را نشان می دهد که در آن تعداد دفعاتی که بر روی یک دکمه کلیک می شود تشخیص داده شده و تعداد آن در خروجی نمایش داده می شود . بدون استفاده از یک راهکار مناسب برای مدیریت state ، شمارنده بطور دائم عدد 1 را در خروجی نشان خواهد داد .
برای ایجاد خروجی مورد نظر ، می بایست از یک راهکار مناسب (view state ) جهت مدیریت state استفاده گردد .

<%@ Page Language="VB" Culture="fa-IR" UICulture="fa-IR" %>

< ="server">
Sub cmdIncrement_Click(ByVal sender As ,ByVal e As EventArgs) Handles cmdIncrement.Click
Dim Counter As Integer
If ViewState("Counter") Is Nothing Then
Counter = 1
Else
Counter = CType(ViewState("Counter"), Integer) + 1
End If
ViewState("Counter") = Counter
lblCount.Text = "مقدار شمارنده برابر است با : " & Counter.ToString()
End Sub
</>

<html xmlns="http://www.w3.org/1999/xhtml" dir="rtl" >
<head id="Head1" ="server">
<title>تست view state </title>
</head>
<body style="font-family: Tahoma">
<form id="form1" ="server">
<div>
<asp:Button ID="cmdIncrement" ="server"
Text="افزایش شمارنده" Font-Names="Tahoma" /><br /><br />
<asp:Label ID="lblCount" ="server"
Font-Names="Tahoma"></asp:Label>&nbsp;
</div>
</form>
</body>
</html>

در کد فوق قبل از تلاش برای بازیابی آیتم مورد نظر از view state ، وجود آن در ساختار فوق بررسی می گردد . شکل 1 خروجی برنامه فوق را نشان می دهد .

http://www.srco.ir/Articles/Images/StateManagement1.jpg

برای حل مسئله مدیریت state در مثال فوق و نگهداری مقدار counter در بین چندین postback از روش هائی دیگر نیز می توان استفاده کرد . به عنوان مثال ، می توان برای کنترل سرویس دهنده label ویژگی view state را فعال و از label برای ذخیره مقدار counter استفاده نمود . هر مرتبه که بر روی دکمه "افزایش شمارنده " کلیک گردد ، مقدار جاری از طریق خصلت text کنترل label بازیابی و پس از تبدیل به یک عدد صحیح در خروجی نمایش داده می شود .
از روش فوق نمی توان همواره به عنوان یک راهکار مناسب استفاده کرد . مثلا" ممکن است قصد ایجاد برنامه ای را داشته باشیم که تعداد دفعاتی را که بر روی یک دکمه کلیک می گردد ثبت نماید ولی قصد نمایش نتایج را در خروجی نداشته باشیم . در چنین مواردی می توان همچنان اطلاعات را در یک کنترل سرویس دهنده ذخیره نمود ولی مجبور خواهیم بود که آن را مخفی نگاه داریم .
پس از انجام تمامی این کارها ، به چیزی می رسیم که view state آن را در اختیار ما قرار می دهد . view state ، اطلاعات را بطور اتوماتیک در یک فیلد مخفی خاص در صفحه نگهداری می نماید . با توجه به این که ASP. NET با جزئیات این کار سروکار دارد ، کد نوشته شده توسط پیاده کنندگان از خوانائی بیشتری برخوردار خواهد بود .

منبع مقاله :‌
www.srco.ir

State Management در ASP. NET 2.0 (بخش دوم)


در بخش اول به ضرورت مدیریت state در برنامه های وب اشاره و در ادامه به بررسی اولین گزینه موجود (view state ) پرداختیم . در این بخش با نحوه ایمن سازی اطلاعات ذخیره شده در view state آشنا خواهیم شد .
اطلاعات view state در یک رشته درهم آمیخته مشابه زیر ذخیره می گردد .

کد:
<input type="hidden"
name="__VIEWSTATE"
value="/wEPDwUKMTUyMzMyNzc3NGRklXVE/6qqfC5AWkr1Yw0Xu5IpHg0="
/>


به موازات اضافه کردن اطلاعات بیشتر به view state ، طول این رشته طولانی تر خواهد شد . با توجه به این که مقدار ذخیره شده در رشته فوق به صورت متن شفاف نمی باشد ، بسیاری از برنامه نویسان ASP.NET بر این باور هستند که داده ذخیره شده در view state به صورت رمز شده است .ولی واقعیت اینچنین نیست . در واقع ، اطلاعات view state به سادگی در حافظه به یکدیگر متصل شده و به یک رشته Base64 تبدیل می شوند .یک هکر باهوش می تواند با استفاده از مهندسی معکوس رشته فوق ، view state را بررسی و از اطلاعات ذخیره شده در آن به سرعت آگاه گردد .
کد زیر نحوه رمز کردن یک رشته معمولی را به یک رشته Base64 نشان می دهد .

کد:
Private Function EncodeBase64(ByVal input As String) As String
Dim strBytes() As Byte = System.Text.Encoding.UTF8.GetBytes(input)
Return System.Convert.ToBase64String(strBytes)
End Function

کد زیر نحوه رمز گشائی یک رشته Base64 را به یک رشته معمولی نشان می دهد .
کد:
Private Function DecodeBase64(ByVal input As String) As String
Dim strBytes() As Byte = System.Convert.FromBase64String(input)
Return System.Text.Encoding.UTF8.GetString(strBytes)
End Function

در صورتی که لازم است اطلاعات ذخیره شده در view state دارای ایمنی بیشتری باشند از دو گزینه مختلف می توان استفاده کرد :

گزینه اول : به ASP. NET اعلام شود که از یک hash code استفاده نماید. برخی اوقات از hash code به عنوان یک checksum قدرتمند پنهانی نیز یاد می شود . در چنین مواردی ، ASP. NET تمامی داده ذخیره شده در view state را بررسی و یک الگوریتم hashing را بر روی آن اعمال می نماید . الگوریتم فوق یک سگمنت کوتاه از داده را ایجاد می نماید که در واقع همان hash code است . در ادامه ، کد فوق به انتهای داده ذخیره شده در view state اضافه می گردد .
زمانی که صفحه post back می گردد ، ASP. NET داده موجود در view state را بررسی و مجددا" hash code را با استفاده از فرآیندی مشابه تولید می نماید . در ادامه مقدار محاسبه شده با مقدار موجود در رشته مقایسه می گردد تا این اطمینان حاصل شود که داده ذخیره شده در view state تغییر نکرده باشد .
در صورتی که یک کاربر بداندیش بخشی از داده موجود در view state را تغییر دهد ، ASP. NET یک hash code را تولید خواهد کرد که با کد ذخیره شده در انتهای view state مطابقت نخواهد کرد . در صورت تحقق چنین شرایطی ، postback بطور کامل نادیده گرفته خواهد شد .
شاید در ذهن شما این موضوع مطرح شده باشد که یک کاربر باهوش می تواند با بکارگیری ترفندهائی بر مشکل اشاره شده غلبه کرده و علاوه بر تولید اطلاعات نادرست ، یک hash code مناسب و منطبق بر اطلاعات ذخیره شده در view state را نیز تولید نماید . در پاسخ می بایست به این نکته اشاره کرد که کاربران بداندیش قادر به تولید hash code صحیح نخواهند بود چراکه آنان دارای کلید رمزنگاری مشابه ASP. NET نمی باشند . این بدان معنی است که hash code تولید شده با وضعیت موجود نمی تواند مطابقت نماید .
hash code بطور پیش فرض فعال است . بنابراین در صورت تمایل به استفاده از پتانسیل فوق ، لازم نیست که مراحل اضافه ای را دنبال نمود . در برخی موارد پیاده کنندگان ویژگی فوق را غیرفعال می نمایند تا از مشکلات احتمالی موجود در یک web farm پیشگیری نمایند . در چنین وضعیتی ، سرویس دهندگان مختلف دارای کلیدهای مختلفی می باشند و مشکل زمانی اتفاق می افتد که پس از post back صفحه ، یک سرویس دهنده جدید آن را دریافت نماید .
در یک محیط web farm کلید می بایست در بین تمامی سرویس دهندگان یکسان باشد . در صورتی که کلید یکسان نباشد و صفحه برای یک سرویس دهنده متفاوت با سرویس دهنده ای که صفحه را ایجاد کرده است ، post back گردد ، یک خطاء ایجاد خواهد شد .بنابراین در یک محیط web farm ، می بایست پیاده کنندگان یک کلید را در فایل Machine.config مشخص نمایند ( در مقابل این که به ASP.NET اجازه داده شود که این کلید را بطور اتوماتیک ایجاد نماید) .
برای غیرفعال کردن hash codes ، می بایست از خصلت enableViewStateMac عنصر <pages> در فایل web.config و یا machine.config به صورت زیر استفاده کرد .
کد:
<configuration >
<system.web>
<pages enableViewStateMac="false" />
...
</system.web>
</configuration>


گزینه دوم : با ایجاد یک کد hash ، فریمورک ASP. NET این موضوع را بررسی خواهد کرد که آیا داده ذخیره شده در view state دستکاری شده است ؟ علی رغم ایجاد این لایه امنیتی ، داده موجود در view state همچنان قابل مشاهده توسط کاربران بداندیش خواهد بود .
در صورتی که بر روی داده ذخیره شده در view state حساسیت زیادی وجود داشته باشد و بخواهیم امنیت آن را افزایش دهیم ، می بایست رمزنگاری view state را فعال کرد . برای فعال کردن ویژگی فوق از خصلت ViewStateEncryptionMode به همراه دایرکتیو page استفاده می گردد .

کد:
<%@Page ViewStateEncryptionMode="Always" %>


در صورت تمایل می توان از خصلت فوق در فایل پیکربندی نیز استفاده کرد .
کد:
<configuration >
<system.web>
<pages viewStateEncryptionMode="Always" />
...
</system.web>
</configuration>


به خصلت ViewStateEncryptionMode یکی از مقادیر زیر را می توان نسبت داد :

*

Always : همواره رمزنگاری انجام می شود .
*

Never : رمزنگاری انجام نخواهد شد .
*

Auto : رمزنگاری صرفا" در مواردی که یک کنترل با صراحت آن را درخواست نماید ، انجام خواهد شد .

گزینه پیش فرض Auto است . این بدان معنی است که یک کنترل با فراخوانی متد Page.RegisterRequiresViewStateEncryption رمزنگاری را درخواست می نماید . در صورتی که یک کنترل به دلیل عدم داشتن اطلاعات حساس از متد فوق استفاده نکند ، view state رمز نخواهد شد و عملیات بیشتری جهت رمزنگاری به سیستم تحمیل نخواهد شد . به عبارت دیگر ، یک کنترل زمانی می تواند دل خود را به خدمات ارائه شده توسط متد فوق خوش نماید که مقدار خصلت viewStateEncryptionMode ، معادل Auto در نظر گرفته شده باشد . در صورتی که مقدار خصلت فوق Never در نظر گرفته شده باشد ، به درخواست کنترل ها جهت رمزنگاری پاسخ داده نخواهد شد.
با توجه به این که رمزنگاری عملیات بیشتری را به سرویس دهنده وب تحمیل می نماید ( هم در زمان رمزنگاری و هم در زمان رمزگشائی پس از هر post back ) در صورت عدم نیاز به پتانسیل فوق و به منظور عدم تاثیرگذاری آن بر روی کارآئی برنامه های وب ، ضرورتی به فعال کردن آن وجود ندارد .

State Management در ASP. NET 2.0 (بخش سوم)


این بخش به بررسی نحوه نگهداری member variable و اشیاء سفارشی در view state خواهیم پرداخت .
اجازه دهید قبل از تشریح موارد فوق ، در ابتدا اشاره ای به انواع متعیرها داشته باشیم .

انواع متغیرها
پس از ایجاد ساختار اولیه یک کلاس ، می بایست عناصر داده پایه را به آن اضافه نمود .
در کد زیر ، سه member variable تعریف شده است که اطلاعاتی را در ارتباط با product ( شامل نام ، قیمت و URL آن که به یک فایل image اشاره می نماید ) در خود نگهداری می نمایند .

Public Class Product
Private name As String
Private price As Decimal
Private imageUrl As String
End Class

یک متغیر محلی صرفا" تا زمانی وجود خواهد داشت که فعالیت متد جاری ادامه داشته باشد . به عبارت دیگر ، یک member variable ( و یا فیلد ) به عنوان بخشی از کلاس تعریف می شود و برای تمامی متدهای موجود در کلاس قابل دسترس و استفاده است . این نوع متغیرها ، پس از ایجاد شی ، ایجاد خواهند شد و تا زمانی که شی مورد نظر به فعالیت خود ادامه می دهد ، آنها نیز فعال و به حیات خود ادامه خواهند داد .
زمانی که یک member variable تعریف می گردد ، می بایست با صراحت قابلیت دستیابی به آن مشخص گردد . قابلیت دستیابی پذیری مشخص می نماید که چه بخش هائی از کد قادر به خواندن و تغییر این متغیر می باشند . مثلا" اگر شی A شامل یک متغیر خصوصی (Private ) باشد ، شی B قادر به خواندن و تغییر آن نخواهد بود و صرفا" شی A قادر به انجام این کار خواهد بود . به عبارت دیگر ، اگر شی A دارای یک متغیر عمومی ( public ) باشد ، هر شی دیگر موجود در برنامه این آزادی عمل را خواهد داشت که اقدام به خواندن و تغییر اطلاعات ذخیره شده در آن نماید . متغیرهای محلی از هیچگونه کلید واژه قابلیت دستیابی پذیری حمایت نمی نمایند چراکه این نوع متغیرها هرگز نمی توانند برای سایر کد های موجود در خارج از متد جاری در دسترس باشند .
در یک برنامه ساده ASP. NET ، اکثر member variables خصوصی خواهند بود چراکه اکثر کد نوشته شده توسط پیاده کنندگان در یک کلاس صفحه وب قرار می گیرد .
به موازات تلاش جهت ایجاد عناصر نرم افزاری با قابلیت استفاده مجدد ، اهمیت قابلیت دستیابی پذیری افزایش خواهد یافت .
جدول 1 انواع سطوح دستیابی را نشان می دهد .

کلید واژه


قابلیت دستیابی پذیری
Public

امکان دستیابی توسط هر کلاس
Private

صرفا" امکان دستیابی به آن توسط متدهای درون کلاس جاری وجود دارد .
Friend

امکان دستیابی به آن توسط متدهای موجود در هر کلاس موجود در اسمبلی جاری ( فایل کد ترجمه شده ) وجود دارد.
Protected

امکان دستیابی به آن توسط متدهای موجود در کلاس جاری و یا هر کلاسی که از این کلاس مشتق شده باشد ، وجود دارد

جدول 1 انواع سطوح دستیابی

توجه داشته باشید که کلید واژه " قابلیت دستیابی پذیری " ، صرفا" در ارتباط با member variable بکار گرفته نمی شود و از آن در ارتباط با متدها ، خصلت ها و رویدادها نیز استفاده می گردد.

ذخیره Member variables در view state
هر گونه اطلاعاتی که در یک member variable صفحه ASP. NET ذخیره می گردد ، بطور اتوماتیک و پس از اتمام پردازش و ارسال صفحه برای سرویس گیرنده از بین می رود ( به عنوان نمونه متغیر counter در مثال ارائه شده در بخش اول ) .
برای حل مشکلاتی این چنین می توان تمامی member variables را در زمان بروز رویداد Page.PreRender در view state ذخیره و زمانی که رویداد Page.Load ایجاد می گردد آنها را بازیابی کرد . رویداد Load هر مرتبه که صفحه ایجاد می شود ، محقق می گردد . در زمان postback ، در ابتدا رویداد Load محقق شده و در ادامه سایر رویدادهای مرتبط با کنترل ها ایجاد خواهند شد .