مناقشة متعمقة لتطبيق صفحة ويب ASP.NET

1. مقدمة أساسية عن البرامج النصية للخادم

أولاً، دعنا نراجع طرق التنفيذ الأساسية لصفحات خادم الويب:

1. يرسل العميل طلبًا إلى الخادم عن طريق كتابة العنوان في شريط العناوين بالمتصفح

2. بعد أن يتلقى الخادم الطلب، يرسلها إلى الصفحة المقابلة من جانب الخادم (أي البرنامج النصي) وينشئ البرنامج النصي استجابة من العميل ويرسلها مرة أخرى إلى العميل

3. يتلقى متصفح العميل الاستجابة من الخادم، ويحللها HTML، ويقدم صفحة الويب الرسومية للمستخدم

للتفاعل بين الخادم والعميل، وعادة ما يتم استخدام الطرق الرئيسية التالية:

1. النموذج: هذه هي الطريقة الأكثر أهمية المستخدمة للحصول على مدخلات المستخدم. يرسل إرسال النموذج البيانات إلى الخادم للمعالجة

طريق

إضافة معلمات بعد عنوان URL، يتم إرسال المعلمات إلى الخادم

طريقة خاصة تستخدم عادةً لتأكيد هوية المستخدم

2. مقدمة ASP.Net

لغات نصوص الخوادم التقليدية، مثل ASP وJSP وما إلى ذلك، تكتب نصوص برمجية للخادم بنفس الطريقة تقريبًا في Html، تقوم منصة الخادم بتنفيذ هذه الأكواد لإنشاء صفحات HTML مماثلة. إن دورة حياة Servlet بسيطة جدًا في الواقع، أي أنه يتم تنفيذ جميع التعليمات البرمجية من البداية إلى النهاية، بالطبع، يتم كتابة Servlet يمكن لـ Java كتابة تعليمات برمجية أكثر تعقيدًا، ولكن من الناحية الهيكلية، فهي لا تختلف عن JSP.

أدى ظهور ASP.Net إلى كسر هذا التقليد؛ حيث اعتمدت ASP.Net تقنية CodeBehind وعناصر التحكم من جانب الخادم، وأضافت مفهوم الأحداث من جانب الخادم، وغيرت نموذج كتابة لغة البرمجة النصية، وأصبحت أقرب إلى برمجة Window، مما جعل برمجة الويب أسهل. بديهي، ولكن علينا أن نرى أن ASP.Net نفسه لا يغير النموذج الأساسي لبرمجة الويب، بل يقوم فقط بتغليف بعض التفاصيل وتوفير بعض الوظائف سهلة الاستخدام، مما يجعل كتابة التعليمات البرمجية وصيانتها أسهل إلى حد ما هذا هو الموضوع الرئيسي الذي سنناقشه اليوم، مما يعقد طريقة التنفيذ من جانب الخادم: دورة حياة صفحة ويب ASP.Net.

3. وضع معالجة طلب ASP.Net

نقول أن صفحة الويب الخاصة بـ ASP.Net لا تنفصل عن وضع برمجة الويب، لذلك فهي لا تزال تعمل في وضع الطلب->تلقي الطلب->طلب المعالجة->إرسال استجابة لكل تفاعل مع العميل سيؤدي إلى إطلاق طلب جديد، وبالتالي فإن دورة حياة صفحة الويب تعتمد على طلب واحد.

عندما يتلقى IIS طلبًا من العميل، فسوف يقوم بتسليم الطلب إلى عملية aspnet_wp للمعالجة، وستتحقق هذه العملية من وجود مجال التطبيق المطلوب، وإذا لم يكن موجودًا، فسيقوم بإنشاء واحد، ثم يقوم بإنشاء وقت تشغيل Http (. HttpRuntime ) للتعامل مع الطلبات، فإن وقت التشغيل هذا "يوفر مجموعة من خدمات وقت تشغيل ASP.NET للتطبيق الحالي" (من MSDN).

