همه چيز در مورد انتقال از asp به asp.net

[TAHA]

بخش یازدهم
يک صفحه ممکن است دارای دايرکتيو باشد.. دايرکتيوها شامل خصلت های خاصی برای صفحات ، نظير زبان مورد استفاده در صفحه و يا اسمبلی هائيکه می بايست به صفحه Import گردنند، باشد .
<%@ Directive %>

از تگ های کنترلی Server-Side نيز می توان استفاده نمود.
<tag runat=server>

تعاريف کنترل شده وب ، که دارای خصلت Runat server می باشند.
<script runat=server>

عبارات نسبت دهی داده . عبارات فوق امکان بازيابی داده را از منابع داده ئی تعريف شده فراهم می نمايند.
<%# %>

نظير اسکريپت های توضيحی Client-Side می توان از توضيحات Server-Side استفاده نمود.
<%-- --%>

می توان از Server-Side Includes و render Blocks نيز استفاده نمود.
<!-- #include --> <%= %> , <% %>

[TAHA]

تغييرات بوجود آمده در کدهای بلاکی . در ASP کلاسيک محدوديتی از بعد محل و زمان تعريف موارد نظر وجود نداشت . اما در ASP.NET ضوابطی بدين منظور وضع شده است . نمی توان توابع را درون تگ های <% %> تعريف نمود .بنابراين می بايست مطمئن گرديد که تمامی توابع و متغيرهای مورد نظر درون بلاک <SCRIPT> تعريف شده اند.
<Script runat="server" language="vb">
dim gVar as String ?Page level variable
private sub MySubRoutine()
Label1.Text = gVar
End Sub
</Script >

[TAHA]

در ASP کلاسيک می توان از دايرکتيوهائی بمنظور مشخص نمودن زبان ، وضعيت Session State ، کد پيج و ... استفاده کرد . در صفحات aspx می توان از دايرکتيوهای جديدی بمنظور مشخص نمودن خصلت ها برای صفحه ، کنترل ها اسمبلی ها و ... استفاده نمود. در ASP کلاسيک می بايست دايرکتيوها را در ابتدای صفحه قرار داد .در ASP.NET می توان دايرکتيوها را در هر محل که مورد نظر است و به هر تعداد که ضرورت وجود دارد ، استفاده کرد. مثال فوق دايرکتيوی را نشان می دهد که زبان مورد نظر و نوع محتويات صفحه را مشخص می نمايد.
کد:
<%@ Page Language="VB" ContentType="text/xml" %>

[TAHA]

بخش چهاردهم
تغييرات اضافی در رابطه با پيکربندی
يکی از نکات قابل تامل ASP کلاسيک ، ذخيره سازی تمامی تنظيمات مربوط به پيکربندی در ريجستری و يا متابيس های IIS است . ويژگی فوق در زمان بکارگيری يک برنامه ، باعث بروز مشکلاتی می گردد . در ASP.NET مدل فوق استفاده نشده و از مجموعه ای فايل های پيکربندی Xml استفاده می گردد. تنظيمات مربوط به يک برنامه ASP.NET ، در فايل های پيکربندی خاصی از نوع Xml ذخيره می گردنند. تمامی تنظيمات مربوطه با يک فرمت قابل خواندن در فايل های Xml ذخيره خواهند شد. دو نوع عمده از فايل های پيکربندی وجود دارد :
- فايل Machine.Config شامل تنظيمات عمومی و گسترده در رابطه با ماشين است . بنابراين در صورتيکه قصد اعمال تغييراتی را داشته باشيم که می بايست بر روی تمامی برنامه های تحت وب تاثير گذار باشد ، می توان از فايل فوق جهت نيل به خواسته های خود استفاده کرد .
- فايل Web.Config فايل فوق ، تمامی تنظيمات موجود در فايل Machine.Config را به ارث برده و در عين حال شامل ساير نتظيمات در رابطه با يک پروژه و درسطح برنامه است . مثلا" در صورتيکه بخواهيم مدل Session state را برای برنامه جاری مشخص و يا از برخی داده های خاص برای برنامه استفاده کرد ، می توان از فايل فوق استفاده نمود. دات نت از طريق اينترفيس های مربوطه امکان دستيابی به اين نوع فايل ها را بسادگی فراهم می نمايد.

