از ASP کلاسيک تا ASP.NET

پياده سا زی نرم افزار تحت وب دارای سا بقه ای چندين سا له بوده و تا کنون دستخوش تحولات متعددی گرديده است . تما می تحولات بوجود آمده ، ريشه در سير صعودی نيا زها ومطرح شدن انتظا رات جديد از اينترنت و مهمترين سرويس آن يعنی وب دارد. اگر سال 1996 ميلادی را نقطه عطفی در زمينه طراحی و پيا ده سازی نرم افزارهای تحت وب بدانيم ، قطعا" می بايست به نقش تکنولوژی های متفا وت که امکا ن خلق آثار نرم افزاری بر روی بستر وب را فراهم نموده اند ، مرور مجددی داشت .
تکنولوژی ASP يکی از پيشکسوتا ن در اين زمينه می با شد. با عرضه تکنولوژی فوق و استقبا ل برنامه نويسان بيشماری در سطح دنيا، ASP بسرعت جايگا ه و مکانی رفيع را پيدا نمود. تکنولوژی فوق ، طی ساليان متما دی توانست به خيل عظيم نيازها بدرستی و بخوبی پاسخ دهد. ASP آن روز، که امروزه با نام ASP کلاسيک از آن يا د می گردد ، گرچه کا مل ترين تکنولوژی در زمينه آفرينش آثا ر نرم افزار تحت وب نيست ، ولی قطعا" يکی از بهترين گزينه ها در اين زمينه می با شد. . ماحصل تما می تلاش های انجام گرفته شده طی سا ليان قبل ، انقلابی عظيم در زمينه بکارگيری نرم افزار های تحت وب از زاويه استفاده کننده بود. با توجه به رشد تصاعدی خواسته ها و مطرح شدن نوع خاصی از انتظارات ، نياز به يک تکنولوژی قدرتمند تر بهمراه زير ساخت ها و چارچوپ های مناسب ، طی ساليان اخير بشدت احساس می گرديد. بر همين اساس شرکت ما کروسافت پروژه معروف دات نت را مطرح نمود. يکی از اهداف اساسی و مهم در پروژه فوق ، ارائه يک مدل و ساختا ر جديد برنامه نويسی تحت وب است . مدل فوق ، بستر مناسب برای گفتما ن برنامه ها بر روی بستر وب را ايجاد خواهد کرد ، چيزی که از آن بعنوان انقلابی ديگر در عرصه برنامه نويسی تحت وب نام برده می شود. در اين مقاله قصد پرداختن به شاخص ها ، ويژگی ها و شا ه کليدهای مطرح در دات نت را نداريم . هدف پرداختن به مواردی است که از منظر برنامه نويسان ASP حائز اهميت است . عرضه و معرفی ASP.NET بهمراه برخی ديگر از تکنولوژی ها در دات نت، کا نون توجه برنامه نويسان ASP قرار گرفته است . تمامی برنامه نويسا ن وب که تا کنون بکمک ASP آثا ر خود را خلق می کردند ، با نگا هی عميق و کنجکا وانه بدنبال ASP.NET هستند. برنامه نويسان، در مرحله اول تما يل دارند که با دستا وردها و امکا نات ASP.NET آشنا شده و قادر به استفاده از پتانسيل های ارائه شده در کوتا هترين زمان ممکن و با روشی کاملا" علمی باشند. در مرحله دوم می بايست تکليف ميليون ها صفحاتی را که توسط ASP کلاسيک ايجاد شده و تاکنون نيز به ارائه خدمات و مسئوليت های محوله ادامه می دهند ، روشن گردد.
در اين مقاله سعی خواهد شد که با ارائه يک مدل علمی و عملياتی ، منا سبترين روش ها بمنظور گذر از ASP کلاسيک و رسيدن به ASP.NET ، ارائه و بررسی گردد. با مطالعه مقاله فوق از يکسو با برخی امکانات و ويژگی های ASP.NET آشنا شده و از سوی ديگر نحوه گذر از ASP کلاسيک و پرداختن به ASP.NET نيز تبين خواهد شد.
اهم مطالبی که در اين مقاله به آنها پرداخته خواهد شد بشرح ذيل می باشند:
• ضرورت های حرکت به سمت ASP.NET . در ابتدا به اين پرسش مهم پاسخ داده خواهد شد که چرا می بايست بسمت دانت نت حرکت نمود؟
• معرفی اوليه ASP.NET . در اين بخش به تشريح برخی از ويژگی های مهم دانت نت اشا ره خواهد شد .
• تغييرات کليدی و اساسی بين ASP و ASP.NET. در اين بخش به بررسی برخی از تفاوت های مهم موجود بين دو تکنولوژی فوق اشا ره خواهد شد.
• نحوه حرکت از ASP بسمت ASP.NET . در اين بخش نحوه تبديل برنامه های نوشته شده ASP توسط VBScript تشريح می گردد .
• نحوه حرکت نرم افزارهائی که از عناصر COM استفاده می نمايند. در اين بخش نحوه تبديل و استفاده از عناصر Com بهمراه ASP.NET تشريح خواهد شد.
• نحوه حرکت نرم افزارهائی که از بانک های اطلاعاتی استفاده می نمايند. در اين بخش نحوه تبديل و استفاده از با نک های اطلاعاتی در ASP.NET تشريح خواهد شد.
• نحوه حرکت بصورت عملی . نحوه عملی ترکيب کدهای نوشته شده ASP کلاسيک وASP.NET تشريح خواهد شد.
• پاسخ به برخی سوالات متداول در خصوص سازگاری بين ASP و ASP.NET

