javascript - AngularJS क्लाइंट एमवीसी पैटर्न?




model-view-controller client-side server-side (7)

अब तक मैं मुख्य रूप से वेब अनुप्रयोगों के निर्माण के लिए Struts 2 , Spring , JQuery प्रौद्योगिकी स्टैक का उपयोग कर रहा था। मुद्दा यह है कि, स्टैक का उल्लेख सर्वर पक्ष MVC पैटर्न का उपयोग करता है। वेब ब्राउज़र की मुख्य भूमिका एक अनुरोध / प्रतिक्रिया चक्र (+ क्लाइंट साइड सत्यापन) तक ही सीमित थी। डेटा पुनर्प्राप्ति, व्यापार तर्क, तारों और सत्यापन मुख्य रूप से सर्वर पक्ष की जिम्मेदारियां थीं।

मेरे पास AngularJS ढांचे के बारे में कुछ प्रश्न हैं जो मैंने पढ़े गए उद्धरणों से प्रेरित थे:

AngularJS ट्यूटोरियल से :

कोणीय ऐप्स के लिए, हम कोड को डीक्यूपल करने और चिंताओं को अलग करने के लिए मॉडल-व्यू-कंट्रोलर (एमवीसी) डिज़ाइन पैटर्न के उपयोग को प्रोत्साहित करते हैं।

विकिपीडिया मॉडल-व्यू-कंट्रोलर से :

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

AngularJS क्लाइंट साइड MVC पैटर्न का उपयोग करता है। तो मुझे लगता है कि किसी भी तरह से क्लाइंट पक्ष को सत्यापन तर्क भी शामिल करने के लिए कोई दूसरा विकल्प नहीं है?

एक मजबूत AngularJS आवेदन लिखने का सबसे अच्छा तरीका क्या होगा? सर्वर पक्ष पर एमवीसी और कुछ तरफ एमसी (मॉडल, नियंत्रक) सर्वर पक्ष पर?

क्या इसका मतलब है कि मॉडल और नियंत्रक एक तरफ डुप्लीकेट (क्लाइंट / सर्वर) हैं?

मुझे पता है कि मेरा सवाल किसी भी तरह अजीब है, लेकिन मुझे लगता है कि कारण यह है कि मैं पारंपरिक सर्वर पक्ष एमवीसी पैटर्न के प्रति आदी हूं। मुझे यकीन है कि कोई ऐसा व्यक्ति है, जो पहले से ही एक ही संक्रमण कर चुका है।


Answers

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

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

मैं धीरे-धीरे इसे गले लगाने और धीरे-धीरे धीरे-धीरे जाने के लिए प्रोत्साहित करता हूं, लेकिन निश्चित रूप से, मैं निश्चित रूप से गारंटी देता हूं।

Angularjs इस दृष्टिकोण की सेवा के लिए डिज़ाइन किया गया है, क्योंकि यह सबसे छोटे काम पर काम कर सकता है क्योंकि यह सबसे बड़ा कर सकता है। उदाहरण के लिए, पहली बार जब मैंने कोणीय का उपयोग किया था तो उपयोगकर्ता नामों को दिखाने के लिए था, जबकि उपयोगकर्ता आईडी टाइप करता था।


मैं यहां जवाब के साथ सहमत हूं। कुछ और टिप्पणियां जब आप एक आवेदक लिखते हैं, तो आपको पहले समस्या डोमेन पर ध्यान केंद्रित करने की आवश्यकता होती है। और कुछ वास्तविक व्यवसाय का एक सॉफ्टवेयर मॉडल बनाएँ। उदाहरण के लिए, यदि आपकी समस्या डोमेन खरीदारी है, तो आपको कुछ मॉडल की आवश्यकता है जो आपको मॉडल करने की आवश्यकता हो सकती हैं:

  • क्रेडिट कार्ड मान्य होना चाहिए।
  • यदि आप ब्रांड एक्स के क्रेडिट कार्ड के साथ भुगतान करते हैं, तो आपको 10% छूट मिल जाएगी।
  • दुकान कार्ट में चेकआउट करने के लिए कम से कम एक आइटम होना चाहिए
  • उपयोगकर्ताओं को दुकान कार्ट में जोड़ने की अनुमति देने से पहले आइटम में स्टॉक होना चाहिए

