एमवीसी: हमें "नियंत्रक" की आवश्यकता क्यों है, या हमें इस पैटर्न का उपयोग कब करना चाहिए?

Question

मैंने एमवीसी के बारे में कई प्रकाशन पढ़े हैं, लेकिन मैं अभी भी स्पष्ट रूप से समझ नहीं पा रहा हूं कि हमें "नियंत्रक" की आवश्यकता क्यों है।

मैं आमतौर पर में क्लाइंट-सर्वर मॉडल अनुप्रयोग लिखने:

सर्वर सभी व्यापार-तर्क होता है, और यह जीयूआई बारे में कुछ नहीं जानता है। यह मुख्य काम करता है, और यह यथासंभव पोर्टेबल है।

ग्राहक एक जीयूआई है, यह सर्वर को बांधता है, उपयोगकर्ता के साथ सूचना का आदान प्रदान, उपयोगकर्ता से सर्वर को आदेश भेजता है।

मैं इस वास्तुकला की तरह, और मैं समझ नहीं क्यों लोग वास्तव में, ग्राहक और सर्वर के बीच एक और मध्यम की ज़रूरत है जो नियंत्रक होने लगते हैं?

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

• Data_receiver:

  सर्वर निम्न आइटम शामिल हैं:

  मैं इसे कैसे होगा वास्तव में COM पोर्ट से कच्चे डेटा प्राप्त करता है, लेकिन यह इंटरफेस है, इसलिए हम कुछ करने में सक्षम हैं एक और वर्ग जो किसी अन्य स्रोत से डेटा प्राप्त करता है;

• Data_decoder: कच्चे डेटा लेता है और परिणामस्वरूप डीकोड किए गए संदेश लौटाता है, यह इंटरफेस भी है, इसलिए हम आसानी से एन्कोडिंग प्रोटोकॉल बदल सकते हैं;
• Data_core: Data_receiver और Data_decoder के उदाहरणों का उपयोग करके, ग्राहकों को सिग्नल उत्सर्जित करता है।

ग्राहक निम्न आइटम शामिल हैं:

• Appl कोर: बनाता है Data_receiver (एक COM पोर्ट से कनेक्ट होता है), Data_decoder और Data_core (जो Data_receiver और Data_decoder उदाहरणों के लिए संदर्भ लेता है) के कहने , जीयूआई सरल लॉग विंडो भी बनाता है (जो Data_core का संदर्भ लेता है);
• जीयूआई सरल लॉग विंडो: Data_core से बांधता है, यानी इसके द्वारा उत्सर्जित सिग्नल के लिए सुनता है, और प्राप्त डेटा प्रदर्शित करता है।

के रूप में मैं समझ गया कि मैं क्या MVC के बारे में पढ़ा है, जीयूआई नहीं वास्तव में प्राप्त हुए संदेशों का Data_core से ले क्योंकि नियंत्रक कि क्या करना चाहिए और उसके बाद जीयूआई को डेटा पास जाना चाहिए। लेकिन क्या खराब चीजें होती हैं यदि जीयूआई इस डेटा को सीधे मॉडल से लेता है?

Answer 1

"क्लाइंट-सर्वर" के पास एमवीसी, afaik के साथ कुछ लेना देना नहीं है।

मैं इस तरह यह समझ:

• Model जिस तरह से आप अपने डेटा संरचना है।
• View दृश्यमान प्रतिनिधित्व है। (जीयूआई)
• Controller दृश्य और/या अन्य तर्क को नियंत्रित करने के लिए तर्क का उपयोग करता है।

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

Answer 2

मुझे आपके क्लाइंट-सर्वर पैटर्न के विवरण पढ़ने में MVVM पैटर्न के बारे में लगता है। जब आप इकाई परीक्षण करना चाहते हैं तो नियंत्रक के रूप में वीएम (व्यूमोडेल) को देखना बेहतर होता है।

आपके पैटर्न के बाद, शास्त्रीय क्लाइंट/सर्वर पैटर्न, नियंत्रक, मॉडल, और दृश्य सर्वर कोड में लाइव देखें जिसे आप Data_receiver, Data_decoder और Data_core कहते हैं। आपके 'क्लाइंट' में आपके पास फिर से नियंत्रक होता है, और देखें।

सर्वर कोड से अलग करने के लिए उपयोगी है जो COM से सिग्नल और डेटा प्राप्त करता है और डीकोड करता है, एक मॉडल जिसमें नियंत्रक पास होता है और डेटाबेस से और रास्ते में डेटा प्राप्त करता है, एक दृश्य जो एन्कोड करता है और मॉडल से कच्चे डेटा स्वरूपित करता है।

अपने आप को दोहराएं (डीआरवाई) सिद्धांत का पालन करने के बाद आप देख सकते हैं कि आपके कोड के सर्वर और क्लाइंट भागों दोनों में नियंत्रक कोड है जहां आप कोड या जिम्मेदारियों को दोहराते हैं।

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

Answer 3

कभी भी मैं आपकी गलत व्याख्या को सही नहीं करना चाहता हूं "क्लाइंट और सर्वर के बीच एक और परत क्यों जरूरी है।"

यदि आप निम्न पंक्तियों से गुज़रते हैं तो उत्तर क्रिस्टल स्पष्ट है कि एमवीसी आर्किटेक्चर का त्रिभुज मॉडल है।

देखें मॉडल से अनुरोध पूछता है, मॉडल नियंत्रक से पूछता है, नियंत्रक इसे संसाधित करता है और वापस देखने के लिए भेजता है।

The Model is the way you structure your data. 
The View is the visible representation. (GUI) 
The Controller uses the logic to control the view and/or other logic. 

सादर, Pavan.G

Answer 4

अतीत में मैं अपने आप को इस एक ही सवाल कई बार कहा है और मैं हाल ही में के बारे में JSP मॉडल 2 वास्तुकला पढ रहा हूं, और विकिपीडिया प्रविष्टि निम्नलिखित कहा गया।

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

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