2012-01-27 6 views
13

कुछ परिप्रेक्ष्य प्राप्त करने के लिए, हम उम्र के लिए एएसपी.नेट वेब फॉर्म का उपयोग कर रहे हैं।क्या है [HTML5 + jQuery] (कोई एएसपी.नेट नहीं) + डब्ल्यूसीएफ एंटरप्राइज़ लेवल वेब एप्लिकेशन के लिए एक वैध समाधान है?

हम वेब फॉर्मों पर एमवीसी के लाभों के बारे में भी जानते हैं, हालांकि एक वैकल्पिक विकल्प को फेंक दिया जा रहा है, जिसमें उन सभी अमूर्त परतों को बाईपास करना है और केवल शुद्ध। HTML पृष्ठ को डब्ल्यूसीएफ सेवा में जाना है।

नहीं .एएसएक्सएक्स, नहीं .cshtml/.vbhtml, केवल शुद्ध। HTML फाइलें सर्वर साइड लॉजिक और प्रतिपादन से बचने के लिए। यह विचार कुछ लोगों द्वारा सुझाया जा रहा है, और यह HTML5 और इसकी विशेषताओं के साथ अधिक आकर्षक हो रहा है। एचटीएमएल पर पूर्ण नियंत्रण रखने से अधिक उपकरणों को लक्षित करने की क्षमता भी एक ड्राइविंग कारक है।

मुझे पता है कि यह तकनीकी दृष्टि से व्यवहार्य है - विशेष रूप से jQuery बनाने की चीजों के साथ बहुत आसान है - लेकिन मुझे चिंता है कि पूरे सर्वर पक्ष अबास्ट्रक्शन को फेंककर (वेब ​​फॉर्म में कोड-पीछे, नियंत्रक और दृश्य- एमवीसी में बाध्यकारी) हम और अधिक नलसाजी कर देंगे जो हमें पहले चिंता करने की ज़रूरत नहीं थी।

सवाल करने पर निर्भर करता:

  1. है कि एक वैध चिंता का विषय है, और इसलिए पाइपलाइन हम किस तरह कर खत्म हो सकता है तो क्या होगा?
  2. यह वास्तव में क्या है कि हम पूरे एएसपी.NET ढांचे को एक तरफ (वेब ​​एप्लिकेशन के पक्ष से) फेंककर और शुद्ध HTML पृष्ठों से हमारी डब्ल्यूसीएफ सेवा पर सीधे संचार पर भरोसा कर सकते हैं?

एनबी: मैं जोर देना है कि यह एक कुछ पन्नों जहां अंतर्निहित संरचना का अंतिम निर्णय अप्रासंगिक है के साथ एक सरल वेब एप्लिकेशन नहीं है 'शब्द का उद्यम स्तर' का इस्तेमाल किया है, हम बड़ा गधा एप्लिकेशन यहां बात कर रहे हैं :)

संपादित करें: आदेश भी स्पष्ट होने के लिए, मुख्य क्षेत्रों कि इस तरह के दृष्टिकोण में हमारे लिए चिंता का विषय है कर रहे हैं:

  • प्रमाणीकरण और लेखक ization -> एमवीसी गुणों के साथ एक बहुत ही सरल तरीके से इसे संभालता है (उदा। AuthorizeAttribute), यह 'स्थैतिक' दृष्टिकोण का मतलब है कि डब्ल्यूसीएफ को टोकन को संभालना होगा, उन्हें एन्क्रिप्ट/डिक्रिप्ट करना होगा, और यह तय करना होगा कि प्रत्येक कॉल में इस सारी जानकारी को बनाए रखने के दौरान कौन सा अपना काम करता है। क्या यह एकमात्र समाधान है?

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

  • बाइंडिंग & मान्यता -> मैं एक ही टोकरी में इन दोनों के रख दिया है क्योंकि अंततः एक बार WCF सेवा में सभी जानकारी मेरा पेज (सत्यापन नियमों सहित) किसी के करने वाले ढंग से काम करने की जरूरत है जिसमें एक JSON ऑब्जेक्ट के साथ प्रतिक्रिया इसे उन निष्क्रिय नियंत्रणों से बांधना होगा।