[TAHA]

بخش پانزدهم
تغييرات بوجود آمده در مديريت 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 را پياده سازی نموده باشند.

[TAHA]

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

[TAHA]

بخش هفدهم
گذر از VbScript و حرکت بسمت VB.NET
در بخش های قبل ، به برخی از تغييرات اساسی بوجود آمده در ASP.NET نسبت به ASP کلاسيک اشاره گرديد.در ASP کلاسيک برای نوشتن اسکريپت هائی که بر روی سرويس دهنده اجراء می شدند از Vbscript استفاده می گرديد ، در همين راستا تعداد اندکی از برنامه نويسان نيز از Jscript استفاده می کردند. در اين بخش به بررسی برخی از روش های گذر از Vbscript و استفاده از VB.NET اشاره شده و در ادامه تغييرات بوجود آمده بين VB 6.0 و VB.NET بررسی خواهد شد. در دات نت از زبانهای اسکريپت خبری نبوده و بالطبع استفاده از VBscript توصيه نشده است. در دات نت از VB استفاده و کدهای نوشته شده ترجمه خواهند شد. بمنظور گذز از ASP کلاسيک و سوئيچ نمودن بر روی ASP.NET ، در ابتدا می بايست انشعاب صفحات ASPنوشته شده را به aspx تبديل نمود. پس از تبديل انشعاب فايل های ASP کلاسيک ، صفحات جديد با انشعاب aspx توسط ASP.NET پردازش خواهند شد. دومين مرحله تبديل کدهای نوشته شده و موجود Vbscript به VB است . ممکن است ، اين سوال مطرح گردد که تفاوت های اساسی بين VBscript و VB چيست ؟ پاسخ به سوال فوق بسادگی ميسر نمی باشد ، چراکه در اين زمينه تغييرات عمده ای ايجاد شده است . . اولين تغيير اساسی ، پيش فرض قرار داده شدن Option Explicit است . بنابراين می بايست تمامی متغيرهای استفاده شده را با صراحت تعريف کرد. يکی ديگر از تغييرات ، عدم وجود نوع Variant است . در اين راستا می توان از نوع Object استفاده نمود. نوع فوق دارای عملکردی متفاوت نسبت به Variant است . در اين زمينه توصيه می گردد که نوع تمامی متغيرها دقيقا" مشخص شده و ملاحظات مربوط به تبديل نوع ها لحاظ و رعايت گردد. يکی ديگر از تفاوت های اساسی ، مربوط به نحوه فراخوانی توابع و متدها ئی است که پارامترهائی را بعنوان ورودی اخذ می نمايند. در اين راستا می بايست در زمان استفاده از پارامتر از پرانتز استفاده نمود. در صورتيکه متد و يا تابعی فاقد پارامتر باشد ضرورتی به استفاده از پرانتز وجود نخواهد داشت . در VB 6.0 آرگومانهائی که به يک تابع پاس داده می شوند بصورت پيش فرض از نوع مرجع می باشند (By Ref.) در صورتيکه در VB آرگومانهائی پاس داده شده از نوع مقدار (By Value) می باشند. در VB.NET ايندکس بردارها از صفر شروع می گردد.
در VB.NET استفاده از Set و Let مجاز نبوده و بنابراين لازم است که موارد فوق حذف گردد . مثلا" دستور : Set Object1=Object2 به Object1=Object2 تبديل خواهد شد.

[TAHA]

