ما هو asp.net | مدونة سوفتسيز








ما هو asp.net | مدونة سوفتسيز




ما هو asp.net

إختصارا ل Active Server Pages والتي تعني صفحات الخادم النشط " هو إطار لتطبيقات الويب تم تطويره وتسويقه من خلال شركة مايكروسوفت، من أجل إعطاء القدرة للمبرمجين على بناء مواقع ويب ديناميكية، تطبيقات ويب وخدمات ويب. وتم إصداره في يناير من عام 2002 مع النسخة رقم 1.0 من إطار عمل دوت نت، وتعتبر هذه التقنية خلفاً لتقنية ASP (صفحات الخادم النشطة).

 كما أن ASP.NET تم بناؤها لتستند على تقنية CLR (وقت التشغيل المشترك بين اللغات)، مما يسمح للمبرمجين بكتابة أكوادهم الخاصة بإطار ASP.NET باستخدام أي لغة برمجة يفضلونها على أن تكون مدعومة بإطار عمل دوت نت.



تاريخ ال 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 لدعم تطبيقات الأجهزة النقالة.


الأجزاء المكونة عن طريق المستخدم 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.

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


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




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


تعليقات