आशा है कि विचार पर्याप्त स्पष्ट है, और अग्रिम धन्यवाद।

उत्तर

3

आप नहीं "पूरे सर्वर साइड अमूर्त फेंक दिया" है आप एक मानक वेब अनुप्रयोग से अलग ढंग से कार्यक्षमता विभाजन कर रहे हैं। सर्वर साइड एब्स्ट्रक्शन अब डब्ल्यूसीएफ सेवा से आता है जो प्रस्तुति स्तर

पर डेटा की आपूर्ति कर रहा है, आपको वेब स्टाइल एपीआई का उपयोग करने के लिए जेएसओएन को वापस लेने में आसान बनाने के लिए उपयोग करना होगा - और मैं नई वेब एपीआई का उपयोग करने का सुझाव दूंगा इसके लिए क्योंकि यह आपको एचटीसी

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

शायद एक नकारात्मक पक्ष यह है कि प्रत्येक पृष्ठ के लिए कम से कम दो राउंडट्रिप्स होने जा रहे हैं - एक एचटीएमएल + जेएस और दूसरे को जेएस के लिए डेटा प्राप्त करने के लिए - एक पारंपरिक वेब ऐप के साथ केवल एक ही है एक ही रूप में डेटा सर्वर साइड लोड किया जाता है जब पहली जगह में पेज प्रतिपादन

+1

सच है, अब अमूर्त डब्लूसीएफ में रहता है। नई वेब एपीआई यह अब कुछ समय के लिए हमारे रडार के नीचे हो गया है और इस समाधान के लिए एक बहुत अच्छा उपकरण के रूप में। हम पूरे बारे में बहुत चिंतित नहीं हैं "डब्ल्यूसीएफ के साथ संवाद कैसे करें और किसके साथ" लेकिन अधिक "हमें अब चिंता करने की क्या ज़रूरत है कि हम स्थिर पृष्ठ लिख रहे हैं?" कुछ चिंताओं: प्राधिकरण और प्रमाणीकरण की तरह सुरक्षा शामिल है। – Alucardz

+0

... सत्यापन, सत्र प्रबंधन, संभावित स्थानीयकरण आदि ... मैं यह नहीं कह रहा हूं कि ये संभव नहीं हैं, निश्चित रूप से डब्ल्यूसीएफ उन्हें पूरी तरह से ठीक से संभाल सकता है लेकिन ऐसा करके हम "पुनः आविष्कार नहीं कर रहे हैं पहिया "तो बात करने के लिए? नहीं एक मुद्दा है, तो सभी मानक उपयोगकर्ता बातचीत वे एक पृष्ठ में नीडिंत है - – Alucardz

+0

"शायद एक नकारात्मक पक्ष यह है कि प्रत्येक पृष्ठ के लिए वहाँ कम से कम दो roundtrips होने जा रहे हैं कि"। –

2

उदाहरण के लिए आप KendoUI जैसे कुछ और अधिक उन्नत js पुस्तकालयों की जांच कर सकते हैं, कि आप के लिए पाइपलाइन का सबसे बड़ा हिस्सा नहीं होगा। आप कुछ वाकई शानदार सुविधाओं का आनंद ले सकते हैं, कि एएसपी.नेट डेवलपर्स ने क्लाइंट साइड कोड के साथ केवल सर्वर-साइड कोड के साथ-साथ-बॉक्स का उपयोग किया है। ढांचा अभी भी विकास में है और आप अधिक शांत सुविधाओं को बाहर आने की उम्मीद कर सकते हैं।

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

+0

आपकी प्रतिक्रिया का धन्यवाद प्राप्त करने के लिए गोल यात्रा। – Alucardz

+0

हमने केंडोयू और सेन्चा का भी उपयोग करने पर विचार किया है। हालांकि यह केवल उस मुद्दे के यूआई भाग का जवाब देता है, जिसमें हमें वास्तव में कोई समस्या नहीं है, वहां आपके द्वारा उल्लेखित कई महान ढांचे हैं। – Alucardz