إيه إس بي دوت نت

معلومات عامة
نوع	المنصة البرمجية لتطبيقات الإنترنت ; لغة برمجة ; server-side scripting (en) ;
النموذج المصدري	حقوق التأليف والنشر محفوظة
المطورون	مايكروسوفت
موقع الويب	asp.net (الإنجليزية)
الإصدار الأول	يناير 2003
الإصدار الأخير	4.8 ; (أبريل 2019) ;
الرخصة	رخصة أباتشي
امتداد الملف	aspx; ascx; ashx ;

الـ إيه إس بي دوت نت (بالإنجليزية: ASP.NET)‏ «اختصارا ل Active Server Pages والتي تعني صفحات الخادم النشط» هو إطار لتطبيقات الويب تم تطويره وتسويقه من خلال شركة مايكروسوفت، من أجل إعطاء القدرة للمبرمجين على بناء مواقع ويب ديناميكية، تطبيقات ويب وخدمات ويب. وتم إصداره في يناير من عام 2002 مع النسخة رقم 1.0 من إطار عمل دوت نت، وتعتبر هذه التقنية خلفاً لتقنية ASP (صفحات الخادم النشطة). كما أن ASP.NET تم بناؤها لتستند على تقنية CLR (وقت التشغيل المشترك بين اللغات)، مما يسمح للمبرمجين بكتابة أكوادهم الخاصة بإطار ASP.NET باستخدام أي لغة برمجة يفضلونها على أن تكون مدعومة بإطار عمل دوت نت.

تاريخ إيه إس بي دوت نت

بعد إصدار النسخة الرابعة (4.0) من خادم الويب الخاص بمايكرسوفت IIS (اختصارا لخدمات معلومات الإنترنت)، قامت مايكروسوفت بالبدأ في عمل أبحاث حول إمكانية تطوير نموذج تطبيقات ويب جديد يمكن أن يحل المشكلات الشائعة التي اشتكى منها مستخدمو ASP، وخاصة تلك المتعلقة بالفصل بين واجهة استخدام التطبيق (Application) وبين محتوى التطبيق، مما يساعد على كتابة كود «نظيف» Clean ومنظم.وقد تم تكليف شخصين بعينهما لتحديد كيف سيكون شكل هذا النموذج (Model)، الشخص الأول هو مارك آندريس، مدير بفريق IIS، والشخص الثاني هو سكوت جوثري، والذي انضم لمايكروسوفت عام 1997 بعد تخرجه من جامعة ديوك Duke. وقد استغرق آندريس وجوثري شهرين كاملين لتطوير التصميم الأولي للنموذج، وقام جوثري بالعمل على النماذج الأولية (بالإنجليزية: Prototype)‏ للنموذج وكتب كود تلك النماذج في إجازات عطلة رأس السنة من عام 1997.وقد تم إطلاق اللقب XSP على النموذج الأولي، وقد أوضح جوثري في مقابلة أجريت معه عام 2007: «العديد من الأشخاص يسألون حول ما الذي يرمز إليه الحرف X. والحقيقة أنه في ذلك الوقت، لم يعن ذلك الحرف أي شيء. إن لغة الـلغة الترميز القابلة للامتداد يبدأ اسمها بحرف X، وكذلك تقنية الـتحويل لغة الأسلوب الموسع. ويبدو أن كل شيء رائع كان يبدأ اسمه بحرف الـX. ولذلك قمنا ببدأ اسم نموذجنا بالحرف X، لكي يبدو الاسم جذاباً، هذا كل ما في الأمر.» وقد تم تطوير النموذج الأولي للـXSP باستخدام لغة البرمجة جافا، لكن سرعان ما تم اتخاذ قرار ببناء المنصة الجديدة على تقنية جديدة أطلق عليها CLR (وقت التشغيل المشترك بين اللغات)، حيث أنها وفرت بيئة جيدة لكل من: البرمجة غرضية التوجه، جمع القمامة، والعديد من الخصائص التي رؤي أنها مطلوبة، ولم يكن «نموذج مايكروسوفت للمكون الغرضي» MS's Component Object Model يدعم تلك الخصائص في ذلك الوقت. وقد وصف جوثري هذا القرار بالـ «مخاطرة الكبيرة»، حيث أن نجاح منصة تطوير تطبيقات الويب الخاصة بهم ستكون معتمدة على نجاح الـ CLR، والذي كان مثله مثل الـXSP، لا يزال في المراحل الأولى من التطوير، لدرجة أن فريق الـ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 لدعم تطبيقات الأجهزة النقالة.

