ايمن سازی اطلاعات ذخيره شده در View State - بخش دوم
چهارشنبه 24 خرداد 1391 7:07 PM
نویسنده : | www.srco.ir | 86.10.09 | 625 بار مشاهده |
در اين بخش به بررسی نحوه نگهداری member variable و اشياء سفارشی در view state خواهيم پرداخت .
اجازه دهيد قبل از تشريح موارد فوق ، در ابتدا اشاره ای به انواع متعيرها داشته باشيم .
پس از ايجاد ساختار اوليه يك كلاس ، می بايست عناصر داده پايه را به آن اضافه نمود .
در كد زير ، سه member variable تعريف شده است كه اطلاعاتی را در ارتباط با product ( شامل نام ، قيمت و URL آن كه به يك فايل image اشاره می نمايد ) در خود نگهداری می نمايند .
يك متغير محلی صرفا" تا زمانی وجود خواهد داشت كه فعاليت متد جاری ادامه داشته باشد . به عبارت ديگر ، يك member variable ( و يا فيلد ) به عنوان بخشی از كلاس تعريف می شود و برای تمامی متدهای موجود در كلاس قابل دسترس و استفاده است . اين نوع متغيرها ، پس از ايجاد شی ، ايجاد خواهند شد و تا زمانی كه شی مورد نظر به فعاليت خود ادامه می دهد ، آنها نيز فعال و به حيات خود ادامه خواهند داد .
زمانی كه يك member variable تعريف می گردد ، می بايست با صراحت قابليت دستيابی به آن مشخص گردد . قابليت دستيابی پذيری مشخص می نمايد كه چه بخش هائی از كد قادر به خواندن و تغيير اين متغير می باشند . مثلا" اگر شی A شامل يك متغير خصوصی (Private ) باشد ، شی B قادر به خواندن و تغيير آن نخواهد بود و صرفا" شی A قادر به انجام اين كار خواهد بود . به عبارت ديگر ، اگر شی A دارای يك متغير عمومی ( public ) باشد ، هر شی ديگر موجود در برنامه اين آزادی عمل را خواهد داشت كه اقدام به خواندن و تغيير اطلاعات ذخيره شده در آن نمايد . متغيرهای محلی از هيچگونه كليد واژه قابليت دستيابی پذيری حمايت نمی نمايند چراكه اين نوع متغيرها هرگز نمی توانند برای ساير كد های موجود در خارج از متد جاری در دسترس باشند .
در يك برنامه ساده ASP. NET ، اكثر member variables خصوصی خواهند بود چراكه اكثر كد نوشته شده توسط پياده كنندگان در يك كلاس صفحه وب قرار می گيرد .
به موازات تلاش جهت ايجاد عناصر نرم افزاری با قابليت استفاده مجدد ، اهميت قابليت دستيابی پذيری افزايش خواهد يافت .
جدول 1 انواع سطوح دستيابی را نشان می دهد .
قابليت دستيابی پذيری
|
كليد واژه
|
امكان دستيابی توسط هر كلاس
|
Public
|
صرفا" امكان دستيابی به آن توسط متدهای درون كلاس جاری وجود دارد .
|
Private
|
امكان دستيابی به آن توسط متدهای موجود در هر كلاس موجود در اسمبلی جاری ( فايل كد ترجمه شده ) وجود دارد.
|
Friend
|
امكان دستيابی به آن توسط متدهای موجود در كلاس جاری و يا هر كلاسی كه از اين كلاس مشتق شده باشد ، وجود دارد
|
Protected
|
توجه داشته باشيد كه كليد واژه " قابليت دستيابی پذيری " ، صرفا" در ارتباط با member variable بكار گرفته نمی شود و از آن در ارتباط با متدها ، خصلت ها و رويدادها نيز استفاده می گردد.
هر گونه اطلاعاتی كه در يك member variable صفحه ASP. NET ذخيره می گردد ، بطور اتوماتيك و پس از اتمام پردازش و ارسال صفحه برای سرويس گيرنده از بين می رود
برای حل مشكلاتی اين چنين می توان تمامی member variables را در زمان بروز رويداد Page.PreRender در view state ذخيره و زمانی كه رويداد Page.Load ايجاد می گردد آنها را بازيابی كرد . رويداد Load هر مرتبه كه صفحه ايجاد می شود ، محقق می گردد . در زمان postback ، در ابتدا رويداد Load محقق شده و در ادامه ساير رويدادهای مرتبط با كنترل ها ايجاد خواهند شد .
در كد زير از روش فوق در ارتباط با متغيری با نام Contents ، استفاده شده است . در اين صفحه يك text box به همراه دو button ارائه شده است . كاربر در خصوص ذخيره و يا بازيابی داده از view state تصميم می گيرد . روتين های مربوط به رويداد كليك هر يك از دكمه های موجود بر روی فرم ، مسئوليت ذخيره و بازيابی داده در متغير Contents را برعهده دارند . در روتين های فوق ضرورتی به ذخيره و بازيابی مقدار متغير contents در view state وجود ندارد چراكه اين مسئوليت به روتين های رويدادهای Load و PreRender واگذار شده است تا در زمان آغاز و اتمام پردازش صفحه ، وظايف اشاره شده ( ذخيره و بازيابی ) را انجام دهند .
شكل 1 ، خروجی برنامه فوف را نشان می دهد .
در زمان استفاده از روش فوق می بايست از ذخيره اطلاعات غيرضروری در view state اجتناب گردد ، چراكه در چنين مواردی ، حجم خروجی صفحه نهائی افزايش می يابد . اين موضوع می تواند كاهش سرعت انتقال صفحه را به دنبال داشته باشد .
در صورت ضرورت استفاده از رويكرد فوق برای ذخيره member variable در view state ، می بايست از آن در موارد كاملا" خاص استفاده شود .
پياده كنندگان می توانند اشياء خود را در view state ذخيره نمايند . برای ذخيره يك آيتم در view state ، می بايست امكان تبديل آن به مجموعه ای از بايت ها وجود داشته باشد تا بتوان آن را در يك فيلد ورودی مخفی ذخيره كرد . به فرآيند فوق serialization می گويند . در صورتی كه اشياء تعريف شده توسط پياده كنندگان قابليت تبديل به مجموعه ای از بايت ها را نداشته باشند ( به صورت پيش فرض اين قابليت وجود ندارد ) ، در زمان استقرار آنها در view state يك پيام خطاء مواجه خواهيم شد.
برای ايجاد قابليت serializable در اشياء تعريف شده ، می بايست خصلت [Serializable] را به تعريف كلاس اضافه كرد .
كد زير نحوه انجام اين كار را نشان می دهد .
با توجه به اين كه در كلاس Customer خصلت serializable تعريف شده است ، امكان ذخيره آن در view state وجود خواهد داشت .
در زمان استفاده از اشياء سفارشی ، پس از بازيابی داده از view state می بايست آنها را تبديل ( cast ) كرد.
پس از بررسی مستندات يك كلاس و با مشاهده خصلت [Serializable] ، امكان ذخيره شی مورد نظر در view state وجود خواهد داشت . در صورتی كه شی مورد نظر فاقد خصلت فوق باشد ، امكان ذخيره آن در view state وجود نخواهد داشت . در چنين مواردی می توان از روش های ديگر state management كه در بخش های بعدی به آنها اشاره خواهيم كرد، استفاده كرد.
يكی از مهمترين محدوديت های view state ، شعاع استفاده از اطلاعات ذخيره شده در آن توسط ساير صفحات وب است . اطلاعات ذخيره شده در view state صرفا" توسط صفحه ای كه آنها را ايجاد كرده است قابل استفاده خواهند بود و ساير صفحات قادر به استفاده از اطلاعات نخواهند بود . به عنوان مثال ، در صورتی كه كاربر به صفحه ای ديگر حركت و يا هدايت شود ، اطلاعات ذخيره شده در view state قابل دستيابی نبوده و عملا" از بين خواهند رفت . برای غلبه بر محدوديت فوق ، از روش های متعدد ديگری می توان استفاده كرد .
کریمی که جهان پاینده دارد تواند حجتی را زنده دارد
دانلود پروژه و کارآموزی و کارافرینی