रेज़र पेज की कार्यक्षमता को मानक .NET में जोड़ें

रेजर पेज्स Core.Net 2.0 में पेश किया गया एक नया फीचर है। रेजर पेज मानक लेआउट (देखें) और बैकएंड क्लास से युक्त एक पेज है। एक अर्थ में, यह केवल स्टेटफुल सपोर्ट के बिना वेब फॉर्म से मिलता जुलता है। इस तरह के समाधान का लाभ स्पष्ट है - हम एक अनावश्यक परत से छुटकारा पा रहे हैं - पृष्ठ मॉडल (उदाहरण के लिए, एक डेटा मॉडल, उदाहरण के लिए, एंटिटी स्वयं के द्वारा है)। पेज बैकएंड एक नियंत्रक और एक मॉडल दोनों है - ओओपी क्लासिक - एक वस्तु में उनके साथ काम करने के डेटा और तरीकों को इनकैप्सुलेट करना। अंत में, पेज मॉडल सिर्फ एक वर्ग है, कोई कारण नहीं है कि नियंत्रक यह वर्ग क्यों नहीं हो सकता है।

दूसरे शब्दों में, रेजर पेज एमवीसी की तुलना में अधिक समझदार वेब समाधान है, अब हम "पेज" की पारंपरिक और तार्किक अवधारणा के साथ काम कर रहे हैं, न कि पूरे प्रोजेक्ट में बिखरे नियंत्रकों और मॉडलों के साथ। लेकिन चूंकि .NET Core.Net की दिशा में विकसित होगा, यह संभावना नहीं है कि रेजर पेज मानक ढांचे में दिखाई देगा, इस तथ्य के बावजूद कि आने वाले वर्षों में अधिकांश परियोजनाएं मानक .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); } } 

जैसा कि आप देख सकते हैं, जिस समय घटना शुरू होती है, इनपुट डेटा पहले से ही बाध्य है और उपयोग के लिए तैयार है।

बेशक, हमें यह ध्यान रखना चाहिए कि अब हमें नियंत्रक के रूप में भी एग्जाम के रूप में लौटना होगा। साथ ही टेम्प्लेट में कंट्रोलर क्लास का नाम लिखें - जैसे कि @Model AccountController।

इस समाधान के परिणामस्वरूप, अनुरोधों के बीच पृष्ठ की स्थिति बनाए रखने का कार्य भी सरल हो जाता है। मान लें कि आपके पास एक निश्चित तालिका के साथ एक पृष्ठ है, जो कॉलम और पृष्ठ पर अंकन द्वारा फ़िल्टर किया गया है।

आप फ़िल्टर पर क्लिक करते हैं, मॉडल दृश्य पर लौटता है और सब कुछ ठीक है, लेकिन जब आप छँटाई पर क्लिक करते हैं, तो फ़िल्टर स्वाभाविक रूप से रीसेट हो जाएगा। पेजिनेटर छँटाई और फ़िल्टर दोनों को रीसेट करेगा। WebForms में, पृष्ठ की स्थिति स्वचालित रूप से सहेजी गई थी, MVC में आपको विभिन्न बोझिल फैसले लागू करने होंगे, उदाहरण के लिए, सभी मापदंडों को गोंद करें और उन्हें प्रत्येक अनुरोध के लिए ड्राइव करें, अर्थात, आपको सॉर्ट लिंक पर फ़िल्टर से पहले आए सभी मापदंडों को लटका देना होगा।

ऐसी कठिनाइयाँ एसपीए और अन्य जावास्क्रिप्ट पागलपन के कारणों में से एक हैं, जिसके परिणामस्वरूप ब्राउज़र में तर्क और डेटा को खींचकर ब्राउज़र ब्रेक (विशेष रूप से मोबाइल डिवाइस), प्रत्येक माउस आंदोलन के लिए पेज जंपिंग और मरोड़ते हैं और काम की जटिलता और लागत में वृद्धि होती है क्योंकि बैकएंड सभी समान है एक या दूसरे रूप में लिखें, ajax के माध्यम से भेजे गए डेटा को अनपैक करें, साथ ही कॉलबेक नर्क, डिबगिंग की जटिलताएं और इसी तरह, और यह सब साइट के आगंतुकों के लिए व्यावहारिक लाभ के बिना, जो कैसे परवाह नहीं करते हैं इसाना पेज।

सत्र में पृष्ठ स्थिति को बचाने के लिए सबसे तार्किक समाधान है। चूंकि नियंत्रक गुणों के रूप में हमारे पास सभी आवश्यक पैरामीटर हैं, इसलिए हमें केवल OnActionExecuted पद्धति को ओवरराइड करना होगा, जिसे अनुरोध को संसाधित करने के बाद कहा जाता है, और आवश्यक गुणों को सत्र में पैक किया जाता है (सत्र कुंजी को निश्चित रूप से नियंत्रक के नाम को इंगित करना चाहिए)।

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

पैरामीटर को कंट्रोलर कंस्ट्रक्टर में सत्र से पुनर्स्थापित किया जाता है या अपडेटमॉडल (यह) कॉल करने से पहले। जब कोई अनुरोध आता है, उदाहरण के लिए, छंटाई, नए पैरामीटर बदल जाएंगे और बाकी अछूता रहेगा और दृश्य उसी रूप में प्रदर्शित किया जाएगा जैसा कि इसे भेजा गया था।

इस तरह के समाधान में एक और सुविधा है - उदाहरण के लिए, उपयोगकर्ता ने तालिका को सॉर्ट किया, और इसके लिए एक और पृष्ठ खोलकर कुछ तत्व को संपादित करने का निर्णय लिया। स्वाभाविक रूप से, वह उस सूची की स्थिति पर वापस लौटना चाहता है जिसे उसने छोड़ा था, और चूंकि पृष्ठ की स्थिति हमारे सत्र में है, इसलिए पृष्ठ स्वचालित रूप से पुनर्स्थापित हो जाएगा। कोई आवश्यकता नहीं है, जैसा कि अक्सर होता है, मापदंडों के पूरे "पकौड़ी" को संपादित पृष्ठ और इसके विपरीत स्थानांतरित करने के लिए। यदि पृष्ठों के बीच स्थिति को सहेजने की आवश्यकता नहीं है, तो पृष्ठ की स्थिति को एक सत्र में नहीं, बल्कि TempData में संग्रहीत किया जा सकता है।

मुझे आशा है कि ये "जीवन हैक" हैं, हालांकि वे तुच्छ दिखते हैं, शुरुआती लोगों के लिए उपयोगी होंगे जब तक कि वे अधिक असुविधाजनक और बोझिल समाधानों के लिए इंटरनेट पर जासूसी न करें और निर्णय लें कि कोई अन्य नहीं है।