ضرورت های حرکت به سمت ASP.NET

بمنظور پا سخ به سوال فوق در ابتدا می بايست مشخص نمود که تکتولوژی فوق چه خدمات و امکاناتی را ارائه می دهد :
▪ افزايش قا بليت های توسعه و اعتماد . .با استفاده از دات نت قابليت اعتما د و توسعه به شدت افزايش خواهد يافت .امروزه استفاده از تکنولوژی فوق در مزارع وب و باغ های وب ضرورت داشته و اين نوع برنامه ها می بايست همه روز و بصورت شبانه روزی خدمات خود را بصورت بهنگا م ارائه نمايند.
▪ افزايش حداقل دو تا سه برابر کارائی . با استفاده از تکنولوژی دات نت و صرفا" با تبديل برنا مه های نوشته شده با ASP به دات نت کارائی برنامه ها به ميزان دو تا سه برابر افزايش خواهد يافت
▪ دارای ماهيتی کاملا" سازگار با مرورگرها . دات نت کاملا" سازگار با انواع مرورگرها بوده و ضرورتی به نوشتن کدهای اختصاصی بمنظور مشاهده در يک مرورگر خاص وجود نخواهد داشت .
▪ دارای کنترل های سرويس دهنده مورد حمايت ويژوال دات نت و امکانات مربوط به پيکربندی . ASP.NET دارای مجموعه ای وسيع از کنترل های سرويس دهنده می باشد که با توجه به حما يت ويژوال دات نت از تکنولوژی فوق ، زمينه بکارگيری آسان آنها فراهم خواهد شد. در ضمن دات نت دارای امکا نا ت گسترده در زمينه پيکربندی اتوما تيک نيز می باشد.
▪ بکارگيری آسان کدها . صفحا ت و عنا صر طراحی شده بکا رگيری صفحات و حتی عناصر را تسهيل خواهد بخشيد . نظير دستور معروف کپی

تغييرات عمده در 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 خاصی را فراهم می نمايد.با استفاده از ويژگی فوق می توان مجوز استفاده و يا عدم استفاده از يک برنامه به ازای کاربران را تامين نمود.