أ‌س‌پ‌.نت ASP.NET، هوإطار تطبيق وب تم تطويره وترويجع عن طريق شركة مايكروسوفت ليتيح للمبرمج بناء مواقع وب، تطبيقات الوب وخدمات وب ديناميكية. نشر أول إصدار له في يناير 2002 بإصدار 1.0 من .NET Framework.

• لغة تصميم مواقع ويب أنتجت من قبل شركة Microsoft في عام 2005 وبذلك فهي تلقى دعماً كبيراً, بالإضافةً إلى أنّها تمتاز بالأمان وسهولة التّعامل إلى حدٍّ كبير, إلاّ أنّها تعاني من معضلة التّكلفة العالية والبطء مقارنة بلغة PHP والتي هي أكثر انتشاراً واستخداماً في تصميم مواقع الويب حالياً كون لغة PHP رخيصة وسريعة ومفتوحة المصدر مما يسمح للمبرمج بتطوير نفسه.
• تستخدم لغة ASP.NET مع إحدى اللّغتين C# وVisual Basic.
• تميّزت ASP.NET عن ASP بخاصيّة فصل الكود عن التّصميم حيث أصبحت الأكواد في ملف بلاحقة *.cs , أما التّصميم في ملف منعزل بإمتداد *.aspx , وذلك أتاح :

- سهولة في التّوزيع والنقل بين المبرمجين .

- سهولة في التّعديل, فتعديل اسم حقل مثلاً يتطلّب التّعديل في ملف واحد فقط .

- سهولة في الـDeploy لعدم وجود ملفات معتمدة على بعضها البعض .

IIS : الـ IIS هوالسّيرفر الخاص ببرمجيات ASP وASP.NET , ووجوده شرط أساسي ليعمل كود الASP.NET سواءً على جهازك أوعلى السّيرفر الذي ستستضيف عليه مسقطك لاحقاً . يتم تنزيل الـIIS مع الـVisual Studio بشكل افتراضي , أما إذا كنت تعمل على المفكرة Notepad مثلاً فلا بدّ من عمل Setup لـ IIS , وذلك عن طريق اتّباع المراحل التّالية : لوحة التحكم --> إضافة وإزالة برامج --> إضافة مكونات ويندوز ومن ضمن هذه الكونات ستجد الـIIS .

يحتوي أي مشروع لASP.NET على المجلّدات التالية :

• App_Browsers : يحتوي على الملّفات التي تقتنص نوع المتصفّح وتتعامل مع كلّ متصفّح بناء على إمكانياته.
• App_Code : يحتوي على ملفات الأكواد والفئات Classes التي تخصُّ صفحات الويب.
• App_Data : يحتوي على ملّفات قواعد البيانات.
• App_GlobalResources : تحتوي على ملّفات المصادر *.resx
• App_Themes : يحتوي على الملّفات التي تعنى بالمظهر والسّتايلات الخاصّة بالمشروع.
• App_WebReferences : في حالة وجود بروكسي Proxy أوأي نوع من الـ Web Service يستخدمها تطبيقك يتم وضعها هنا.
• Bin : يحتوي على الملّفات الجاهزة مثل ملّفات ال *.dll والتي يتمُّ استخدامها في برنامجك .

تاريخ أي أس بي

