मेरी प्राथमिक दिन की नौकरी HTML अनुप्रयोग बना रही है। इसके साथ मेरा मतलब है कि बहुत सारे संपादन योग्य ग्रिड साक्षात्कार, टेक्स्टबॉक्स, ड्रॉपडाउन आदि के साथ सीआरयूडी-प्रकार के अनुप्रयोगों का उपयोग किया जाता है, हम वर्तमान में ASP.NET वेबफॉर्म का उपयोग कर रहे हैं, जो काम पूरा करते हैं, लेकिन प्रदर्शन ज्यादातर निराशाजनक है, और अक्सर आप आप की जरूरत है पाने के लिए हुप्स के माध्यम से कूदने के लिए है। हुप्स जो छत से लटकाए जाते हैं और aflame सेट करते हैं।
इसलिए मैं सोच रहा हूं कि क्या यह सभी यूआई को जावास्क्रिप्ट पक्ष में स्थानांतरित करने के लिए एक अच्छा विचार होगा। पुन: प्रयोज्य नियंत्रणों का एक मजबूत सेट विकसित करें जो विशेष रूप से हमारी आवश्यकताओं के अनुरूप हैं, और केवल सर्वर के साथ डेटा का आदान-प्रदान करते हैं। हां, मुझे "नियंत्रण" (उर्फ "विजेट") प्रतिमान पसंद है, यह इस तरह के अनुप्रयोगों के लिए काफी उपयुक्त है। तो सर्वर की तरफ हम अभी भी हमारे वर्तमान ASPX मार्कअप के लिए एक बुनियादी लेआउट simliar होगा, लेकिन उसके बाद ग्राहक को केवल एक बार भेजा जाएगा, और जावास्क्रिप्ट भाग बाद के सभी यूआई अपडेट का ख्याल रखेगा।
समस्या यह है कि मैंने ऐसा पहले कभी नहीं किया है, और मैंने कभी किसी को ऐसा करते नहीं देखा, इसलिए मुझे नहीं पता कि समस्याएं क्या होंगी। विशेष रूप से, मैं इससे चिंतित हूं:
- अभी भी प्रदर्शन । बेंचमार्किंग से पता चलता है कि वर्तमान में मुख्य देरी क्लाइंट की तरफ है, जब ब्राउज़र AJAX अपडेट के बाद अधिकांश पेज को फिर से प्रस्तुत करने की कोशिश करता है। ASP.NET वेबफॉर्म जनरेट किया गया मार्कअप शब्द "वेब" को एक नया अर्थ देता है, और समृद्ध डेवेक्सप्रेस नियंत्रण उस के ऊपर जावास्क्रिप्ट जटिलता की अपनी परत जोड़ते हैं। लेकिन क्या जावास्क्रिप्ट पक्ष पर सभी आवश्यक परिवर्तनों को पुनर्गणना करना तेजी से होगा और फिर केवल उसी को अपडेट करना होगा जिसे अपडेट करने की आवश्यकता है? ध्यान दें कि मैं उन रूपों के बारे में बात कर रहा हूं जिनमें कई संपादन योग्य ग्रिड साक्षात्कार, बहुत सारे टेक्स्टबॉक्स, कई ड्रॉपडाउन हैं जिनमें से प्रत्येक में आधा-एक-अरब फ़िल्टर करने योग्य आइटम हैं, आदि।
- विकास में आसानी । अब बहुत अधिक जावास्क्रिप्ट होगा, और यह संभवतः पृष्ठ के HTML मार्कअप के साथ मिश्रित होगा। उस या किसी प्रकार के नए दृश्य इंजन का उत्पादन करना होगा। जावास्क्रिप्ट के लिए Intellisense भी C # कोड की तुलना में बहुत खराब है, और जावास्क्रिप्ट की गतिशील प्रकृति के कारण इसे बहुत बेहतर होने की उम्मीद नहीं की जा सकती है। कोडिंग प्रथाएं इसे थोड़ा सुधार सकती हैं, लेकिन बहुत अधिक नहीं। इसके अलावा, हमारे अधिकांश डेवलपर्स मुख्य रूप से सी # डेवलपर्स हैं, इसलिए कुछ सीखने की अवस्था और शुरुआती गलतियां होंगी।
- सुरक्षा । बहुत सारी सुरक्षा जांच दो बार (सर्वर-साइड और यूआई-साइड) करनी होगी, और डेटा-प्रोसेसिंग सर्वर साइड को उनमें से कई को शामिल करना होगा। वर्तमान में, यदि आप टेक्स्ट-बॉक्स को केवल सर्वर साइड पर पढ़ने के लिए सेट करते हैं, तो आप क्लाइंट राउंडट्रिप के माध्यम से इसके मूल्य में बदलाव नहीं कर सकते हैं। यह सुनिश्चित करने के लिए फ्रेमवर्क में पहले से ही पर्याप्त कोड है (व्यूस्टेट एन्क्रिप्शन के माध्यम से)। डेटा-केवल दृष्टिकोण के साथ, यह कठिन हो जाता है, क्योंकि आपको मैन्युअल रूप से सब कुछ जांचना होगा। दूसरी ओर, शायद सुरक्षा छेद को स्पॉट करना आसान होगा, क्योंकि आपके पास चिंता करने के लिए केवल डेटा होगा।
सब के सब, यह हमारी समस्याओं को हल करेगा, या उन्हें बदतर बना देगा? क्या किसी ने कभी यह प्रयास किया है, और परिणाम क्या थे? क्या इस तरह के प्रयास (jQuery और नैतिक समकक्ष एक तरफ) में मदद करने वाले कोई रूपरेखा हैं?
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.आप बिल्कुल वही बता रहे हैं जो ASP.NET है, जो मुझे बताता है कि आप संभवतः इसका सही उपयोग नहीं कर रहे हैं। :) अपने ASP.NET अनुप्रयोगों में यदि आप घटकों को अपडेट पैनल में रखते हैं तो ASP.NET जावास्क्रिप्ट लाइब्रेरी सर्वर साइड पर अतुल्यकालिक पोस्टबैक करेगा और आपके द्वारा निर्दिष्ट घटकों को फिर से प्रस्तुत करेगा।