عندما يقوم HttpRuntime بمعالجة الطلبات، فإنه سيحتفظ بسلسلة من مثيلات التطبيق، أي مثيلات الفئة العامة للتطبيق (global.asax)، وسيتم تخزين هذه المثيلات في تجمع التطبيقات عندما لا تكون هناك طلبات (في الواقع يتم الاحتفاظ بتجمع التطبيقات). بواسطة فئة أخرى، HttpRuntime هو مجرد مكالمة بسيطة). في كل مرة يتم فيها تلقي طلب، سيحصل HttpRuntime على مثيل خامل لمعالجة الطلب، ولن يقوم هذا المثيل بمعالجة الطلبات الأخرى قبل انتهاء الطلب ارجع إلى التجمع، "يتم استخدام المثيل للتعامل مع طلبات متعددة خلال فترة حياته، ولكن يمكنه التعامل مع طلب واحد فقط في كل مرة." (مقتطف من MSDN)

عندما يتعامل مثيل التطبيق مع الطلب، فإنه سيقوم بإنشاء مثيل فئة صفحة الطلب وتنفيذ طريقة ProcessRequest الخاصة بها لمعالجة الطلب. هذه الطريقة هي بداية دورة حياة صفحة الويب.

4. صفحة Aspx وCodeBehind

قبل أن نتعمق في دورة حياة الصفحة، دعونا نناقش أولاً بعض العلاقات بين Aspx وCodeBehind.

<%@ Page language="c#" Codebehind="WebForm.aspx.cs" Inherits="MyNamespace.WebForm" %>

أعتقد أن الأصدقاء الذين استخدموا تقنية CodeBehind يجب أن يكونوا على دراية بهذه الجملة الموجودة في الجزء العلوي من ASPX قم بتحليلها واحدًا تلو الآخر:

لغة الصفحة = "c#" وغني عن القول أن

Codebehind = "WebForm.aspx.cs" تشير هذه الجملة إلى ملف التعليمات البرمجية المنضم

Inherits = "MyNamespace.WebForm" هذه الجملة مهمة جدًا فهي تمثل اسم الفئة الصفحة الموروثة، وهي الفئة الموجودة في ملف التعليمات البرمجية لـ CodeBehind، يجب أن تكون هذه الفئة مشتقة من System.Web.WebControls.Page

مما سبق يمكننا تحليل ذلك في الواقع، الفئة الموجودة في CodeBehind هي أساس الصفحة (ASPX)، في هذه المرحلة، قد يرغب بعض الأصدقاء في السؤال، عند كتابة ASPX، يمكنك تضمين التعليمات البرمجية أو عناصر تحكم الخادم في Html تمامًا وفقًا لطريقة ASP. ؟

هذه المشكلة في الواقع ليست معقدة. يمكن للأصدقاء الذين يستخدمون برمجة ASP.Net الانتقال إلى قرص النظام الخاص بك: WINDOWSMicrosoft.NETFramework<version number>Temporary ASP.NET Files، ووضعه أسفل كافة ملفات ASP المؤقتة. تطبيقات .Net الموجودة على هذا الجهاز، اسم الدليل الفرعي هو اسم التطبيق، ثم النزول إلى مستويين (من أجل ضمان التفرد، يقوم ASP.Net تلقائيًا بإنشاء مستويين من الدلائل الفرعية، والدليل الفرعي هو الاسم). عشوائي) ومن ثم سنجد أن هناك العديد من مكتبات الارتباطات المشابهة لـ: "yfy1gjhc.dll" و"xeunj5u3.dll" ومصادر مثل ملف "komee-bp.0.cs" و"9falckav.0.cs" ، في الواقع، هذا هو نتيجة تجميع ASPX ديناميكيًا بواسطة ASP.Net. عندما نفتح هذه الملفات المصدر، يمكننا العثور على:

الفئة العامة WebForm_aspx: MyNamespace.WebForm، System.Web.SessionState.IRequiresSessionState

