إضافة وظائف Razor Pages إلى .NET قياسي

Razor Pages هي ميزة جديدة مقدمة في Core.Net 2.0. صفحة الشفرة هي صفحة تتكون من تخطيط قياسي (عرض) وفئة خلفية. يشبه إلى حد ما نماذج الويب فقط دون دعم رسمي. ميزة مثل هذا الحل واضحة - نتخلص من طبقة غير ضرورية - نموذج الصفحة (نموذج البيانات في شكل ، على سبيل المثال ، الكيان هو نفسه). الواجهة الخلفية للصفحة هي وحدة تحكم ونموذج - OOP classic - لتغليف البيانات وطرق التعامل معها في كائن واحد. في النهاية ، يعد طراز الصفحة مجرد فئة ، ولا يوجد سبب يمنع وحدة التحكم من هذه الفئة.

بمعنى آخر ، Razor Pages هو حل ويب أكثر عقلانية من MVC ، والآن نحن نتعامل مع المفهوم التقليدي والمنطقي لـ "page" وليس مع وحدات التحكم والنماذج المنتشرة في جميع أنحاء المشروع. ولكن نظرًا لأن .NET سيتطور في اتجاه Core.Net ، فمن غير المرجح أن تظهر صفحة Razor في الإطار القياسي ، على الرغم من حقيقة أن معظم المشاريع ستبقى في .NET القياسية. ومع ذلك ، فمن الممكن أن تصور وظيفة صفحات الشفرة على إطار قياسي.

الحل يبدو تافهًا بالفعل - تحتاج إلى إضافة التصميم التالي إلى وحدة التحكم:

protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); } 

طريقة OnActionExecuting هي حدث لدورة الحياة يتم استدعاؤه قبل تنفيذ طريقة التحكم (بمعنى أن معالج الطلب - الإجراء).

يقوم UpdateModel بربط معلمات الطلب مباشرة بخصائص النموذج - في هذه الحالة ، خصائص فئة وحدة التحكم.

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

مثال بسيط:

لدينا نموذج تسجيل الدخول المعتاد مع حقلين.

ليس هناك نقطة في الترميز ؛ سأقدم فقط رمز وحدة التحكم

  public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) { //     checklogin(username,userpass); return View("Index",this); } protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); } } 

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

بالطبع ، يجب أن نضع في اعتبارنا الآن أننا بحاجة إلى العودة كما ActionResult وحدة تحكم كذلك ، وفي القالب تسجيل اسم فئة وحدة تحكم - مثلModel AccountController.

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

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

مثل هذه الصعوبات هي أحد أسباب SPA و جنون javascript الآخر الذي يقوم بسحب المنطق والبيانات إلى المستعرض باستخدام فرامل المتصفح الناتجة (خاصة الأجهزة المحمولة) ، والقفز على الصفحات والرجيج لكل حركة ماوس وزيادة التعقيد وتكلفة العمل - لأن الخلفية هي نفسها اكتب بشكل أو بآخر ، حزم حزم البيانات المرسلة عبر ajax ، بالإضافة إلى callbac hell ، ومضاعفات التصحيح وما إلى ذلك ، وكل هذا دون فائدة عملية لزوار الموقع الذين لا يهتمون بكيفية ايسنا الصفحة.

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

 protected override void OnActionExecuted (ActionExecutedContext Context) { //  } 

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

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

آمل أن تكون هذه "الاختراقات في الحياة" ، على الرغم من أنها تبدو تافهة ، مفيدة للمبتدئين حتى يتجسسوا على الإنترنت للحصول على حلول غير مريحة ومرهقة ويقررون عدم وجود حلول أخرى.