इन आवश्यकताओं के कार्यान्वयन से आपकी समस्या डोमेन का मॉडल होगा, यह आपका व्यवसाय तर्क है।

कोणीय एक अग्रभाग ढांचा और टूलकिट है। यह एक वेब फ्रंटेंड है। यदि आप इसे वेब फ्रंटेंड में कार्यान्वित करते हैं, तो आप मोबाइल या डेस्कटॉप एप्लिकेशन जैसे अन्य मॉडल या इंटरफ़ेस से अपने मॉडल का पुन: उपयोग करने के अवसर को याद करेंगे। तो, आदर्श रूप से, आपके व्यापार तर्क कार्यान्वयन को किसी भी उपयोगकर्ता इंटरफ़ेस ढांचे से डीकॉप्ल किया जाना चाहिए और किसी भी लगातार ढांचे से भी तय किया जाना चाहिए। फिर, आपके पास इंटरफ़ेस ऑब्जेक्ट्स होंगे जो उपयोगकर्ता इंटरफ़ेस समस्याओं से निपटेंगे और आपके व्यवसाय तर्क वस्तुओं के साथ मिलकर काम करेंगे। यह एक स्प्रिंग एमवीसी नियंत्रक, और / या एक कोणीय नियंत्रक या सेवा हो सकता है।

एक नमूना आवेदन है जिसे आप देख सकते हैं, जो यहां वर्णित सिद्धांतों का पालन करता है।


मुझे लगता है कि शब्द "व्यापार तर्क" यहां एक गलत नाम है। क्लाइंटसाइड ऐप का "व्यवसाय" उपयोगकर्ता इंटरफ़ेस को संभालने का व्यवसाय है। यह सुरक्षा नियमों और स्वामित्व तर्क या अन्य संवेदनशील बौद्धिक संपदा जैसी चीजें नहीं होने वाला है।

तो कोणीय में विभाजन (आमतौर पर) है:

  • नियंत्रक (नियंत्रक): आपके यूआई के पीछे डेटा (दायरा) में हेरफेर करने के लिए।
  • निर्देश : दायरे के माध्यम से नियंत्रक के साथ संवाद करने के लिए डीओएम स्थापित करने और डीओएम में हेरफेर करने के लिए।
  • टेम्पलेट्स (देखें): डीओएम के तत्वों को निर्देश असाइन करने के लिए।
  • स्कोप (मॉडल या व्यूमोडेल): सिस्टम के सभी टुकड़ों के बीच डेटा ले जाने के लिए।
  • सेवाएं : कोड के इंजेक्शन योग्य, पुन: प्रयोज्य बिट्स। आमतौर पर अजाक्स, कुकीज़, या अन्य I / O को संभालने जैसी निर्भरताओं के लिए।

यह वास्तव में लगभग एमवीवीएम है और एमवीसी नहीं है।

आपके "व्यवसाय" तर्क या नियमों के लिए ... सुरक्षा की आवश्यकता वाले कुछ भी सर्वर स्तर पर हमेशा सुरक्षित होना चाहिए।


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

यदि आप एक 'पारंपरिक' जावा वेबपैप लेते हैं जैसा आपने वर्णन किया है और एंगुलर-इज़ इसे लेना है, तो आपको पहले अपना सर्वर लेना होगा और इसे एक वास्तविक API बनाना होगा। जेएसपी को हटाएं, इत्यादि। यह वास्तव में कठिन हिस्सा है, आईएमओ, एक कोणीय ऐप लिखने - आरईएसटी एपीआई अधिकार प्राप्त करना। यह तय करने के लिए कि सर्वर में जाने के लिए कौन सा तर्क आवश्यक है , यह एक शुद्ध एपीआई के रूप में सोच रहा था और इस पल के लिए भूल रहा था कि इसका फ्रंट एंड होगा