وهذا يؤكد بياننا السابق ، ASPX هي فئة فرعية من فئة ربط التعليمات البرمجية، واسمها هو اسم ملف ASPX بالإضافة إلى اللاحقة "_aspx"، من خلال دراسة هذه الرموز، يمكننا أن نجد أنه في الواقع يتم إنشاء جميع عناصر تحكم الخادم المحددة في aspx في هذه الرموز، و ثم عندما يتم إنشاء هذه الرموز ديناميكيًا، تتم كتابة التعليمات البرمجية المضمنة في الأصل في ASPX في الموقع المقابل.

عند زيارة الصفحة لأول مرة، سيستخدم وقت تشغيل HTTP منشئ التعليمات البرمجية لتحليل ملف ASPX وإنشاء التعليمات البرمجية المصدر وتجميعها، ثم ستستدعي الزيارات اللاحقة ملف dll المترجم مباشرةً. وهذا هو سبب وصول ASPX بطيء جدًا.

بعد أن شرحنا هذه المشكلة، دعونا ننظر إلى مشكلة أخرى. عندما نستخدم ربط التعليمات البرمجية، اسحب عنصر التحكم إلى صفحة التصميم، ثم قم بالتبديل إلى عرض التعليمات البرمجية، يمكنك استخدام عنصر التحكم مباشرة في Page_Load نظرًا لأنه يتم إنشاء عنصر التحكم في الفئة الفرعية، فلماذا يمكن استخدامه في الفئة الأصلية؟ وماذا عن استخدامه مباشرة؟

في الواقع، يمكننا أن نجد أنه عندما نستخدم VS.Net لسحب عنصر تحكم إلى الصفحة، تتم دائمًا إضافة عبارة مشابهة لهذا إلى ملف ربط التعليمات البرمجية:

protected System.Web.WebControls.Button Button1;

يمكننا أن نجد أن هذا الحقل هو إعلان أنه محمي، والاسم متوافق مع معرف عنصر التحكم في ASPX. إذا فكرت في الأمر بعناية، فسيتم حل هذه المشكلة. لقد ذكرنا سابقًا أن الكود المصدري لـ ASPX يتم إنشاؤه وتجميعه ديناميكيًا بواسطة المولد، وسيقوم المولد بإنشاء التعليمات البرمجية لإنشاء كل عنصر تحكم في الخادم عند الإنشاء، وسيتحقق مما إذا كانت الفئة الأصلية قد أعلنت عن عنصر التحكم هذا. سيضيف رمزًا مشابهًا لما يلي:

this.DataGrid1 = __ctrl;

هذا __ctrl هو المتغير الذي يقوم بإنشاء عنصر التحكم. في هذا الوقت، يقوم بتعيين مرجع عنصر التحكم للمتغير المقابل في الفئة الأصلية، وهذا هو السبب يجب حماية إعلان الفئة الأصلية (في الواقع يمكن أن يكون عامًا أيضًا)، لأنه من الضروري التأكد من إمكانية استدعاء الفئات الفرعية له.

ثم عند تنفيذ Page_Load، لأنه تم تعيين قيمة لإعلان الفئة الأصلية من خلال رمز التهيئة في الفئة الفرعية، يمكننا استخدام هذا الحقل للوصول إلى عنصر التحكم المقابل. مع العلم بذلك، لن نلتزم بربط التعليمات البرمجية باستخدام عنصر التحكم في المُنشئ في الملف المحدد، يحدث خطأ في استثناء المرجع الفارغ، نظرًا لأنه تم تنفيذ المُنشئ أولاً، فإن تهيئة الفئة الفرعية لم تبدأ بعد، لذا فإن الحقول الموجودة في الفئة الأصلية تحتوي على قيم فارغة عند تهيئة الفصل.

5. دورة حياة الصفحة:

نعود الآن إلى المحتوى المذكور في العنوان الثالث، حيث تحدثنا عن مثيل HttpApplication الذي يتلقى الطلب وينشئ مثيلًا لفئة الصفحة، في الواقع، هذا المثيل هو مثيل لفئة ASPX المترجمة ديناميكيًا. علمنا في العنوان السابق أن ASPX هو في الواقع فئة فرعية من الفئة الموجودة في ربط التعليمات البرمجية، لذا فهو يرث جميع الأساليب المحمية.

