در بخش اول، به ضرورت های حرکت به سمت
ASP.NET اشاره و با ساختار و معما ری اوليه آن نيز آشنا شديم . در
بخش دوم به بررسی تغييرات اساسی ايجاد شده در ASP.NET نسبت به ASP
کلاسيک ، اشاره شد.
بخش سوم : تغييرات عمده در ASP.NET
يکی
از اهداف اوليه و مهم ASP.NET سازگاری کامل آن با ASP کلاسيک است .
دستيابی به هدف فوق بصورت کامل و در مرحله عمل غير ممکن بنظر می آيد .
زمانيکه اين محصول ارائه گرديد ، صرفا" يک تفاوت اساسی مربوط به يکی از
اشياء مهم ( شی Request) ، در آن مشهود بود . در ASP کلاسيک ،
Querystring و مجموعه Form مربوط به شی Request ، برداری از نوع رشته را
برمی گردانند . اما در ASP.NET آنها يک مجموعه شامل نام / مقدار را برمی
گردانند. در اغلب حالات تعييرات اعمال شده بگونه ای بوده که از اشياء
موجود استفاده و امکانات آنها افزايش يا بد .يکی ديگر از موارد قابل تامل
، احتياط در بکارگيری Response.write است . زمانيکه امکان فوق بهمراه تگ
های Server-Side استفاده می گردد، نتايج در بالای صفحه و قبل از تگ HTML
نمايش داده خواهند شد. بمنظور استفاده درست از امکان فوق و نمايش نتايج
دلخواه در مکان مورد نظر، می بايست Response.write از طريق تگ های
Server-side و يا از طريق توابع مورد نظر ، فراخوانده گردد.در اين راستا
می توان از کنترل های سرويس دهنده نظير : Labels و يا PlaceHolder استفاده
کرد . هر يک از اشياء اساسی نظير : Request , Response , Server, Session
و ... دارای تعداد زيادی خصلت و متد جديد شده و در عين حال تعداد ديگر شی
اضافه گرديده است .مثلا" شی Cashe باعث پياده سازی سيستم Cashe برای يک
نرم افزار متکی بر وب می گردد و يا شی ديگر، اطلاعات کاربری که در حال
استفاده از برنامه است ، در خود نگهداری می نمايد . و يا شی Trace که می
توان اطلاعات مربوط به رديابی را بکمک آن در خروجی نمايش داد، نمونه هائی
از اشياء جديد می با شند .
تغييرات ساختاری
در
زمان کوچ از ASP کلاسيک بسمت ASP.NET ، می بايست به تغييرات ساختاری
بوجود آمده نيز دقت گردد. برخلاف صفحات ASP کلاسيک ، در ASP.NET در هر
صفحه صرفا" می توان از يک زبان استفاده کرد . ويژگی فوق يکی از مشهودترين
تغييرات بوجود آمده در ساختار است . بنابراين نمی توان در يک صفحه چندين
زبان را بخدمت گرفت . استثنا" می توان از کنترل های کاربر که توسط يک زبان
نوشته شده اند، در صفحاتی که با زبان ديگر نوشته شده اند ، استفاده کرد .
قانون فوق صرفا" محدود به کدهای نوشته شده ای است که می بايست بر روی
سرويس دهنده اجراء گردنند و استفاده از اسکريپت ها بر روی سرويس گيرنده
نظير آنچيزی است که تاکنون استفاده شده است .
تغيير ديگر:
يک صفحه aspx می تواند دارای صرفا" يک تگ فرم Server-side بوده وپس از
ارسال می بايست به صفحه يکسانی ارسال گردد. البته در اين راستا همچنان می
توان از تگ های Client-Side Form نيز استفاده نمود . در چنين وضعيتی می
توان آنها را برای ساير صفحات موجود ديگر نيز ارسال کرد .جدول زير امکا نا
تی را که می توان بهمراه صفحات aspx استفاده کرد ، نشان می دهد .
مثال
<%@
Directive %> يک صفحه ممکن است دارای دايرکتيو باشد..
دايرکتيوها شامل خصلت های خاصی برای صفحات ، نظير زبان مورد استفاده در
صفحه و يا اسمبلی هائيکه می بايست به صفحه Import گردنند، باشد .
<tag runat=server> از تگ های کنترلی Server-Side نيز می توان استفاده نمود.
<script runat=server> تعاريف کنترل شده وب ، که دارای خصلت Runat server می باشند.
<%# %> عبارات نسبت دهی داده . عبارات فوق امکان بازيابی داده را از منابع داده ئی تعريف شده فراهم می نمايند.
<%-- --%> نظير اسکريپت های توضيحی Client-Side می توان از توضيحات Server-Side استفاده نمود.
<!--
#include --> <%= %> , <% %> می توان از
Server-Side Includes و render Blocks نيز استفاده نمود.
<Script runat="server" language="vb">
dim gVar as String �Page level variable
private sub MySubRoutine()
Label1.Text = gVar
End Sub
</Script >
تغييرات
بوجود آمده در کدهای بلاکی . در ASP کلاسيک محدوديتی از بعد محل و زمان
تعريف موارد نظر وجود نداشت . اما در ASP.NET ضوابطی بدين منظور وضع شده
است . نمی توان توابع را درون تگ های <% %> تعريف نمود .بنابراين می
بايست مطمئن گرديد که تمامی توابع و متغيرهای مورد نظر درون بلاک
<SCRIPT> تعريف شده اند.
تابع زير :
<% MyRenderFunction
Sub MyRenderFunction() %>
<h1> Hi there! </h1>
<%end sub%>
بصورت زير نوشته می گردد :
<% Call MyRenderFunction()%>
<script runat="server" language="vb">
Response.Write(�Hi there!�)
</script>
اغلب برنامه نويسان از توابع خاصی با نام render استفاده می نمايند. ويژگی
مهم در اين زمينه ، امکان ايجاد کدهای Server-Side و تگ های Html بوجود
آمده که با اولويت خاص خود اجراء خواهند گرديد. در مثال روبرو تابعی با
نام MyRenderFunction فراخوانده شده و بلافاصله تعريف شده است همانگونه که
مشاهده می گردد تگ هدر ، بعنوان بخشی از تابع محسوب می گردد.بنابراين
زمانيکه تابع فراخوانده می شود تگ هدر مربوطه Render خواهد شد.اين نوع
نوشتن تابع و فراخوانی در ASP.NET مجاز نبوده و می بايست تمام کدهای
مربوطه درون بلاک <Script> قرار گيرند.
<%@ Page Language="VB" ContentType="text/xml" %>
در
ASP کلاسيک می توان از دايرکتيوهائی بمنظور مشخص نمودن زبان ، وضعيت
Session State ، کد پيج و ... استفاده کرد . در صفحات aspx می توان از
دايرکتيوهای جديدی بمنظور مشخص نمودن خصلت ها برای صفحه ، کنترل ها
اسمبلی ها و ... استفاده نمود. در ASP کلاسيک می بايست دايرکتيوها را در
ابتدای صفحه قرار داد .در ASP.NET می توان دايرکتيوها را در هر محل که
مورد نظر است و به هر تعداد که ضرورت وجود دارد ، استفاده کرد. مثال فوق
دايرکتيوی را نشان می دهد که زبان مورد نظر و نوع محتويات صفحه را مشخص می
نمايد.
تغييرات اضافی در رابطه با پيکربندی
يکی
از نکات قابل تامل ASP کلاسيک ، ذخيره سازی تمامی تنظيمات مربوط به
پيکربندی در ريجستری و يا متابيس های IIS است . ويژگی فوق در زمان
بکارگيری يک برنامه ، باعث بروز مشکلاتی می گردد . در ASP.NET مدل فوق
استفاده نشده و از مجموعه ای فايل های پيکربندی Xml استفاده می گردد.
تنظيمات مربوط به يک برنامه ASP.NET ، در فايل های پيکربندی خاصی از نوع
Xml ذخيره می گردنند. تمامی تنظيمات مربوطه با يک فرمت قابل خواندن در
فايل های Xml ذخيره خواهند شد. دو نوع عمده از فايل های پيکربندی وجود
دارد :
- فايل Machine.Config شامل تنظيمات عمومی و گسترده در رابطه
با ماشين است . بنابراين در صورتيکه قصد اعمال تغييراتی را داشته باشيم که
می بايست بر روی تمامی برنامه های تحت وب تاثير گذار باشد ، می توان از
فايل فوق جهت نيل به خواسته های خود استفاده کرد .
- فايل Web.Config
فايل فوق ، تمامی تنظيمات موجود در فايل Machine.Config را به ارث برده و
در عين حال شامل ساير نتظيمات در رابطه با يک پروژه و درسطح برنامه است .
مثلا" در صورتيکه بخواهيم مدل Session state را برای برنامه جاری مشخص و
يا از برخی داده های خاص برای برنامه استفاده کرد ، می توان از فايل فوق
استفاده نمود. دات نت از طريق اينترفيس های مربوطه امکان دستيابی به اين
نوع فايل ها را بسادگی فراهم می نمايد.
تغييرات بوجود آمده در مديريت Session
در
بخش قبل اشاره گرديد که می توان تنظيمات مربوط به مديريت Session را در
فايل web.Config ذخيره کرد . در ASP.NET چه امکانات جديدتری بمنظور مديريت
Session ايجاد شده است ؟ در ASP کلاسيک صزفا" می توانستيم از شی پيش فرض
Session استفاده نمائيم حتی اگر آن را دوست نداشته باشيم ولی مجبور بوديم
با آن زندگی نمائيم . در ASP.NET از مکانيزمهای جديدی بمنظور مديريت
Session استفاده می گردد. در اين راستا می توان از InProc Session استفاده
، که دارای عملکردی مشابه شی Session در ASP کلاسيک است . با اينکه امکان
فوق گزينه مظلوبی بنظر می آيد ولی همچنان مسئله Load-Balancing را برطرف
نمی نمايد . در ASP کلاسيک همواره دارای مسائلی از بابت حصول اطمينان از
بابت اتصال يک کاربر به سرويس دهندگان يکسانی بمنظور پشتيبانی از داده های
مربوط به Session هستيم . در ASP.NET برای برطرف نمودن مسائلی اينچنين از
StateServer استفاده می گردد. در اين حالت داده مربوط به Session کاربر
مورد نظر در يک State Service ذخيره و قابل اجراء بر روی هر ماشين است .
بنابراين می توان گفت که داده های Session متمرکز شده است . در صورتيکه
StateServer با مشکل (Crashe) مواجه گردد تکليف چيست ؟ در اين حالت تمامی
داده های Session از بين خواهند رفت . بمنظور حل مشکلاتی از اين نوع ،
استفاده از SQLServer Session توصيه می گردد. در اين حالت داده های مربوط
به Session در SQL Server ذخيره و بصورت اتوماتيک برای شما مديريت خواهند
شد. در صورتيکه علاقه مند به استفاده از Session State نباشيد ، می توان
آن را غير فعال نمود. در اين راستا می توان حتی مکانيزمهای تدوين شده توسط
خود را نيز با آن جايگزين نمود. در صورتيکه قصد تغيير و پيکربندی session
State را داشته باشيد ، می توان نقطه نظرات خود را در بخش
<SessionState> مربوط به فايل Web.Config نرم افزار مورد نظر ،
اعمال کرد. در رابطه با بکارگيری و ذخيره اشياء در Session state موارد
متعددی وجود دارد که می بايست مورد توجه قرار گيرد. مثلا" می توان عناصر
COM را صرفا" زمانی در اشياء Session state ذخيره نمود که از InProc
استفاده شده است . ( عناصر فوق قابليت سريال سازی خود را ندارند) . در اين
زمينه نيز می توان عناصر مديريت يافته را در هر نوع مدلی از Session State
ذخيره نمود مشروط به اينکه آنها اينترفيس ISerializable را پياده سازی
نموده باشند.
تغييرات بوجود آمده از بعد امنيتی
يکی
ديگر از تغييرات اساسی در ASP.NET نسبت به ASP کلاسيک مقوله امنيت است .
از آنجائيکه ASP.NET مستقل از IIS است آن بخش از مسائل مرتبط با امنيت ،
مشابه ASP کلاسيک است . ASP.NET يک مدل جديد و انعطاف پذير در رابطه با
امنيت ارائه نموده که بر اساس تنظيمات تعريف شده در بخش های امنيتی
(Security) فايل های پيکربندی مشخص شده است . در اين راستا امکانات و
گزينه های متعددی بمنظور تشخيص هويت ( اعتبار سنجی ) در رابطه با برنامه
تحت وب مبتنی بر دات نت وجود دارد. مثلا" می توان از روش های اعتبار
سنجی حمايت شده توسط IIS استفاده و يا می توان تصميم به استفاده از کدهای
جديد بمنظور اعتبار سنجی گرفت . عموما" از چهار مدل اعتبار سنجی استفاده
می گردد.اعتبار سنجی فوق بعد از اعتبار سنجی IIS صورت می پذيرد .
-
Windows Authentication . اعتبارسنجی ويندوز ، بعنوان پيش فرض در نظر
گرفته خواهد شد. روش فوق زمانيکه از اعتبارستجی های IIS نظير :
Digest,Certificates ، استفاده می گردد ، توصيه شده است .
- Form Authentication اعتبارسنجی مبتنی بر فرم ها را بعنوان اعتبار سنجی پيش فرض برای برنامه در نظر خواهد گرفت .
- Passport Authentication. اعتبار سنجی پاسپورت را بعنوان اعتبار سنجی پيش فرض برای برنامه در نظر خواهد گرفت .
-
None صرفا" کاربران گمنام (Anonymouse) قادر به استفاده از برنامه خواهند
بود. در اين راستا ممکن است عمليات اعتبارسنجی توسط برنامه ها اعمال
گردد.پس از اعتبار سنجی کاربر، می بايست به کاربران مجوزهای لازم جهت
دستيابی از برنامه تحت وب داده شود. مجوزهای مربوطه امکان کنترل دستيابی
به منابع را فراهم خواهند نمود. در اين راستا از دو امکان File
Authorization و URL Authorization می توان استفاده بعمل آورد . مجوز فايل
، بصورت اتوماتيک اعمال خواهد شد. در صورتيکه کاربر متقاضی ، دارای حق
دستيابی به يک فايل و يا منبع خاص را نداشته باشد، دستيابی به صورت خودکار
انکار خواهد گرديد. مجوز مبتنی بر URL امکان اعمال محدوديت به برنامه و يا
آدرس های URL خاصی را فراهم می نمايد.با استفاده از ويژگی فوق می توان
مجوز استفاده و يا عدم استفاده از يک برنامه به ازای کاربران را تامين نمود
کلیه حقوق تحت مجوز