بعد إصدار النسخة الرابعة (4.0) من خادم الويب الخاص بمايكرسوفت IIS (اختصارا لخدمات معلومات الإنترنت), قامت مايكروسوفت بالبدأ في عمل أبحاث حول إمكانية تطوير نموذج تطبيقات ويب حديث يمكن حتى يحل المشكلات الشائعة التي اشتكى منها مستخدموASP, وخاصة تلك المتعلقة بالفصل بين قابلة استخدام التطبيق (Application) وبين محتوى التطبيق, مما يساعد على كتابة كود "نظيف" Clean ومنظم.وقد تم تكليف شخصين بعينهما لتحديد كيف من الممكن أن سيكون شكل هذا النموذج (Model), الشخص الأول هومارك آندريس, مدير بفريق IIS, والشخص الثاني هوسكوت جوثري, والذي انضم لمايكروسوفت عام 1997 بعد تخرجه من جامعة ديوك Duke. وقد استغرق آندريس وجوثري شهرين كاملين لتطوير التصميم الأولي للنموذج, وقام جوثري بالعمل على النماذج الأولية Prototypes للنموذج وخط كود تلك النماذج في إجازات الكريسماس من عام 1997.وقد تم إطلاق اللقب XSP على النموذج الأولي, وقد أوضح جوثري في لقاءة أجريت معه عام 2007: "الكثير من الأشخاص يسألون حول ما الذي يرمز إليه الحرف X.والحقيقة أنه في ذلك الوقت, لم يعني ذلك الحرف أي شيء.إن لغة الـ XML يبدأ اسمها بحرف X, وكذلك تقنية الـ XSLT. ويبدوحتى جميع شيء رائع Cool كان يبدأ اسمه بحرف الـ X. ولذلك قمنا ببدأ اسم نموذجنا بالحرف X, لكي يظهر الاسم جذابا, هذا جميع ما في الأمر."وقد تم تطوير النموذج الأولي للـ XSP باستخدام لغة البرمجة جافا JAVA, لكن سرعان ما تم اتخاذ قرار ببناء المنصة الجديدة Platform على تقنية جديدة اطلق عليها CLR (وقت التشغيل المشهجر بين اللغات), حيث أنها وفرت بيئة جيدة لكل من: البرمجة غرضية التوجه Object Oriented, إزالة الكود غير المستخدم Garbage Collection, والكثير من الخصائص التي رؤي أنها مطلوبة, ولم يكن "نموذج مايكروسوفت للمكون الغرضي" MS's Component Object Model يدعم تلك الخصائص في ذلك الوقت.وقد وصف جوثري هذا القرار بالـ "مخاطرة الكبيرة", حيث حتى نجاح منصة تطوير تطبيقات الويب الخاصة بهم ستكون معتمدة على نجاح الـ CLR, والذي كان مثله مثل الـ XSB، لا يزال في المراحل الأولى من التطوير, لدرجة حتى فريق الـ XSP كان أول فريقا ي مايكروسوفت يستخدم الـ CLR.

ومع الانتنطق لـ "وقت التشغيل المشهجر بين اللغات" CLR, تم إعادة كتابة الـ XSP باستخدام لغة سي شارب (وقد أطلق عليها في بداية تطويرها الاسم الرمزي "المشروع الرائع Project Cool"، ولكن ذلك أبقي سرا عن الجمهور)، وتم تغير الاسم XSP إلى ASP+، وفي هذه النقطة من العمل تم النظر إلى ASP+ كخليفة شرعي لـ "صفحات الخادم النشطة" ASP, وقد انتوى القائمون على المشروع توفير طريقة بسيطة لمبرمجي ASP لتفهم ASP+ وللانتنطق بعملهم إلى ASP+.

وقد قام مارك آندريس بعرض ASP+ للمرة الأولى في مؤتمر "روابط إيه إس بي" في مدنية فينيكس بولاية أريزونا يوم 2 مايو2000. وتم عمل عروض للجمهور حول أول إصدار من نوع بيتا (خاص بـ ASP+، وباقي مكونات إطار عمل دوت نت) في مؤتمر المطورين المحترفين 2000، يوم 11 يوليوبمدينة أورلاندوبولاية فلوريدا. وأثناء العرض الإفتتاحي الذي قام به بيل جيتس, قامت شركة فوجيتسوبتوضيح إمكانيات ASP+ مستخدما بالاقتران مع لغة الكوبول COBOL, وكذلك تم الإعلان عن المزيد من لغات البرمجة والمدعومة بـ.NET منها Visual Basic.NET وC# بالإضافة إلى لغات بايثون Python وبيرل Perl, والتي قامت شركة ActiveState بضبطها بنوع معين من أنواع التوافقية Interoperability لتعمل في إطار عمل دوت نت.

وبعد حتى تم الاستقرار على الاسم التجاري إطار عمل دوت نت في النصف الثاني من عام 2000، تم تغيير اسم تقنية ASP+ إلى ASP.NET. وفي ظهور له ببرنامج The MSDN Show (برنامج شبكة مطورومايكروسوفت، وهوبرنامج يذاع على شبكة الإنترنت) عام 2000 شرح مارك آندريس: "لقد تم إطلاق مبادرة.NET من أجل عدة أشياء: إنها من أجل تقديم البرمجيات كخدمات Services, إذا الـ.NET مرتبطة بالـ XML (لغة التوصيف الممتدة extended markup language) ومرتبطة بخدمات الويب, وتهدف إلى تعزيز قدرات الإنترنت من جهة: ماذا يمكنه حتى يقدم.. حقا أردنا حتى نجلب اسمها -اسم خدمات الويب- أكثر إلى الأمام مع باقي المكونات التي تشكل سويا إطار.NET".