الآن دعونا نلقي نظرة على كود فئة CodeBehind التي تم إنشاؤها تلقائيًا بواسطة VS.Net لبدء مناقشتنا لدورة حياة الصفحة:

#region Web Form Designer أنشأ رمز

تجاوز محمي void OnInit(EventArgs e)
{
//
// CODEGEN: هذا الاستدعاء مطلوب من قبل مصمم نماذج ويب ASP.NET.
//
InitializeComponent();
base.OnInit(e);
}

/// <الملخص>
/// يدعم المصمم الطرق المطلوبة - لا تستخدم محرر التعليمات البرمجية للتعديل
/// محتوى هذه الطريقة.
/// </summary>

باطل خاص ()InitializeComponent
{
this.DataGrid1.ItemDataBound += new System.Web.UI.WebControls.DataGridItemEventHandler(this.DataGrid1_ItemDataBound);

this.Load += new System.EventHandler(this.Page_Load);
}

#endregion

هذا هو الكود الذي تم إنشاؤه باستخدام VS.Net. هناك طريقتان فيه، إحداهما هي OnInit والأخرى هي InitializeComponent، والأخيرة تسمى في الواقع بداية تهيئة الصفحة فيInitializeComponent نرى إعلان الحدث لعنصر التحكم وإعلان تحميل الصفحة.

فيما يلي وصف مقتبس من MSDN وجدول تسلسلي لأساليب دورة حياة الصفحة وتشغيل الأحداث:

"في كل مرة يتم فيها طلب صفحة ASP.NET، يقوم الخادم بتحميل صفحة ASP.NET وإلغاء تحميل الصفحة عند اكتمال الطلب. تعد عناصر التحكم في الصفحة والخادم مسؤولة عن تنفيذ الطلب وتقديم HTML للعميل. على الرغم من أن الاتصال بين العميل والخادم عديم الحالة ومتقطع، إلا أنه يجب أن ينظر إليه العميل على أنه عملية مستمرة.

"يتم تنفيذ وهم الاستمرارية هذا بواسطة إطار عمل صفحة ASP.NET والصفحة وعناصر التحكم الخاصة بها. بعد إعادة النشر، يجب أن يبدو سلوك عنصر التحكم وكأنه يبدأ من حيث انتهى طلب الويب الأخير. يمكن لإطارات العمل أن تجعل إدارة حالة التنفيذ نسبيًا سهل، ولكن من أجل تحقيق تأثيرات الاستمرارية، يجب على مطوري التحكم معرفة ترتيب تنفيذ عناصر التحكم. يحتاج مطورو التحكم إلى فهم المعلومات التي يمكن استخدامها والبيانات التي يمكن الاحتفاظ بها بواسطة التحكم في كل مرحلة من دورة حياة التحكم الحالة التي يتم فيها عرض عنصر التحكم. على سبيل المثال، لا يمكن لعنصر التحكم استدعاء الأصل الخاص به حتى تتم تعبئة شجرة التحكم في الصفحة." يوفر الجدول التالي نظرة عامة عالية المستوى على المراحل في دورة حياة عنصر التحكم. انقر فوق الجدول. وصلة."

من هذا الجدول، يمكننا أن نرى بوضوح الأساليب التي تم استدعاؤها ووقت تشغيل الصفحة من التحميل إلى التفريغ. وبعد ذلك، سنقوم بتحليلها بعمق.

بعد النظر إلى الجدول أعلاه، قد يسأل الأصدقاء اليقظون، نظرًا لأن OnInit هو بداية دورة حياة الصفحة، وتحدثنا عن عناصر التحكم التي يتم إنشاؤها في الفئات الفرعية في المحاضرة السابقة، فهنا نستخدم فعليًا حقول أسلوب التهيئة الموضحة في الفئة الأصلية يمكن استخدامها بالفعل، فهل هذا يعني أنه تمت تهيئة الفئة الفرعية قبل ذلك؟