उस सवाल ने वास्तव में मेरी मदद की - अगर कोई किसी दिए गए संसाधन को सहेजने का प्रयास करता है और उस संसाधन के पास वैध डेटा नहीं है तो उन्हें बताने के लिए कोई अंत नहीं है - वे सीधे एपीआई मार रहे हैं ताकि एपीआई को इसे अस्वीकार करने की आवश्यकता हो। तो, पिछला अंत गहरी सत्यापन के लिए ज़िम्मेदार है। यह आपके व्यापार तर्क पर भी लागू होता है। मान लीजिए कि कोई सिर्फ एपीआई का उपयोग कर रहा है और यह स्पष्ट हो जाएगा कि आपके सर्वर को क्या करना है।

सर्वर को (शायद) जेसन प्रारूप (मैं स्प्रिंग एमवीसी + जैक्सन का उपयोग करता हूं) में डेटा को वेंड करने की भी आवश्यकता है, इसलिए यह मॉड्यूलर को मॉडल को उजागर करने और डेटाबेस के साथ संचार के लिए ज़िम्मेदार है।

तो फिर कोणीय पक्ष पर एमवीसी क्या है?

  • मॉडल : डेटा जो आरईएसटी एपीआई से आता है। यदि एपीआई JSON को वेंड कर रहा है, तो ये ऑब्जेक्ट्स पहले से ही प्रथम श्रेणी जावास्क्रिप्ट ऑब्जेक्ट्स होंगे।
  • देखें : HTML, और निर्देश जब आपको DOM में हेरफेर करने की आवश्यकता होती है
  • नियंत्रक : (और कस्टम सेवाएं जिन्हें आपने अपने नियंत्रकों से बाहर निकाल दिया है ..)
    • आरईएसटी एपीआई पूछताछ करता है और $ स्कोप पर दृश्य के लिए जरूरी है
    • उन घटनाओं का जवाब देने के निर्देशों के लिए कॉलबैक प्रदान करता है जिन्हें बाद में सर्वर पर कॉल की आवश्यकता हो सकती है।
    • प्रमाणीकरण: आमतौर पर एक निर्देश के लिए कॉलबैक के माध्यम से। संभवतः सर्वर में आपके द्वारा पहले से किए गए कुछ सत्यापन को ओवरलैप कर देगा , लेकिन आप नहीं चाहते हैं कि आपका उपयोगकर्ता सर्वर को सबकुछ मान्य करने के लिए प्रतीक्षा करे - ग्राहक को तत्काल प्रतिक्रिया देने के लिए सत्यापन के बारे में कुछ पता होना चाहिए।
    • व्यापार तर्क: सत्यापन के रूप में बहुत अधिक वही कहानी।

लेकिन क्लाइंट में और सर्वर में तर्क का दोहराव क्यों? अधिकतर क्योंकि आप एक ऐप नहीं लिख रहे हैं, आप दो स्वतंत्र चीजें लिख रहे हैं:

  1. एक आरईएसटी एपीआई जिसे बिना किसी अंत के मजबूत और उपयोग करने योग्य होना चाहिए
  2. एक जीयूआई जिसे किसी उपयोगकर्ता को तत्काल प्रतिक्रिया देने की आवश्यकता होती है और जरूरी नहीं कि सर्वर के लिए प्रतीक्षा करें।

तो, संक्षिप्त उत्तर - यह भूलकर आरईएसटी एपीआई अधिकार प्राप्त करें कि एक यूआई होगा, और कोणीय में क्या होगा, यह बहुत स्पष्ट होगा।


मुझे यह सवाल भी लगता है, क्योंकि कुछ संगठन सिर्फ नई प्रौद्योगिकियों के लिए सनक हैं - "मुझे क्लाउड चाहिए ... प्रतीक्षा करें, मुझे हल्का वजन चाहिए", यह उचित है कि यह एक हल्के ढांचे पर स्विच के लायक है या नहीं।

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