وبعد أربعة سنوات من التطوير وبعد سلسلة من إصدارات البيتا ظهرت في عامي 2000 و2001، تم إطلاق النسخة النهائية الأولى تحت اسم ASP.NET 1.0 في الخامس من يناير عام 2002 كجزء من الإصدار رقم 1.0 من إطار عمل دوت نت. وتم كتابة العشرات من الخط التي تشرح ASP.NET حتى قبل إطلاقها في السوق للمبرمجين، وقامت مايكروسوفت بعمل نادىية مكثفة للغاية من أجل ASP.NET التي تشكل جزءا مهما من منصة خدمات الويب التي دفعتها مايكروسوفت بكامل ثقلها. وأصبح جوثري مدير وحدة منتج خاص بـ ASP.NET, واستمر التطوير على قدم وساق, وتم إطلاق الإصدار قم 1.1 في يوم 24 أبريل من عام 2003 كجزء من نظام تشغيل "خادم ويندوز 2003" Windows Server 2003. وقد ركز هذا الإصدار على تحسين إمكانيات ASP.NET لدعم تطبيقات الأجهزة الننطقة.

تقنية المعالجة Rendering

يستخدم ASP.NET تقنية معالجة تدعى Visited Composites (مركبات يتم زيارتها).فأثناء عملية ترجمة البرنامج Compilation, يتم يتم ترجمة صفحة الـ.aspx إلى كود مبدأي يقوم ببناء شجرة تحكم (The Composite) تمثل الصفحة الأصلية.ثم تمضى النصوص الحرفية إلى مثيلات Instances مشتقة من Class خاص بالـ Literal Control, بينما يتم تمثيل الـ Server Controls عن طريق Instances من الصنف Class المناسب لتلك الأجزاء.ويتم جمع هذا الكود المبدأي مع الكود الذي يقوم المبرمج بكتابته (وعادة يتم ذلك عبر الجمع بين عدة أصناف Classes جزئية) وينتج عن ذلك صنف حديث Class مخصص للصفحة.وتتحول الصفحة لشكل مزوج يمثل جذر شجرة التحكم Control Tree.

وعند طلب الصفحة Request من الخادم, تتم تلك العملية عبر سلسلة من المراحل.أولا, وخلال خطوات التهيئة Initialization, يتم عمل Instance من صنف الصفحة ثم يتم تطبيق كود التهيئة.وهذا يقوم بإنتاج شجرة التحكم المبدأية, والتي يتم التعامل معها عن طريق الـ Methods (الطرق) الخاصة بالصفحة في المراحل التالية.ولكل عقدة Node في الشجرة تجد Control يتم تمثيله عن طريق Instance من الصنف (Class) الخاص به, ويمكن للكود حتى يقوم بتغيير الشكل البنائي للشجرة كما يستطيع التعامل مع الخاصئص Properties والطرق Methods الخاصة بكل عقدة موجودة.وأخيرا, وفي جميع خطوة معالجة يقوم الزائر باستخدامها لزيارة العقدة داخل الشجرة, ويطلب من عقدة حتى تقوم بمعالجة Rendering نفسها باستخدام طرق Methods الزائر.ينتج عن ذلك كود من نوع HTML يمثل الشكل النهائي للصفحة, فيتم إرساله من الخاد Server إلى العميل Client.

وبعد حتى تمت معالجة الطلب Request, يتم التخلص من صنف الصفحة ومن شجرة التحكم كلها.ودائما ما تسبب هذه المراحل بلبلة لدى جمهور المبرمجين الجدد الذي ستخدمون ASP.NET لأول مرة, حيث أنهم غير معتادون على فقد الـ Instances الخاصة بأصنافهم في جميع مرة يتم عمل طلب/استجابة للصفحة/من الصفحة.

إدارة حالة الصفحة State Management