خصائص إيه إس بي دوت نت

صفحات الويب

تشكل صفحات دوت نت، والمعروفة باسم نماذج الويب (بالإنجليزية: Web Forms)‏، حجر الزاوية بالنسبة لتطوير البرمجيات تحت إطار عمل دوت نت وتأتى نماذج الويب في ملفات تحمل الامتداد.aspx، وإذا تحدثنا بلغة أهل البرمجة فإن تلك الملفات تحتوي على توصيف ستاتيكي من نوع HTML وXHTML، بجانب توصيف أجزاء الويب (بالإنجليزية: Web Controls)‏ وأجزاء معرفة من قبل المستخدم (بالإنجليزية: User Controls)‏ حيث يضع المطورون فيها كل المحتوى الستاتيكي والديناميكي من أجل صفحة الويب Web Page.وبالإضافة إلى ذلك، يمكن وضع كود ديناميكي -يعمل على الخادم Server- في أي صفحة داخل الكود <% -- كود دايناميكي Dynamic Code -- %> والذي يشبه كثيرا نفس طريقة عمل تقنيات تطوير الويب الأخرى مثل PHP, JSP وASP، لكن هذا النوع من الممارسة لا ينصح باستخدامه كثيرا إلا في حالات ربط البيانات Data Binding نظرا لأن ذلك الأمر يتطلب استدعائات كثيرة في كل مرة يتم عمل طلب الصفحة Request.

وكمثال: لاحظ هذا الكود التوضيحي Sample الذي يحتوي على الكود داخل الصفحة inline، بعكس طريقة «الكود خلف الصفحة» Code-Behind الموصى باستخدامها.

<%@ Page Language="C#" %>
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
 
 protected void Page_Load(object sender, EventArgs e)
 
    {
        Label1.Text = DateTime.Now.ToLongTimeString();
    }
 
</script>
 
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Sample page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        The current time is: <asp:Label runat="server" id="Label1" />
    </div>
    </form>
 
</body>
</html>

نموذج «الكود خلف الصفحة» Code-behind

(يقصد بالكود خلف الصفحة أن الكودالمستخدم يوجد في صفحة مستقلة عكس السابق الذي هو مدموج مع كود التصميم html) وقد أوصت مايكروسوفت المطورين أثناء عملهم مع كود البرامج الدايناميكية أن يستخدموا نموذج «الكود خلف الصفحة»، حيث يقوم هذا النموذج بوضع الكود في ملف منفصل أو في Script Tag مصمم خصيصا لهذا الغرض.وتمتلك ملفات «الكود خلف الصفحة» أسماء مثل MyPage.aspx.cs أو mypage.aspx.vb (تعطى نفس الاسم الخاص بصفحة ASPX، مع اختلاف نوع الامتداد Extension والذي يمثل نوع لغة البرمجة المستخدمة- cs تعني C-Sharp, vb تعني Visual Basic).وبشكل تلقائي فإن بيئات التطوير المتكاملة مثل Microsoft Visual Studio تقوم بهذه الممارسة آليا.وعند استخدام هذا النمط من البرمجة، يقوم المبرمج بكتابة كود يستجيب لكل حدث Event مختلف، مثل إعادة تحميل صفحة، أو زر يتم النقر عليه، على عكس الأنماط التقليدية والتي تقوم بتنفيذ كل الكود بشكل إجرائي Procedural.