في العنوان الثالث، ذكرنا أن عملية طلب فئة الصفحة هي بداية دورة إعلان الصفحة بالمعنى الحقيقي لهذه الطريقة بواسطة HttpApplication (طريقة الاستدعاء أكثر تعقيدًا، وسوف تتاح لي الفرصة لكتابة مقالة منفصلة لشرحها). صفحة تبدأ معالجة الطلب بهذه الطريقة. من خلال فك ترجمة مكتبة فئة .Net لعرض الكود المصدري، وجدنا الفئة الأساسية لـ System.Web.WebControls.Page: System.Web. WebControls.TemplateControl (هذا هو التحكم في الصفحة والمستخدم، يتم تعريف الطريقة الافتراضية "FrameworkInitialize" في الفئة الأساسية)، ثم يتم استدعاء هذه الطريقة أولاً في ProcessRequest للصفحة، وقد وجدنا آثارًا لهذه الطريقة في كود مصدر ASPX تم إنشاؤها بواسطة المولد. تتم تهيئتها بهذه الطريقة، ويتم إنشاء شجرة التحكم الخاصة بالصفحة في هذا الوقت.

الشيء التالي بسيط، دعنا نحلل تدريجيًا كل عنصر من عناصر دورة حياة الصفحة:

1. التهيئة

تتوافق التهيئة مع حدث Init وطريقة OnInit للصفحة.

إذا كنت تريد إعادة الكتابة، توصي MSDN بالتحميل الزائد لأسلوب OnInti بدلاً من إضافة وكيل لحدث Init. هناك فرق بين الاثنين حيث يمكن للأول التحكم في الترتيب الذي يتم به استدعاء أسلوب OnInit للفئة الأصلية، بينما يمكن لـ لا يمكن استخدام الأخير إلا في الفئة الأصلية، والذي يتم تنفيذه بعد OnInit (يُسمى بالفعل في OnInit).

2. تحميل حالة العرض

هذه طريقة أكثر أهمية، ونحن نعلم أن كل طلب تتم معالجته بالفعل بواسطة مثيل فئة صفحة مختلفة لضمان الحالة بين الطلبين، يستخدم ASP.Net ViewState.

تحصل طريقة LoadViewState على الحالة الأخيرة من ViewState، وتستخدم التكرار لاجتياز الشجرة بأكملها وفقًا لبنية شجرة التحكم على الصفحة لاستعادة الحالة المقابلة لكل عنصر تحكم.

3. معالجة بيانات إعادة النشر

يتم استخدام هذه الطريقة للتحقق مما إذا كانت حالة بيانات التحكم التي أرسلها العميل قد تغيرت. النموذج الأولي للطريقة:

المنطق الظاهري العام LoadPostData(string postDataKey, NameValueCollection postCollection)

postDataKey هي الكلمة الأساسية التي تحدد عنصر التحكم (أي المفتاح في postCollection عبارة عن مجموعة تحتوي على بيانات إعادة النشر يمكننا تجاوز هذه الطريقة ثم التحقق منها). الإرجاع ما إذا كانت البيانات المرسلة قد تغيرت، إذا كان الأمر كذلك، فإنها تُرجع True، "يُرجع LoadPostData صحيحًا إذا تغيرت حالة التحكم بسبب إعادة النشر؛ وإلا فإنه يُرجع خطأ. يتتبع إطار عمل الصفحة جميع عناصر التحكم التي تُرجع صحيحًا ويستدعي RaisePostDataChangedEvent على عناصر التحكم هذه "(مقتطف من MSDN)

تم تعريف هذه الطريقة في System.Web.WebControls.Control، وهي أيضًا الطريقة التي تحتاج إلى التعامل مع جميع عناصر التحكم المخصصة التي تحتاج إلى التعامل مع الأحداث. بالنسبة للصفحة التي نناقشها اليوم، يمكنك تركها. وحيد.

4. يتوافق التحميل