يتم استضافة تطبيقات ASP.NET من خلال خادم ويب Web Server ويتم الوصول إليها من خلال بروتوكول HTTP الذي يتصف بأنه "عديم الحالة" Stateless.وعلى هذا النحو, إذا كان التطبيق يحتاج استخدام تفاعل "كامل الحالة" Stateful, فيجب على مطور التطبيق حتى يقوم بإدارة الـ State على مسئوليته. ويقدم ASP.NET مجموعة من الوظائف التي تتيح للمطورين إدارة الـ State. ومن الناحية المبدأية, تعامل مايكرسوفت الـ State (حالة الصفحة) على أنها حالة قابلة الاستخدام الرسومية GUI, وقد تحدث مشكلات كبيرة إذا ما احتاج تطبيق ما حتى يبقى على اتصال مع حالة البيانات Data State مثلما هوالحال مع "آلة الحالة المحدودة" Finite State Machine والتي من الممكن تتطلب وجود حالة ما بين الطلبات المتنوعة للصفحة (مما يسمى: التقييم الكسول Lazy Evaluation), أومن الممكن تتطلب فقط وقتا طويلا للتهيئة.

حالة التطبيق Application State

يمكن تعريف حالة التطبيق Application State بأنها مجموعة من المتغيرات Variables الفهم عن طريق المستخدم والتي يتم مشاركتها Shared بين أجزاء تطبيق ASP.NET المتنوعة.ويتم إعداد تلك المتغيرات وتعريفها عند تحميل الصفحة, حيث يتم نداء الحدث ذوالاسم Application_OnStart, ويتم ذلك مع تحميل أول Instance من التطبيق, ويستمر ذلك في العمل حتى الخروج من آخر Instance من التطبيق.ويتم التعامل مع متغيرات حالة التطبيق عن طريق مجموعة Collection يطلق عليها الاسم Applications, والتي تشكل غلافا Wrapper حول متغيرات حالة التطبيق.ويتم تعريف/تحديد متغيرات حالة التطبيق عبر "أسماء" Names.

حالة الجلسة Session State

حالة الجلسة Session State, هي مجموعة من المتغيرات التي يتم تعريفها عبر المستخدم نفسه, ويتم الحفاظ عليها أثناء جلسة المستخدم Session.هذه المتغيرات تكون فريدة Unique وتختلف من جميع جلسة Session إلى أخرى., ويمكن التعامل معها من خلال مجموعة Collection يطلق عليها اسم Session.ويمكن ضبط متغيرات الدورة/ الجلسة لكي يتم التخلص منها بعد مرور وقت معين من توقف نشاط المستخدم Visitor مع الجلسة.وفي نهاية عمل العميل Client, يمكن تحديد جلسة المستخدم إما عن طريق Cookie(ملفات يتم تحميلها من الخادم إلى العميل وتظل على جهاز العميل لوقت معين يقوم المطور بتحديده) أوعن طريق تكويد رقم تعريف الجلسة ID في عنوان الصفحة URL.

ويدعم ASP.NET ثلاثة أنماط من أجل استماراية متغيرات الجلسة Session Variables:

النمط الأول

داخل العملية In Process

يتم الحفاظ على متغيرات الحالة عن طريق عملية ASP.NET نفسها.هذه هي أسرع طريقة, ولكن على الرغم من ذلك, يتم التخلص من متغيرات الجلسة إذا ما توقفت عملية ASP.NET أوأعيد تكرارها من جديد.ولأن غالبا ما يتم إعادة تشغيل التطبيق من وقت إلى آخر, فإن هذا النمط لا يوصى به للتطبيقات ذات الإحتياجات الحرجة/ الهامة Critical, بلا لا يوصى استخدامه في أي نوع من أنواع التطبيقات.

النمط الثانية

ASPState

في هذا الوضع, يقوم ASP.NET بتشغيل خدمة ويندوز منفصلة Windows Service لكي تحافظ على متغيرات الحالة State Variables.ولأن إدارة الحالة تتم خارج عملية ASP.NET ولأنه يجب حتى يتم استخدام.NET Remoting عبر محرك ASP.NET للوصول إلى البيانات, فإن هذا النمط له تأثير سلبي للغاية على أداء التطبيق Performance بالمقارنة مع النمط السابق من نوع In Process, وعلى الرغم من هذا, فإن هذا النمط يسمح لتطبيقات ASP.NET بتوزيع الحمل Load بشكل متوازن على عدة خوادم (من أجل حل معضلة الـ Performance).ومع ذلك, فلأن خدمة إدارة الحالة تتم بمعزل عن ASP.NET, فيمكن لمتغيرات الجلسة حتى يتم الحفاظ عليها حتى ولوتم إغلاق عمليات ASP.NET.
وتظهر نفس المشكلة برغم ذلك- يعمل خادم الجلسة من خلال Instance واحدة, وإذا فشلت, فإنها نقطة فشل واحدة تخص الجلسة Session.هذه الخدمة لا يمكن تحميلها بشكل متوازن على أكثر من خادم, وكذلك فهي تفرض قيودا على "الأنواع" Types والتي يمكن تحميلها داخل متغيرات الجلسة.

