امکان ارسال ديدگاه شما در اين باره، در قالب ارسال نظر در انتهاي همين صفحه قرار دارد. صاحبان وب سايت ها و فعالان اينترنتي مي توانند با ايجاد صفحه شخصي از امکان ارسال محتوا: مقالات, لينک, آگهي و...برخوردار شوند. امکانات و خدمات ما را مقايسه کنيد!

در بخش اول  ،  به ضرورت های حرکت به سمت ASP.NET  اشاره  و  با  ساختار و معما ری اوليه آن  نيز آشنا شديم . در بخش دوم  به بررسی  تغييرات اساسی  ايجاد شده در ASP.NET نسبت به ASP کلاسيک ، اشاره می گردد . يکی از اهداف اوليه و مهم 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 نيز استفاده نمود . در چنين وضعيتی می توان آنها را برای ساير صفحات موجود ديگر نيز ارسال کرد . در ASP کلاسيک محدوديتی از بعد محل و زمان تعريف موارد نظر وجود نداشت . اما در ASP.NET ضوابطی بدين منظور وضع شده است . نمی توان توابع را درون تگ های <% %> تعريف نمود .بنابراين می بايست مطمئن گرديد که تمامی توابع و متغيرهای مورد نظر درون بلاک &ltSCRIPT> تعريف شده اند. 
تابع زير :
<% MyRenderFunction
Sub MyRenderFunction() %>
&lth1> Hi there! </h1>
<%end sub%>
بصورت زير نوشته می گردد :
<% Call MyRenderFunction()%>
&ltscript runat="server" language="vb">
Response.Write(�Hi there!�)
</script>  
اغلب برنامه نويسان از توابع خاصی با نام render استفاده می نمايند. ويژگی مهم در اين زمينه ،  امکان ايجاد کدهای Server-Side و تگ های Html بوجود آمده که با اولويت خاص خود اجراء خواهند گرديد. در مثال روبرو  تابعی با نام MyRenderFunction فراخوانده شده و بلافاصله تعريف شده است همانگونه که مشاهده می گردد تگ هدر ، بعنوان بخشی از تابع محسوب می گردد.بنابراين زمانيکه تابع فراخوانده می شود تگ هدر مربوطه Render خواهد شد.اين نوع نوشتن تابع و فراخوانی در ASP.NET مجاز نبوده و می بايست تمام کدهای مربوطه درون بلاک &ltScript> قرار گيرند. <%@ 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 را داشته باشيد ، می توان نقطه نظرات خود را در بخش &ltSessionState> مربوط به فايل 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 خاصی را فراهم می نمايد.با استفاده از ويژگی فوق می توان مجوز استفاده و يا عدم استفاده از يک برنامه به ازای کاربران را تامين نمود

امکان ارسال ديدگاه شما در اين باره، در قالب ارسال نظر در انتهاي همين صفحه قرار دارد. صاحبان وب سايت ها و فعالان اينترنتي مي توانند با ايجاد صفحه شخصي از امکان ارسال محتوا: مقالات, لينک, آگهي و...برخوردار شوند. امکانات و خدمات ما را مقايسه کنيد!