مع حدث التحميل وطريقة OnLoad، وأعتقد أن معظم الأصدقاء سيكونون على دراية بهذا الحدث سيتم تشغيل الحدث، وسيتم أيضًا تنفيذ طريقة Page_Load وأعتقد أن هذه أيضًا هي الخطوة الأولى لفهم ASP.Net.

يستجيب أسلوب Page_Load لحدث التحميل، الذي تم تعريفه في فئة System.Web.WebControl.Control (هذه الفئة هي أصل الصفحة وجميع عناصر تحكم الخادم) ويتم تشغيله في أسلوب OnLoad.

ربما واجه العديد من الأشخاص مثل هذا الشيء، فقد كتبوا فئة PageBase ثم تحققوا من معلومات المستخدم في Page_Load، وبغض النظر عما إذا كان التحقق ناجحًا أم لا، فسيتم دائمًا تنفيذ Page_Load لصفحة الفئة الفرعية أولاً هذه المرة، قد يتم ترك بعض المعلومات كخطر أمني، وقد يقوم المستخدم بتنفيذ أسلوب Page_Load في الفئة الفرعية دون المصادقة عليه.

سبب هذه المشكلة بسيط للغاية، لأنه تتم إضافة أسلوب Page_Load إلى حدث التحميل في OnInit، وتقوم طريقة OnInit للفئة الفرعية أولاً بإضافة حدث التحميل ثم استدعاء base.OnInit، مما يتسبب في إضافة الفئة الفرعية Page_Load أولاً ، ثم يتم تنفيذه أولاً.

من السهل أيضًا حل هذه المشكلة، هناك طريقتان:

1) قم بتحميل طريقة OnLoad في PageBase، ثم قم بمصادقة المستخدم في OnLoad، ثم اتصل بـ base.OnLoad، لأنه يتم تشغيل حدث التحميل في OnLoad، حتى نتمكن من ذلك. تأكد من مصادقة المستخدم قبل إطلاق حدث التحميل.

2) قم أولاً باستدعاء base.OnInit في طريقة OnInit للفئة الفرعية للتأكد من أن الفئة الأصلية تنفذ Page_Load أولاً.

5. أرسل إشعار تغيير إعادة النشر.

تتوافق هذه الطريقة مع معالجة بيانات إعادة النشر في الخطوة 3. إذا تمت معالجة بيانات إعادة النشر ، يتم إرجاع True. سوف يستدعي إطار عمل الصفحة هذه الطريقة لتشغيل أحداث تغيير البيانات، لذلك يجب تشغيل حدث تغيير بيانات إعادة النشر لعنصر التحكم المخصص بهذه الطريقة.

وبالمثل، هذه الطريقة ليست مفيدة جدًا للصفحة. بالطبع، يمكنك أيضًا تحديد أحداث تغيير البيانات على أساس الصفحة. وهذا بالطبع ممكن أيضًا.

6. التعامل مع أحداث إعادة النشر

هذه الطريقة هي المكان الذي يتم فيه تشغيل معظم أحداث التحكم في الخادم. عندما يحتوي الطلب على معلومات حول مشغلات أحداث التحكم (أحداث عناصر تحكم الخادم هي موضوع آخر، سأكتب مقالًا آخر لمناقشته في المستقبل القريب)، التحكم في الصفحة. سيتم استدعاء أسلوب RaisePostBackEvent لعنصر التحكم المقابل لتشغيل الحدث من جانب الخادم.

هنا يأتي سؤال شائع آخر:

غالبًا ما يتساءل مستخدمو الإنترنت عن سبب عدم تغيير البيانات المقدمة بعد التعديل،