सुरक्षा बिंदु के लिए, मेरा मानना ​​है कि भारी या संवेदनशील व्यापार नियम सर्वर के पक्ष में रहना चाहिए क्योंकि हम इसे दुनिया में बेनकाब नहीं करना चाहते हैं। यदि व्यापार तर्क खराब रूप से विकसित किया गया है, तो हम आसानी से हमारे कोड पर कमजोरी पा सकते हैं और इसका फायदा उठा सकते हैं।

यहां कोणीय जैसे ढांचे के लिए मेरा विचार एक छोटी दुकान / एसओएचओ हैंडलिंग ग्राहक की तरह है, और उनके पास कुछ लोग हैं और वास्तव में कुशल और तेज़ हैं। वे व्यापार और वितरण का सामना करने वाले ग्राहकों के लिए अच्छी तरह से देखभाल करते हैं / माल कुशलतापूर्वक प्राप्त करते हैं (आरईएसटी, जेएसओएन)। उनके पास भूमिकाएं और कार्य निर्दिष्ट हैं, लेकिन कुछ कर्मचारी एक कार्य से अधिक प्रदर्शन करते हैं। दुकान चोर या लुटेरों के लिए भी कमजोर है क्योंकि आमतौर पर वे भारी सुरक्षा पर जोर नहीं देते हैं।

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


मेरा दृष्टिकोण हमेशा नीचे की ओर दृष्टिकोण है। डाटाबेस डिज़ाइन से शुरू, उचित रूप से निर्मित / संबंधित तालिकाओं के साथ, आवश्यक होने पर संग्रहित प्रक्रियाएं, फिर समाधान में इकाई फ्रेमवर्क जोड़ें या यदि ईएफ विकल्प नहीं है तो ADO.Net का उपयोग करें। फिर डेटाबेस तर्क और डेटाबेस को डेटाबेस में डेटा प्राप्त करने के लिए विकसित करें।

मॉडल स्थापित होने के साथ, अब हम दो मार्गों पर जा सकते हैं: एमवीसी नियंत्रक का विकास, और / या वेबएपीआई नियंत्रक विकसित करना। दोनों नियंत्रकों के पास मॉडल तक पहुंच हो सकती है, यह केवल कक्षाओं को चालू करने और विधियों का आह्वान करने का मामला है।

अब आपके पास एमवीसी व्यूअर को स्थापित करने का विकल्प है, जो एमवीसी नियंत्रक द्वारा नियंत्रित किया जाता है, या पूरी तरह से HTML पृष्ठों या एसपीए (नोडजेएस पर होस्ट किए गए सिंगल-पेज एप्लिकेशन) से अलग सेट है।

एचटीएमएल पेज के पूरी तरह से अलग सेट के साथ, आपको वेबएपीआई नियंत्रकों का उपयोग, गेट, पोस्ट, पुट और डिलीट विधियों के साथ करने की आवश्यकता होगी, और अपने क्लाइंट की पहचान करने के लिए टोकन को आगे और आगे शामिल करना सुनिश्चित करें, और सीओआरएस सक्षम करें (क्रॉस ओरिजिनल अनुरोध के लिए )

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

दोनों स्थितियों में, आप AngularJS का उपयोग डेटा से आगे / नियंत्रकों तक ले जाने के लिए कर सकते हैं।

IMHO AngularJS नियंत्रक की अवधारणा सी # एमवीसी या सी # वेबएपीआई नियंत्रक के साथ समान नहीं है। AngularJS नियंत्रक घर सभी जावास्क्रिप्ट तर्क के साथ-साथ "ApiFactory" के माध्यम से एंडपॉइंट्स पर कॉल करता है, जबकि सी # नियंत्रक सर्वर पक्ष में एंडपॉइंट्स के अलावा कुछ भी नहीं हैं जो यूआई अनुरोधों को स्वीकार करते हैं और जवाब देते हैं।






javascript model-view-controller client-side angularjs server-side