النمط الثالث

وضع SqlServer

في هذا النمط/الوضع, يتم تخزين متغيرات الجلسة في خادم خاص بقواعد البيانات, ويمكن الوصول للمتغيرات من خلال لغة SQL. وفي هذا النمط يمكن الحفاظ على متغيرات الجلسة وحتى إذا تم الغلاق عمليات ASP.NET.والميزة الرئيسية لهذا الوضع أنه يمكن للتطبيق توزيع الحمل على عنقود من الخوادم Cluster ويمكن مشاركة الجلسات Sessions بين الخوادم.وهوالأسلوب الأبطأ لإدارة حالة الجلسات في ASP.NET.

حالة العرض View State

تشير حالة العرض View State إلى آلية لإدارة الحالة على مستوى الصفحة, والتي يتم استخدامها من قبل صفحات HTML المنبعثة من تطبيقات ASP.NET من أجل الحفاظ على حالة أجزاء Controls نموذج الويب Web Forms وكذل الحاجايات Widgets التي من الممكن يحتويها النموذج.ويتم تكويد وإرسال حالة الأجزاء Controls إلى الخادم في جميع مرة يتم تفعيل الجزء Submission, وتخزن بيانات الحالة في حقل خفي يطلق عليه اسم _VIEWSTATE.وفي جانب الخادم, يمكن للتطبيق تغير حالة العرض, إذا ما قامت النتائج -بعد المعالجة- بتحديث حالة أي جزء Control.وعند الخادم, يتم تكويد حالات الأجزاء المتنوعة, وتكون جاهزة للاستخدام في صفحات ASP.NET عبر مجموعة Collection يطلق عليها ViewState.

وحقيقة, فإن الاستخدام الرئيسي لهذه التقنية هوالحفاظ على معلومات النماذج Forms عبر النداءات المتنوعة للصفحة Postbacks.لذلك, فعندما يملأ المستخدم نموذج ما ولكن يقوم بإدخال قيمة خاطئة Value, فإن النموذج يتم تعبأته ذاتيا حين ارساله مرة أخرى للمستخدم ليقوم بتعديل الخطأ.وآليا يتم استخدام الـ View State, وآليا يتم ترتيب تستسل البيانات الخاصة بكل جزء Control بغض النظر عما إذا كان سيستخدم مع جميع Postback أم لا.هذا السلوك يمكن (وينبغي) حتى يتم تعديله, وبالعمل, يمكن إغلاق هذه الخاصية Disable مع جميع جزء Control أوصفحة Page داخل التطبيق, أوفي إطار عمل خادم الويب ككل.

ويجب على المطورين الحذر من تخزين المعلومات الهامة/الحساسة داخل حالة العرض الخاص بصفحة أوجزء, لأن سلسلة الحروف String (ذات الـ Base64) والتي يتم تخزين معلومات الـ View State داخلها يمكن حتى يتم تفكيكها de-serialized (فك شفرتها), عن طريق أي من الأدوات المنتشرة على شبكة الإنترنت, أوعن طريق أي برنامج عام يفك شفرة الـ Base64.وبشكل آلي Default, لا يتم تشفير بيانات الـ View State (القيم المخزنة في _VIEWSTATE), ولكن يمكن تشغيل التشفير على نطاق الخادم كله, من أجل الحفاظ على وجود مستوى معين من الأمان.

وسائل أخرى

يمكن إدارة الحالة State Management عن طريق وسائل أخرى يدعما ASP.NET مثل الكوكيز Cookies, التخزين Cashing وتقنية سلسلة الاستعلام Query String.

أداء ASP.NET

يهدف ASP.NET إلى أفضل أداء بحيث يفوق أي تقنية معتمدة على أكواد نصية Scripts (متضمنة الـ ASP الكلاسيكي), وذلك يتم عبر ترجمة الكود الذي سيعمل في جهة الخادم Server Side إلى ملف DLL أوأكثر يتم استضافته/استضافتهم على خادم الويب.وتتم هذه الترجمة بشكل آلي في أول مرة يتم استنادىء الصفحة بها (وذلك يعني أنه ليس على المطور حتى يقوم بعمل أي خطوات لترجمة Compile الصفحات).هذه الخاصية توفر تطويرا سهلا باستخدام لغة برمجة نصية وتوفر أداءا ممتازا مثل الذلك الضي يصاحب الترجمة الثنائية Binary.ومع ذلك, فإن عملية الترجمة قد تسبب تأخير قصير -ولكنه ملحوظ- عندما يقوم مستخدم الويب باستنادىء صفحة - تم تحريرها/تعديلها حديثا- لأول مرة من خادم الويب, لكن ذلك التأخير لا يحدث مجددا إلا في حالة ما تم تحرير/تعديل الصفحة مرة جديدة.