ويمثل نموذج «الكود خلف الصفحة» المعتمد في ASP.NET إجراء ثوريا، أعفى المطورين من نموذج ASP الكلاسيكي، وشجعهم على فصل كود التطبيقات عن واجهة التطبيقات الرسومية Presentation وعن محتوى الصفحات Content.ومن الناحية النظرية، فإن هذا النظام يتيح لمصمم الويب Designer أن يقوم بالتركيز على شكل وتصميم الصفحة الإبداعي بدون أن يزعج نفسه كثيرا بتوزيع البرمجة/الكود التي ستعمل مع أجزاء الصفحة.وهذا مشابه لفصل المتحكم Controller عن الواجهة View في إطار عمل Model-View-Controller MVC.

مثال



<%@ Page Language="C#" CodeFile="SampleCodeBehind.aspx.cs"
Inherits="Website.SampleCodeBehind"
AutoEventWireup="true" %>

العلامة Tag المذكورة أعلاه يتم وضعها في بداية ملف الـ ASPX.وتحدد خاصية CodeFile الموضوعة في الموجه Directive باسم @Page الملف (cs. أو vb.) بصفته الكود الخلفي، بينما تمثل الخاصية Inherits الـ Class التي تشتق الصفحة منه.في هذا المثال، يتم وضع الموجه @Page في ملف SampleCodeBehind.aspx، بينما يمثل الملف SampleCodeBehind.cs ملف الكود الخلفي Code-behind لهذه الصفحة:

using System;
namespace Website
{
	public partial class SampleCodeBehind : System.Web.UI.Page
	{
		protected void Page_Load(object sender, EventArgs e)
		{
			Response.Write("Hello, world"+"<br />");
                        Response.Write("مرحبا بك في عالم asp.net");

		}
	}
}

في هذه الحالة، يتم استدعاء الطريقة Method المسماة Page_Load () في كل مرة يتم تحميل/طلب الصفحة Request.ويمكن للمبرمج تنفيذ معالجات للأحداث Event Handlers في مراحل مختلفة من عملية تنفيذ الصفحة Execution لتقوم بالعمليات التي يرغب في تنفيذها.

الأجزاء المكونة عن طريق المستخدم User Controls

يدعم ASP.NET تكوين أجزاء برمجية قابلة لإعادة الاستخدام، من خلال إنشاء ما يسمى بـ User Controls - أجزاء مكونة عن طريق المستخدم-.ويتبع الـ User Control نفس التركيب الخاص بنموذج الويب Web form، والاختلاف أن الـ User Control مشتق من الـ Class المسمى System.Web.UI.UserControl.ويتم تخزينه في ملف من النوع ASCX.ومثلما الحال في ملفات ASPX، يحتوي ملف الـ ASCX على كود توصيفي markup من نوع HTML أو XTML، بجانب توصيف يحدد web control ويحدد الـ user controls الأخرى.وبالطبع فإن نموذج الكود-خلف-الصفحة يمكن استخدامه مع الـ User Controls.

ويمكن للمبرمجين أن يضيفوا خصائصهم الخاصة properties، طرقهم/دوالهم methode، ومعالجات الأحداث Event Handlers التي يكتبوها بأنفسهم.وهناك آلية تسمى «تعويم الحدث» Event Bubbling تتيح تمرير حدث تم إثارته Fired داخل User Control إلى الصفحة التي تحتوي هذا الـ User Control.

ويمكن للمبرمجين أيضا بناء أجزاء مخصصة Custom Controls لتطبيقات الـ ASP.NET التي يعملون عليها.ويتم ترجمة هذه الـ Custom Controls إلى ملفات من نوع DLL. وعبر استخدام الموجه Directive ذو الاسم Register يمكن استخدام/استدعاء الـ Control من ملف الـ DLL.

تقنية المعالجة 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.[1]

وحقيقة، فإن الاستخدام الرئيسي لهذه التقنية هو الحفاظ على معلومات النماذج 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.

محرك القالب Template Engine