وفي معظم الحالات، لا يفهمون عملية تشغيل أحداث الخادم. يمكننا أن نرى أن حدث الخادم يتم تشغيله بعد تحميل الصفحة. وهذا يعني أن الصفحة ستقوم أولاً بتنفيذ Page_Load، ثم تنفيذ حدث النقر على الزر (هذا هو الزر كمثال)، حيث يقوم العديد من الأصدقاء بربط البيانات في Page_Load، ثم معالجة التغييرات في حدث الزر هناك هناك مشكلة في ذلك، يتم تنفيذ Page_Load دائمًا قبل حدث الزر، مما يعني أنه قبل أن يتوفر الوقت لتغيير البيانات، يتم تنفيذ رمز ربط البيانات في Page_Load أولاً، ويتم تعيين البيانات الأصلية لعنصر التحكم، ثم عندما يتم تنفيذ الأمر. تم تنفيذ حدث الزر، وما تم الحصول عليه بالفعل هو البيانات الأصلية، وبالتالي فإن التحديث لن يكون له أي تأثير بالطبع.

من السهل أيضًا تغيير هذه المشكلة. الطريقة الأكثر منطقية هي كتابة رمز ربط البيانات في طريقة، لنفترض أنها BindData:

Private void BindData().
{
// ربط البيانات
}

ثم قم بتعديل PageLoad:

Private void Page_Load(object sender,EventArgs e)
{
إذا (!IsPostBack)
{
BindData(); // ربط البيانات عند الوصول إلى الصفحة لأول مرة}
}

أخيرًا في حدث الزر:

خاص Button1_Click(object sender,EventArgs e )
{
// تحديث dataBindData();// إعادة ربط البيانات
}

7.

سيتم تحويل معالجة الطلب النهائي للعرض المسبق إلى استجابة يتم إرسالها مرة أخرى إلى الخادم. تتمثل مرحلة العرض المسبق في إجراء تغييرات الحالة التي تم إجراؤها قبل العرض النهائي، لأنه قبل تقديم عنصر التحكم، يجب علينا. قم بإنشاء Html بناءً على خصائصه، مثل سمة النمط، وهي المثال الأكثر شيوعًا قبل العرض المسبق، يمكننا تغيير نمط عنصر التحكم عند إجراء العرض المسبق، يمكننا حفظ النمط وعرض HTML معلومات النمط كمرحلة التقديم.

8. حفظ الحالة

هذه المرحلة مخصصة لحالة التحميل لقد ذكرنا عدة مرات أن هناك حالات مختلفة تتم معالجتها بين الطلبات، لذلك نحتاج إلى حفظ حالة هذه الصفحة والتحكم فيها .

9. عند

هذه النقطة، انتهت معالجة طلب الصفحة بشكل أساسي في طريقة العرض، سيتم تكرار شجرة التحكم للصفحة بأكملها، وسيتم استدعاء طريقة العرض بالتسلسل، وسيتم كتابة كود Html المقابل. في تيار الاستجابة النهائية.

10. التخلص

هو في الواقع أسلوب التخلص. في هذه المرحلة، سيتم تحرير الموارد المشغولة، مثل اتصالات قاعدة البيانات.

11.

في نهاية التفريغ، ستنفذ الصفحة طريقة OnUnLoad لتشغيل حدث UnLoad، الذي يعالج المعالجة النهائية قبل تدمير كائن الصفحة. في الواقع، يوفر ASP.Net هذا الحدث فقط لاعتبارات التصميم تم الانتهاء من الموارد في طريقة التخلص لذلك أصبحت هذه الطريقة غير مجدية.

لقد قدمنا ​​بإيجاز دورة حياة الصفحة، وقدمنا ​​شرحًا أقل تعمقًا لمعالجة الأحداث من جانب الخادم. واليوم، أريد بشكل أساسي أن يفهم الجميع دورة تنفيذ الصفحة، وسأكتب المزيد عن الأحداث ومدى الحياة من الضوابط الخادم في المادة المستقبلية للمناقشة.

هذه المحتويات هي بعض من تجاربي في بحث الصفحة عندما كنت أتعلم ASP.Net، ولم تتم مناقشة التفاصيل المحددة بالتفصيل، يرجى الرجوع إلى MSDN لمزيد من المعلومات، لكنني ذكرت بعض الأخطاء والأخطاء الشائعة التي يرتكبها المبتدئون ، وآمل أن تجلب الإلهام للجميع.