بخش هجدهم
در VB.NET خصلت های پيش فرض وجود نداشته و می بايست با صراحت خصايص مربوط به اشياء را مشخص کرد . مثلا" دستور : Mystring as string=TextBox1 به MyString as string=TextBox.Text تبديل خواهد شد. در عبارت دوم از خصلت .Text استفاده شده است . نوع صحيح به سی و دو بيت و نوع Long به شصت و چهار بيت تبديل شده اند. در VB.NET از روش های ساختيافته تری بمنظور برخورد با خطاهای احتمالی استفاده می گردد. در اين راستا ضمن اينکه می توان کماکن از عبارت OnError استفاده کرد ، ولی مناسب تر است که از "Try-Catch Block" استفاده گردد. در VB.NET می بايست با صراحت نوع داده ها را تبديل نمود وگرنه با خطاء مواجه خواهيم شد. در اين راستا می بايست از توابع Cstr,Ctype بمنظور تبديل يک نوع صحيح به نوع رشته ای برای نوشتن پاسخ رشته ای استفاده نمود.

  
 Response.Write ("Count=" & CStr(MyCount))  
Response.Write("Count=" & CType(MyCount, String))

[TAHA]

بخش نوزدهم
درVBScript ، بمنظور الحاق ( اتصال ) دو رشته ، الزامی جهت استفاده از فضا های خالی بين & و متفيرهای رشته ای وجود ندارد . (x = str1&str2) ولی در VB.NET می بايست حتما" از فضای خالی در اين راستا استفاده گردد. (x = str1 & str2) . گرامر عبارات Property نيز تغيير يافته است . در اين راستا Property Get ، Property Let و Prpoerty Set با يکديگر ترکيب و به يکی تبديل شده اند. GET و SET درون عبارت Property استفاده می گردند.

 Public Property MyCount as Integer 
   Get  
      MyCount = InternalValue 
   End Get 
   Set  
     InternalValue = value 
  End Set 
End Property

[TAHA]

بخش بیستم
برنامه های ASPکلاسيک که از عناصر COM استفاده می نمايند.
تمامی برنامه نويسان ASP ، تاکنون در برنامه های خود از عناصر COM استفاده کرده اند . در مورد اين نوع برنامه ها چه تدابيری انديشيده شده است ؟ اغلب برنامه نويسان از اشياء متعدد COM که با اهداف خاصی طراحی شده و يا خود آنها را طراحی و پياده سازی نموده اند ، استفاده می نمايند. آيا ضرورتی به بازنويسی مجدد کدها وجود خواهد داشت ؟ در دات نت ، عناصر COM وجود نداشته و از يک پل ارتباطی بمنظور ارتباط آنها بايکديگر استفاده می گردد. COM Iterop رسالت فوق را برعهده دارد. در ابتدا لازم است مطالبی در رابطه با COM Interop عنوان شده ودر ادامه به بررسی تغييرات مبتنی بر COM در ASP.NET پرداخته گردد. COM Interop روشی را جهت فراخوانی عناصر از طريق ASP.NET فراهم می آورد. امکان فوق ، می تواند بمنزله يک خبر خوب برای برنامه نويسان ASP تلقی گردد. در اين راستا لازم است که از صفت ASPCOMPAT استفاده گردد. اگر قصد استفاده از عناصر موجود STA و يا VB را در ASP.NET داشته باشيم، می بايست از ASPCOMPAT استفاده گردد. در صورتيکه اشياء COM مورد نظر از اشياء ذاتی ASP استفاده می نمايند ، نيز می بايست از ASPCOMPACT استفاده گردد . ASP بصورت اساسی از MTA thread pool به جای STA استفاده می نمايد. بنابراين صفحاتی که از عناصر STA استفاده می نمايند ممکن است عملکرد مثبت و يا حتی منفی را داشته باشند. وضعيت فوق ارتباط مستقيم با ماهيت و رفتار عناصر COM بستگی خواهد داشت . بخاطر داشته باشيد که استفاده از ASPCOMPACT در زمان استفاده از سرويس های وب مجاز نخواهد بود.