ويتم وضع ملفات ASPX وكذلك ملفات الموارد Resources الأخرى في مجلد تخيلي Virtual على خادم خدمات معلومات الإنترنت IIS (أوعلى أي خادم ويب آخر متوافق مع ASP.NET, أنظر تطبيقات أخرى, أدناه).وعند المرة الأولى التي يتم فيها طلب صفحة, يقوم اطار دوت نت بجمع وترجمة الملف (الملفات) إلى assembly من نوع دوت نت ويقوم بإرسال الرد إلى المستخدم, ويقوم خدمة الطلبات اللاحقة من خلال ملفات الـ DLL.وبشكل آلي فإن ASP.NET يقوم بترجمة المسقط ككل على دفعات (كل دفعة 1000 صفحة) ويحدث ذلك عند أول طلب Request. وإذا وقع حتى تسببت الترجمة في تأخير, يمكن تعديل حجم الدفعات أواستراتيجية الترجمة للتغلب على هذا التأخير.

ويمكن للمطورين حتى يختاروا ترجمة أكوادهم قبل نقلها إلى الخادم, وبذلك يتم إلغاء الحاجة إلى الترجمة عند الطلب الأول -في بيئة التشغيل الحقيقية Production Environment-.وأيضا يلغي ذلك الحاجة لوجود ملفات كود على خادم الويب.

ملحقات خاصة بـ ASP.NET

قامت مايكروسوفت بإصدار بعض الأطر Frameworks لتعمل كإمتدادات لـ ASP.NET ولكي تزيد من فاعليته.وفيما يلي بعض الملحقات:

ASP.NET AJAX

ملحق يحتوي عدة مكونات تعمل جهة العميل وجهة الخادم من أجل كتابة صفحات ASP.NET تؤدي وظائف AJAX (تقنية تعمل على إثراء التفاعل بين المستخدم وقابلة الاستخدام).

ASP.NET MVC Framework

ملحق يمكن المطورين من كتابة صفحات ASP.NET باستخدام هندسة MVC.

مقارنة بين ASP.NET وبين ASP الكلاسيكية

حاولت ASP.NET حتى تبسط للمطورين عملية الانتنطق من تطوير تطبيقات ويندوز لتطوير تطبيقات الويب عبر تقديم إمكانية بناء صفحات مكونة من أجزاء Controls بنفس الطريقة المستخدمة في بناء قابلة استخدام تطبيقات ويندوز.ويقوم جزء الويب Web Control (مثل الزر Button أوالعلامة Label) بوظائف مماثلة للغاية مع مثيله في ويندوز: فيمكن تكويد خصائص الجزء, ويمكن حتى يستجيب لأحداث معينة Events بإجرائات معينة.ومن المعروف حتى الأجزاء Controls قدرة على معالجة (رسم) نفسها: فأجزاء ويندوز قادرة على رسم نفسها على الشاشة, وكذلك أجزاء ويب قادرة على تكوين كود HTML وJavaScript يمثل هذا الجزء في المكان المحدد له على صفحة الويب التي يتم إرسالها للمستخدم, والتي تظهر على شاشة المتصفح Browser الخاص به.

ويشجع ASP.NET المبرمجين على تطوير تطبيقات تستخدم قابلة المستخدم الرسومية GUI ذات النموذج المعتمد على أحداث Event-Driven, وليس كالنموذج المعتاد في بيئات برمجة الويب مثل ASP وPHP. ويحاول الإطار حتى يجمع بين التقينات الموجودة مثل JavaScript وبين العناصر الداخلية مثل ViewState من أجل تقديم حالة مستمرة (بين الطلبات Inter-Request) بدلا من بيئات الويب القديمة التي عابها وجود Stateless في تطبيقاتها.

وهناك اختلافات أخرى تجدها عند المقارنة مع ASP الكلاسيكية, وهي:

• لأن الكود يتم ترجمته, فإن التطبيقات تعمل بشكل أسرع, مع أخطاء أقل -يتم اكتشافها أثناء عملية التصميم وأثناء فترة التطوير-.
• وجود تطور كبير في معالجة الأخطاء أثناء وقت التشغيل Run-Time,عبر تقنية "معالجة الأخطاء" والتي تستخدم كتل Try-Catch.
• لغة تقنية مماثلة لتلك المستخدمة في تطوير تطبيقات ويندوز مثل "أجزاء" Controls و"أحداث" Events.
• وجود عدد كبير من الأجزاء الجاهزة ووجود مخطات جاهزة للأصناف Classes مما يسمح ببناء التطبيقات بشكل سريع, هذا بجانب الأجزاء التي يتم تعريفها عن طريق المستخدم, والتي تتيح بناء أجزاء مشهجرة بين صفحات التطبيق مثل "القوائم" Menus.ويمكن استعمال ووضع هذه الأجزاء على الصفحة بشكل أيسر من ذي قبل, لأن معظم العمل عبر أدوات تحرير بصرية Visually.
• يزيد إطار ASP.NET من فاعلية قدرات وقت التشغيل المشهجر بين اللغات CRM والذي يدعم عدة لغات برمجية, سامحا لأن يتم تكويد الصفحات بلغات مختلفة مثل VB.NET, C#, J#, Delphi.NET, Chrome..الخ.
• القابلية على تخزين صفحة الويب ككل أوأجزاء منها, من أجل تحسين الأداء (السرعة).
• القدرة على استخدام نموذج التطوير عبر "الكود خلف الصفحة", مما يساعد في الفصل بين منطق العمل وبين القابلة الرسومية.
• إذا قام ASP.NET بتسريب ذاكرة الخادم Memory, يقوم وقت تشغيل ASP.NET بتفريغ المكان الذي يستضيف AppDomain والذي يحوي التطبيق المتسبب في المشكلة, ثم يعيد تحميل التطبيق في AppDomain جديد.
• يمكن تخزين حالة الجلسة Session State في ASP.NET من خلال قاعدة بيانات مايكروسوفت SQL أوفي عمليات منفصلة تعمل على نفس الكمبيوتر أوعلى نفس خادم الويب أوحتى على كمبيوتر مختلف.وبهذه الطريقة لا تضيع قيم الجلسة إذا ما تم إعادة تشغيل خادم الويب أوإذا ما تم إعادة تشغيل عملية ASP.NET المنفذة.
• تعرضت إصدارات ASP.NET الأقل من رقم 2.0 لانتقادات بسبب عدم الامتثال للمعايير.فقد كان كود الـ HTML وكود الـ JavaScript المولدان يتم إرسالهما لمتصفح العميل لا يتسمان في كثير من الأحيان بتوافقهما مع معايير W3C/ECMA.بالإضافة إلى ذلك, ففي الكثير من الأحيان تقوم الخاصية المسئولة عن تحديد نوع متصفح العميل بتحديده بشكل خاطئ, -تعمل ذلك بشكل سليم مع المتصفح من نوع "مستكشف الإنترنت من مايكروسوفت"-, مما يسبب في إظهار كود HTML/JavaScript بشكل خاطئ عند العميل, وربما يتسبب ذلك أيضا في عدم ظهور أجزاء من الصفحة بأكملها عند العميل.ومع ذلك, ففي الإصدار رقم 2.0 من ASP.NET تقوم جميع الأجزاء بتوليد كود سليم من نوع HTML 4.0، XHTML 1.0 أوXHTML 1.1, بالاعتماد على ما تم تهيئة المسقط عليه.وبالنسبة للكشف عن التوافق مع المعايير في متصفحات الويب, فهويجعل التصفح أكثر قوة, ويقدم دعما بإمكانيات أكثر لصفحات الطرز المتراصة CSS.
• أجزاء ويب الخادم: وهي الأجزاء التي تم تقديمها عبر ASP.NET لتوفير قابلة استخدام على نماذج الويب.تتميز هذه الأجزاء بأنها مدارة الحالة State, وتعمل تحت نموذج "ما تراه يفترض أن تجده" WYSIWYG "What You See Is What You Get".

انتقادات وجهت لـASP.NET