عند الإصدار الأول لـ ASP.NET، افتقر ASP.NET لمحرك قالب.ولأن إطار دوت نت هو من نوع غرضي-التوجه، ويسمح بالتوريث Inheritance، فإن العديد من المطورين يمكنهم أن يقوموا بتعريف صنف قاعدي جديد Base Class يرث من الصنف System.Web.UI.Page، ويكتبوا طرق Methods يمكنها معالجة كود الـ HTML، ثم يجعلون تلك الصفحات ترث من هذا الصنف الجديد.Web.وفي حين أن هذا الإجراء يسمح بإعادة استخدام عناصر عدة عبر الموقع Site، إلا أن ذلك يضيف تعقيدا كبيرا ويخلط بين الكود وبين التوصيف Markup.وعلاوة على ذلك، فلا يمكن اختبار هذه الطريقة أثناء تصميم التطبيق، وإنما لا بد من تشغيله للقيام بالاختبار.بعض المطورين الآخرين قاموا بتضمين ملفات - وباستخدام حيل أخرى- تجنبهم من أن يضطروا لتنفيذ/تكويد نفس شرائط الانتقال Navigation (مثال: قائمة الروابط Links Menu) ونفس العناصر في كل صفحة.

تم الحل مع الإصدار الثاني من ASP.NET، ففي ASP.NET رقم 2.0 ظهر لأول مرة مفهوم الصفحة الرئيسية Master Page.ويمكن لتطبيق الويب أن يحصل على صفحة رئيسية أو أكثر من صفحة رئيسية، وقد سمح ASP.NET 3.5 -فيما فوق- بمبدأ التضمين Nesting - صفحة داخل صفحة-.وتمتلك الصفحة الرئيسية أجزاء مزودة بضوابط للأماكن Place-Holders، ويطلق عليها ContentPlaceHolders، للدلالة على أماكن المحتوى الديناميكي، بجانب كود الـ HTML والكود المكتوب بلغة JavaScript والمشترك عبر الصفحات المشتقة من الصفحة الرئيسية Child Pages.

الصفحات الأطفال/الصفحات المشتقة Child Page تستخدم هذه الأجزاء من نوع ContentPlaceHolder، والتي لا بد أن تشير إلى الـ Place-Holder الخاص بالصفحة الرئيسية التي تستخدمها الصفحة الفرعية والتي تحمل المحتوى Content.أما باقي أجزاء الصفحة فتحتوي على العناصر المشتركة مع الصفحة الرئيسية، بالضبط مثل عملية دمج المراسلات Mail Merge التي تجدها في تطبيقات معالجة النصوص -مثل MS Word-.ويجب وضع كل التوصيف Markup وجميع أجزاء الخادم Server Controls في صفحة المحتوي داخل جزء من نوع ContentPlaceHolder.

وعندما يتم طلب صفحة محتوى Content Page، يقوم ASP.NET بدمج محتويات صفحة المحتوى مع محتويات الصفحة الرئيسية وإرسال الخرج إلى المستخدم.

ويمكن لصفحة المحتوى أن تستخدم الصفحة الرئيسية بشكل كامل.وذلك يعني أن صفحة المحتوى يمكن أن تقوم بتعديل رأس الصفحة، تقوم بتغيير عنوان الصفحة، تقوم بتعديل مسألة التخزين Cashing..الخ. وإذا أتاحت الصفحة الرئيسية خصائص عامة Properties أو طرق Methods (مثال: لتحديد إشعار حقوق الطبع والنشر)، فيمكن لصفحة المحتوى أن تستخدم ذلك أيضا لتغيير الخصائص أو استدعاء الطرق.

ملفات أخرى

هناك العديد من الملفات ذات الامتدادات المختلفة والتي تتعلق بالإصدارات المختلفة لـ ASP.NET:

الامتداد	الإصدار المطلوب للتشغيل	التوصيف
asax	1.0	ملف Global.asax، يستخدم من أجل ضبط المنطق Logic على مستوى التطبيق.
ascx	1.0	أجزاء ويب من نوع UserControls : أجزاء معرفة عن طريق المستخدم ويتم وضعها في صفحات الويب.
ashx	1.0	معالجات HTTP يتم تعريفها عن طريق المستخدم.
asmx	1.0	صفحات خدمات الويب Web Services.بدءا من الإصدار 2.0, يتم وضع صفحة كود خلفية لملفات asmx ويوضع في مجلد App_Code.
axd	1.0	عندما يتم تمكينها Enable في ملف web.config، تقوم ملفات.axd بإنتاج تقارير ملاحقة Tracing على مستوى التطبيق.أيضا تستخدم من أجل معالج خاص يدعى WebResource.axd مما يمكن مطورو الـ Controls/Components من دمج تلك الملفات مع الصور، السكريبتات، وملفات css..الخ في رزمة واحدة package مكونة من ملف واحد (من نوع assembly)
متصفح	2.0	يتم تخزين إمكانيات المتصفح في ملف من نوع XML، وقد تم تقديم هذا النوع من الملفات في الإصدار رقم 2.0.ويقوم ASP.NET 2 بتخزين العديد من تلك البيانات بشكل آلي، من أجل دعم متصفحات الويب شائعة الاستخدام.ويحدد ذلك أي من تلك المتصفحات له أي من تلك الخصائص، حتى يقوم ASP.NET 2 بعمل تخصيص -بشكل آلي- وضبط الخرج output بما يتلائم مع المتصفح.بعض ملفات مميزة وذات امتداد.browser متوفرة للتحميل مجانا عبر الإنترنت، وعلى سبيل المثال، الـ W3C Validator، بحيث يتم إظهار الصفحات المتوافقة مع معايير معينة، بشكل صحيح.ويقوم هذا الملف باستبدال مقطع BrowserCaps صعب الاستخدام والذي كان موجودا في ملفات machine.config وكذلك يمكن أن يتجاوز محتويات ملف web.config في إصدارات ASP.NET 1.x.
config	1.0	ملف web.config هو الملف الوحيد الذي يمكن أن يوجد في تطبيق ويب محدد ويستخدم الامتداد config بشكل آلي default (هناك حالة تشابه مع ملف machine.config والذي يؤثر في خادم الويب كله وجميع تطبيقات الويب التي يستضيفها).محتويات هذا الملف مخزنة في تنسيق من نوع XML.
cs/vb	1.0	ملفات الكود (حيث يشير الحرفان cs إلى لغة C# -تنطق سي شارب-، ويشير الحرفان vb إلى Visual Basic)وغالبا ما تأخذ ملفات الكود الخلفي Code behind (انظر أعلاه) الامتداد.aspx.cs أو.aspx.vb لأن الـ Cs والـ Vb هما أكثر لغتين انتشارا.ويمكن أن توجد ملفات كود أخرى داخل مجلدات الويب مع امتدادات من نوع cs/vb (وغالبا ما تحتوي أصناف مكتبية متشاركة Common Library Classes).وفي ASP.NET 2 يجب أن يتم وضع هذه الملفات داخل مجلد App_Code حيث يتم ترجمتها بشكل آلي بحيث تصبح متوفرة لكامل التطبيق.
dbml	3.5	رابط LINQ لملف يحتوي على أصناف بيانات SQL.
master	2.0	ملف صفحة رئيسية.والاسم الافتراضي للصفحة الرئيسية هي Master1.master
resx	1.0	ملفات موارد Resources من أجل أغراض التدويل والأقلمة.ويمكن أن تكون ملفات الموارد عاملة على مستوى التطبيق (مثال: تصدر رسائل) ويمكن أن تكون "محلية" بمعنى أن يكون هناك ملف ascx لكل ملف aspx.
sitemap	2.0	ملفات تكوين الموقع.والاسم الافتراضي لها هو web.sitemap
skin	2.0	ملفات مظهر Skin خاصة بتيمة التطبيق Theme.
svc	3.0	ملف خاص بخدمة تأسيس اتصالات ويندوز.
edmx	3.5	نموذج لإطار خاص بكيان من نوع ADO.NET

بنية الدليل Directory Structure

بشكل عام فإن بنية دليل Directory الخاص بـ ASP.NET يمكن تحديده عبر تفضيلات المطور Developer.وبصرف النظر عن عدد معين من الأسماء المحجوزة للدليل، يمكن للموقع أن يتسع لأي عدد من الدلائل.وبالطبع فإن بنية الدليل تؤثر بشكل مباشر على عناوين المواقع URLs.وعلى الرغم من أن ASP.NET يوفر وسائل لاعتراض الطلب Request خلال أي لحظة من عملية المعالجة Processing، فإن المطور لا يضطر إلى توجيه الطلبات خلال تطبيق مركزي أو خلال وحدة تحكم أمامية.

وأسماء الأدلة الخاصة في ASP.NET 2.0 (فيما فوق) هي:

App_Browsers: يحتوي على ملفات تعريف المتصفح المطلوب لتشغيل موقع معين.

App_Code: هذا الدليل مخصص لاحتواء الكود الخام raw code.ويقوم خادم الويب الذي يدعم ASP.NET بترجمة الملفات (والمجلدات الفرعية) الموجودة داخل هذا المجلد وتحويلها إلى assembly بحيث تستطيع أي صفحة داخل الموقع بالوصول إليه.ويستخدم App_Code غالبا مع الكود المخصص للوصول للبيانات، كود النمذجة، وكود العمل Business.ويحتوي أيضا على أي معالجات http خاصة بموقع معين، وأجزاء Modules وتنفيذ خدمات ويب.وكبديل لاستخدام مجلد App_Code يمكن للمطور أن يوفر assmbly منفصل به الكود قبل الترجمة.

App_Data: الدليل الافتراضي لقواعد البيانات، مثل ملفات برنامج Access ذات الامتداد mdb ومثل ملفات خادم SQL ذات الامتداد mdf.وغالبا ما يتصف هذا المجلد بأنه الوحيد ذو إمكانية الكتابة فيه write access داخل التطبيق.

App_LocalResources: يحتوي على ملفات الأقلمة Localization لكل صفحة من صفحات الموقع.وعلى سبيل المثال فإن ملفا ذو الاسم CheckOut.aspx.fr-FR.resx يحتوي موارد الأقلمة الخاصة بالنسخة الفرنسية من صفحة CheckOut.aspx.وعند ضبط اعدادات ثقافة واجهة الاستخدام للغة الفرنسية، فإن ASP.NET يقوم أتوماتيكيا بإيجاد واستخدام ملف الأقلمة المناسب للفرنسية.

App_GlobalResources: يحتوي هذا المجلد ملفات resx ذات موارد الأقلمة المناسبة لكل صفحة في الموقع.وهذا هو المكان حيث يقوم مطور ASP.NET بتخزين رسائل الأقلمة وما إلى ذلك، حيث يتم استخدامها مع أكثر من صفحة ويب واحدة.

App_Themes: يحتوي على التيمات Themes المختلفة للموقع.

App_WebReferences: يحتوى على ملفات الاكتشاف Discovery وملفات WSDL التي تشير غلى خدمات ويب يمكن استعمالها/استهلاكها عن طريق الموقع.

Bin: تتضمن الكود المترجم (في صيغة ملفات من نوع.dll)، من أجل: الأجزاء Controls، المكونات Components وأي كود آخر قد يرجع إليه داخل التطبيق.ويتم الإشارة لأي أصناف Classes مكودة داخل مجلد Bin بشكل أوتوماتيكي في التطبيق الخاص بك.

أداء 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، والذي لا يمكن الاعتماد عليه بسبب إمكانية إعادة تشغيل التطبيق مرارا وتكرارا.

أدوات التطوير

يوجد العديد من رزم البرمجيات التي تتيح تطوير تطبيقات من نوع ASP.NET، ومنها على سبيل المثال:

المنتج:	الشركة المطورة	الترخيص	ملاحظات
ASP.NET Intellisense Generato	BlueVision LLC	مجاني
Microsoft Visual Studio	مايكروسوفت	مجاني/ تجاري
دلفي (لغة برمجة)	امباركاديرو تكنولوجيز	تجاري
Macromedia HomeSite	Adobe Systems	تجاري
إكسبرشن ويب	شركة مايكروسوفت	تجاري
مايكروسوفت شير بوينت ديزاينر	شركة مايكروسوفت	مجاني
مونو ديفيلوب	شركة Novell مع مجتمع مطورو Mono	مجاني ومفتوح المصدر
شارب ديفيلوب	فريق ICSharpCode	مجاني ومفتوح المصدر
Eiffel for ASP.NET	Eiffel Software	مجاني ومفتوح المصدر/ تجاري
أدوبي دريمويفر	Adobe Systems	تجاري	يدعم البرنامج خصائص هامة لـ ASP.NET 2.0, لكنه ينتج كود غير فعال مع ASP.NET 1.x: وأيضا فإن دعم إنتاج الكود ودعم خصائص ASP.NET يكون ضعيفا للغاية إذا تم التطوير بالإصدار رقم 8.0.1 ثم تم تغيير أي شيء بالتطبيق عبر الإصدار MX من ماكروميديا دريم-ويفر: الإصدار رقم 8.0.2 يمكنه عمل تغييرات لتحسين درجة الأمان التي تحمي من الاختراقات التي تتم عبر حقن كود SQL في أجزاء التطبيق بشكل غير قانوني.

أطر أخرى Frameworks

ليس من الضوري استخدام نموذج قياسي لتطوير نماذج الويب أثناء تطوير التطبيقات بـ ASP.NET، ويجدر الإشارة إلى بعض الأطر/النماذج المصممة للتوافق مع منصة دوت نت، مثل:

مكتبة عناصر Base One Foundation BFC، وهي إطار من نوع RAD (التطوير السريع للتطبيقات)، وتستخدم من أجل بناء قواعد بيانات دوت نت ومن أجل الحوسبة الموزعة Distributed للتطبيقات.
إطار DotNetNuke وهو حل مفتوح المصدر، ويحتوي على إطار لتطوير برمجيات الويب بجانب نظام لإدارة المحتوى CMS والذي يسمح لتمديدات متقدمة من خلال توفير لأجزاء Modules، أشكال لواجهة الاستخدام Skins، ومقدمي خدمات Providers.
كاستل مونوريل Castle Monorail، وهو إطار مفتوح المصدر من نوع MVC مع نموذج تنفيذي مشابه لـ Ruby on Rails. ويستخدم هذا الإطار عادة مع منتج Castle ActiveRecord وهو عبارة عن طبقة ORM مبنية على NHibernate.الإطار يستخدم عادة مع القلعة ActiveRecord، طبقة اسندت بنيت على NHibernate.
إطار Spring.NET، وهو جزء من إطار يسمى Spring للتطوير باستخدام لغة البرمجة «جافا» Java.
إطار Skaffold.NET، وهو إطار مبسط لتطوير تطبيقات دوت نت، ويستخدم مع تطبيقات المؤسسات Enterprises.'

إصدارات ASP.NET

التاريخ	الإصدار	ملاحظات	الخصائص الجديدة المرتبطة بـ ASP.NET
16 يناير 2002	1.0	الإصدار الأول ، وتم إطلاقه مع بيئة Visual Studio.NET	تطوير تطبيقات الويب مع دعم البرمجة غرضية التوجه مع جميع خصائصها مثل التوريث Inheritance، تعدد الأشكال Polymorphism، وباقي الخصائص القياسية لنموذج البرمجة غرضية التوجه. لم يعد المطورون مجبرون على استخدام Server.CreateObject(...)، يمكن الآن عمل ربط مبكر، والإطمئنان على سلامة النوع Type. مثلما الحال مع برمجية تطبيقات ويندوز، فمبرمج الويب يستطيع الآن استخدام مكتبات أصناف DLL، واستخدام خصائص أخرى متعلقة بخادم الويب، لبناء تطبيقات قوية وسريعة تستطيع أن تقدم أكثر من مجرد معالجة كود HTML.
24 أبريل 2003	1.1	تم إطلاق الإصدار بصحبة Windows Server 2003 ، صدر كذلك بالاشتراك مع بيئة التطوير الجديدة Visual Studio.NET 2003	أجزاء خاصة بتطوير تطبيقات المحمول Mobile تحقق تلقائي من صحة المدخلات
7 نوفمبر 2005	2.0	الاسم الرمزي لهذا الإصدار هو "ويدبي" Whidbey وتم إطلاق الإصدار بالتزامن مع إطلاق Visual Studio 2005 وبرنامج Visual Web Developer Express ومع خادم البيانات SQL Server 2005	أجزاء Controls جديدة من أجل عرض ومعالجة البيانات مثل (GridView، FormView، DetailsView) تقنية جديدة للإعلان عن الوصول للبيانات مثل أجزاء (SqlDataSource، ObjectDataSource، XmlDataSource) أجزاء للملاحة Navigation الصفحات الرئيسية أجزاء للولوج Login تيمات واجهة الاستخدام Themes أشكال واجهة الاستخدام Skins أجزاء الويب Web Parts خدمات التخصيص ترجمة-قبلية كاملة Pre-Compilation تقنية جديدة للأقلمة دعم للمعالجات التي تعمل بتقنية 64 بت توفير نموذج صنفي Class
21 نوفمبر 2006	3.0		قاعدة اتصالات ويندوز WCF التي تمكن ASP.NET من استضافة خدمات Services. خاصية Windows CardSpace التي تستخدم ASP.NET في أدوار الولوج Roles.
19 نوفمبر 2007	3.5	تم إطلاقه مع بالتزامن مع Visual Studio 2008 ومع خادم Windows Server 2008.	أجزاء جديدة لعرض ومعالجة البيانات (ListView، DataPager) تم ضم ASP.NET AJAX كجزء من إطار ASP.NET. دعم تقنية "النقل الأنبوبي" Pipelining عبر بروتوكول HTTP، وكذلك التغذية النقابية Syndicate Feeds. قامت قاعدة اتصالات ويندوز WCF بدعم كل من RSS, JSON, POX وكذلك الاستئمان الجزئي Partial Trust.
11 أغسطس 2008	3.5 (حزمة الخدمات 1) Service Pack	تم إطلاقه مع حزمة الخدمات 1 لـ Visual Studio 2008.	دمج البيانات الديناميكية لـ ASP.NET. دعم التحكم في تاريخ المتصفح عبر تطبيق ASP.NET AJAX. القدرة على دمج أكثر من ملف من نوع Javascript في ملف واحد من أجل كفاءة أكثر أثناء التحميل. أسماء مكتبية جديدة Namespaces مثل ٍSystem.web.Abstraction وSystem.Web.RoutingWeb.التجريد والنظام.Web.التوجيه

تطبيقات أخرى

يدعم مشروع «مونو» Mono Project اطار ASP.NET 1.1 ومعظم اطار ASP.NET 2.0. ويمكن لـ ASP.NET أن يعمل مع Mono من خلال واحدا من ثلاث خيارات: استضافة التطبيقات على خادم آباتشي Apache عبر جزء Module من نوع mod_mono، الاستضافة من خلال FastCGI، الخيار الأخير هو الـ XSP.

مراجع

"ASP.Net ViewState Overview"، مؤرشف من الأصل في 26 نوفمبر 2009.

MacDonald, Matthew (2005)، Pro ASP.NET 2.0 in C# 2005 (ط. 1st edition)، Apress، ISBN 1-59059-496-7. {{استشهاد بكتاب}}: |edition= has extra text (مساعدة)

انظر أيضًا

وصلات خارجية

آن بوهم: Murachs ASP.NET 3.5، برمجة الويب باستخدام فيجوال بيسيك 2008، 21 يوليو 2008، مايك موراش وشركاه، رقم الإيداع: 978-1-890774-47-9
ستيفن والتر: إطلاق العنان لـ ASP.NET 3.5، 28 ديسمبر، سامز للنشر، رقم الإيداع: 0-672-33011-3
ستيفن والتر: الوصول للبيانات من خلال إطار ASP.NET 2.0 (برنامج تدريب عبر الفيديو)، سامز للنشر، رقم الإيداع 0-672-32952-2
الموقع الرسمي لإيه إس بي دوت نت
صفحة إيه إس بي دوت نت على شبكة مطوري مايكروسوفت

بوابة تقنية المعلومات
بوابة برمجيات
بوابة علم الحاسوب
بوابة مايكروسوفت

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[1] "ASP.Net ViewState Overview"، مؤرشف من الأصل في 26 نوفمبر 2009.