في خادم IIS 6.0 والإصدارات الأقل, لا يمكن للصفحات المكتوبة بإصدارات مختلفة من إطار ASP في تشارك حالة الجلسة Session State بدون استخدام مخطات Libraries واردة من أطراف ثلاثة. هذه الانتقادات لا ينطبق على تطبيقات ASP.NET ولا على تطبيقات ASP تعمل جنبا إلى جنب على خادم من نوع IIS 7.ومع الخادم IIS 7, يمكن للـ Modules حتى تعمل من خلال خط متكامل يسمح للـ Modules التي تم كتابتها بأي لغة حتى يتم تطبيقها لخدمة أي طلب Request.

تقوم نماذج الويب المكتوبة بـ ASP.NET 2.0 بإنتاج كود توصيف يتوافق مع معايير W3C, لكن الأمر الذي يخضع للمناقشة هوإذا ما كان ذلك يقوم بزيادة إمكانية الوصول Accessibility, والتي تمثل واحدة من فوائد صفحات الـ XHTML الدلالية بجانب دعم العرض باستخدام CSS.الكثير من الأجزاء, مثل جزء الدخول Login وجزء المساعدة Wizard, تستخدم جداول من نوع HTML أثناء التخطي -وبشكل افتراضي-.وقد قامت مايكروسوفت بحل هذه المشكلة عبر اصدار محولات تحكم Adapters تحت اسم ASP.NET 2.0 CSS, وهي مكونات مجانية تقوم بإنتاج كود توصيفي من نوع XHTML+CSS يتسم بالتوافق.

بعض خصائص نماذج الويب الخاصة بـ ASP.NET, مثل إعادة تنظيم الصفحات وتغيير تاريخ المتصفح, تتوافر فقط من متصفح "إنترنت إكسبلورر".

وقد وضعت مايكروسوفت خدمات الويب وبالتالي IIS/ASP.NET كحل رئيسي لخادم التطبيقات.وقد ظهرت أوجه القصور الكبيرة في المفاهيم عندما تم تطبيق تطبيقات أعمال معقدة تستخدم نهج مايكروسوفت Out-of-the-box: فقد ظهر حتى ASP.NET تفتقد إلى إدارة صلبة للحالة, فقد احتاج المبرمجون إلى كتابة كود يقوم بإدارة الحالة بشكل يحددونه بأنفسهم, ويتم تخزينه في عمليات خارجية, لأن عملية تشغيل ASP.NET تقوم بإعادة التشغيل بشكل آلي -وهم يريدون عملية مستقرة لا تعيد التشغيل آليا-.ويمكن توضيح ذلك عبر مثال بسيط: تخيل حتى مسقط من نوع ASP.NET والذي يعتمد على عناصر لخادم يقوم بحفظ الحالة, وأن هذه الحالة تنتج بعد الحصول على ناتج لألجوريثم معقد جدا -وعلى سبيل المثال, ألجوريثم يقوم بحساب مسارات هندسية معقدة على عدة أجزاء من خريطة كبيرة.ومعنى ذلك حتى مسارا واحدا قد يستغرق عدة دورات من وحدة المعالجة المركزية لحساب وجمع طلبات العميل المتلاحقة, ومعنى ذلك حتى "ترى" وحدة المعالجة النتيجة أثناء معالجة أجزاء الخريطة. مثال آخر: عندما يتم وضع الحالة في كائن من نوع COM والذي لا يمكن تمريره بين خوادم الحالة التي تتعامل مع حالات web/session- هناقد يكون النمط الوحيد الممكن هوin-proc, والذي لا يمكن الاعتماد عليه بسبب إمكانية إعادة تشغيل التطبيق مرارا وتكرارا.

الهوامش

المصادر

• MacDonald, Matthew; Szpuszta, Mario (2005). Pro ASP.NET 2.0 in C# 2005 (1st edition ed.). Apress. ISBN .CS1 maint: extra text (link)

قراءات إضافية

• Anne Boehm: Murachs ASP.NET 3.5 Web Programming with VB 2008, July 21, 2008, Mike Murach and Associates, ISBN 978-1-890774-47-9
• Stephen Walther: ASP.NET 3.5 Unleashed, December 28, 2007, Sams Publishing, ISBN 0-672-33011-3 ISBN 0-672-33011-3
• Stephen Walther: Data Access in the ASP.NET 2.0 Framework (Video Training), September 26, 2007, Sams Publishing, ISBN 0-672-32952-2

وصلات خارجية

• أ‌س‌پ‌.نت at the Open Directory Project
• Microsoft's Official ASP.NET 3.5 website
• ASP.NET on MSDN
• Some of new features in ASP.Net أربعة and vs 2010 IDE