MVC में M कहाँ है?

14

मैं अपने आवेदन को MVC में वापस करने की कोशिश कर रहा हूं, लेकिन मैं एम भाग पर अटका हुआ हूं।

डेटाबेस-समर्थित ऐप में, मॉडल ऐप कोड में लागू किया जाता है, है ना?

लेकिन फिर, डेटाबेस में क्या है - यह भी मॉडल नहीं है?

(मैं डेटाबेस को एक साधारण ऑब्जेक्ट स्टोर के रूप में उपयोग नहीं कर रहा हूं - डीबी में डेटा एक उद्यम संपत्ति है)।

design-patterns mvc

I'm not using the database as a simple object store। मैं अनुमान लगा रहा हूं कि डेटाबेस में कुछ व्यापारिक तर्क हैं, संग्रहीत प्रक्रियाओं के रूप में। MVC के खिलाफ जाने वाले सिद्धांत में, लेकिन व्यवहार में यह कोई मायने नहीं रखता है।

— यानिस डे 1’11

@YannisRizos - वहाँ है डीबी में बीएल, लेकिन क्या मैं उस का मतलब है कि मैं डीबी में डेटा एक जीवन और आवेदन परे अर्थ करना चाहते है।

3

I want the data in the DB to have a life and meaning beyond the application.क्या?

— यानिस डे १’११

2

@YannisRizos - मैं निश्चित रूप से उस कथन को पुनः प्राप्त करने में मदद की सराहना करूंगा। डेटा एक उद्यम संपत्ति है, है ना? यह ऐप से संबंधित नहीं है - इसलिए ऐप को कुछ पागल बदनाम मॉडल बनाने की अनुमति नहीं है , जो ऐप के लिए बहुत आसान बनाता है , अगर यह अन्य ऐप से डेटा का पुन: उपयोग करना बहुत मुश्किल बनाता है। कोई सुझाव?

1

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

— स्टुपेरयूजर

46

हाँ, कोड और डेटाबेस में दोनों मॉडल "मॉडल" हैं।

मॉडल को आपके आवेदन "आईएस" के साथ क्या करना है, और नियंत्रक वह है जो "करता है"। डेटाबेस के लिए प्रत्यक्ष दृढ़ता से निपटने वाले किसी भी कोड को मॉडल माना जाता है।

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

— रयान हेस
स्रोत

15

तो सी और वी के दृष्टिकोण से, कि एक डेटाबेस है एम का सिर्फ एक कार्यान्वयन विवरण है?

निश्चित रूप से। अच्छी तरह से बहक गया।

— हर्बी

3

@MattFenwick C और V के परिप्रेक्ष्य से, कोई डेटाबेस नहीं है। आप डेटाबेस को डेटा संग्रहण से अधिक उपयोग कर रहे हैं, MVC के संदर्भ में एक डेटाबेस केवल एक डेटा संग्रहण है। लेकिन यह पूरी तरह से ठीक है, अगर यह आपके आवेदन के अनुरूप है।

— यानिस डे १’११

5

+1 के लिए "mvc को न उखाड़ें"

— जेवियर

2

"अपने व्यापारिक तर्क को डेटाबेस और UI से बाहर रखें" - यह

— डेविड मर्डोक

17

Trygve Reenskaug ने 1978 में MVC पैटर्न का वर्णन करते हुए प्रारंभिक पत्र लिखे । उनके विवरण में मॉडल वास्तविक दुनिया की वस्तुओं, घटनाओं और अवधारणाओं का प्रतिनिधित्व करने वाला वस्तु मॉडल था। डेटाबेस समर्थित एप्लिकेशन के आपके परिदृश्य में, मॉडल आपके डेटा का एक प्रक्षेपण है। इसे सीधे शब्दों में कहें, तो मॉडल वर्ग और उनके रिश्ते हैं जो आपके आवेदन से संबंधित हैं।

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

— माइकल ब्राउन
स्रोत

+1: मुझे यह उत्तर सबसे अच्छा लगता है। The model is a projection of your data.डेटाबेस को एक्सेस करने और अनुक्रमण के लिए डेटा को सबसे कुशल तरीके से संग्रहीत करने के लिए डिज़ाइन किया गया है। मॉडल को इसके बजाय व्यावसायिक डोमेन के आसपास डिज़ाइन किया जाना चाहिए।

— जोएल एथरटन

मुझे दूसरी बार ले गया the Domain Model (what's mapping to your database)। अच्छा उत्तर!

2

+1 यह उन विभिन्न स्वादों का एक शानदार वर्णन है जो MVC में विकसित हुए हैं।

— रयान हेस

धन्यवाद दोस्तों। मैं अपनी पुस्तक लिखते समय इस सामग्री में गहराई से गोता लगा रहा हूं। खुशी है कि यह समझ में आता है!

— माइकल ब्राउन

3

आपको MVC के लिए डेटाबेस की आवश्यकता नहीं है। यदि आपका मॉडल डेटाबेस से बात करने के लिए होता है, तो बढ़िया है। यह अपने आप को एक सपाट फ़ाइल के लिए भी बनाये रख सकता है, या अपने आप पर ही नहीं टिकता।
मॉडल वह जगह है जहां आपके एप्लिकेशन में मेमोरी में डेटा संग्रहीत होता है। आप मॉडल का उपयोग उसके डेटा पर गणना और सत्यापन करने के लिए भी करना चाहेंगे। उदाहरण के लिए, आपके पास एक FinancePayment मॉडल है, जिसमें ब्याज दर, अवधि और सिद्धांत जैसे गुण हैं। मासिक भुगतान की गणना करने के लिए आप अपने मॉडल में getMonthlyPayment () विधि जोड़ सकते हैं। आप नियंत्रक या दृश्य में ऐसा नहीं करना चाहेंगे।
दृश्य यथोचित रूप से गूंगा होना चाहिए, या तो कोई तर्क नहीं है, या केवल साधारण डेटा बाइंडिंग का उपयोग करना है ( मार्टिन फाउलर की साइट पर निष्क्रिय दृश्य और पर्यवेक्षण नियंत्रक देखें )। दृश्य घटनाओं को उठाता है जब उपयोगकर्ता एक बटन क्लिक करने की तरह सामान करता है।
नियंत्रक घटनाओं को संभालने के लिए ज़िम्मेदार है (उपयोगकर्ता द्वारा सेव बटन पर क्लिक करने पर कुछ कोड चलाएं), और मॉडल गुण सेट करने के लिए, और मॉडल को लोड करने और स्वयं को बचाने के लिए कह रहा है (यदि दृढ़ता का उपयोग करके)। नियंत्रक को मॉडल के डेटा पर गणना नहीं करनी चाहिए। हालाँकि, नियंत्रक में, आप दृश्य की ओर से कुछ गणनाएँ कर सकते हैं, जैसे कि "if model.profit () <0 तो widget.colour = 'red'"
आपको अपने एप्लिकेशन के कमांड लाइन संस्करण में मॉडल बदलने के बिना स्विच करने में सक्षम होना चाहिए, और मॉडल की कार्यक्षमता को खोए बिना।

ए। आपको केवल अपने एप्लिकेशन के मोबाइल संस्करण (जैसे डेस्कटॉप संस्करण के विपरीत) को केवल दृश्य स्विच करने में सक्षम होना चाहिए (और नियंत्रक या मॉडल नहीं)। आपको जीयूआई परीक्षण ढांचे के बिना अपने मॉडल और नियंत्रकों को इकाई-परीक्षण करने में सक्षम होना चाहिए।

— नील मैकगिगन
स्रोत

सही पर! यह बहुत स्पष्ट है।

2

मॉडल वह कोड होता है, जिसमें वीएंडवाई और सी के सामने का कनेक्शन होता है, और बैकएंड में लगातार स्टोरेज (फाइल से SQL / NoSQL डेटाबेस तक कुछ भी हो सकता है)। यह न केवल कोड है जो db और स्टोर्स से db (जो मॉडल की गलतफहमी में से एक है) पर लोड होता है, यह वह कोड होता है जो वास्तव में सभी "डोमेन" का काम करता है - चयन, फ़िल्टर, अलर्ट, कंप्यूट, से अधिक डेटा। आवेदन के सभी गैर-यूआई तर्क शामिल हैं।

— herby
स्रोत

कच्चा डेटा जिसे आप लगातार रखना चाहते हैं। किसी भी संगठन में जो आपके मॉडल के लिए सबसे उपयुक्त है। मॉडल एक एपीआई है जो आपके एप्लिकेशन तर्क को लाइव बनाता है। वह डेटाबेस (गैर-जीवित) डेटा के लिए भंडारण है। यदि यह आपके ऐप के लिए संभव है (मुझे नहीं पता कि यह किस तरह का ऐप है), तो इसे "डेटाबेस-समर्थित ऐप" के रूप में सोचने की कोशिश करें, लेकिन सिर्फ एक "ऐप" के रूप में, जो एक डेटाबेस को एक तरह से उपयोग करता है मॉड्यूल डेटा को बनाए रखने के लिए। कई समस्याएं डेटाबेस को "आइकॉनिज़िंग" से उपजाती हैं - यह मॉडल के लिए डेटा स्टोरेज से ज्यादा कुछ नहीं है; आप इसे खोद सकते हैं, इसका पुनर्गठन कर सकते हैं या इसे बदल सकते हैं यदि यह मदद करता है।

— इसके बाद

(ऊपर परिदृश्यों के लिए केवल रखती है जब DB में डेटा किसी अन्य अनुप्रयोग के साथ साझा नहीं कर रहे हैं)

— herby

मैं अपनी टिप्पणी में खराब शब्द-चुनाव के लिए माफी मांगता हूं - मेरे कहने का मतलब यह था कि मुझे यकीन नहीं है कि एमवीसी के संबंध में डेटाबेस में क्या है । MVC के बाहर डेटाबेस है? क्या यह मॉडल का हिस्सा है? क्या यह वी या सी का हिस्सा है (शायद नहीं, लेकिन आपको बात मिलती है)।

समझा। आप शायद मेरे जवाब से निकले हैं कि आप इसे मॉडल का एक हिस्सा देख सकते हैं जो एप्लिकेशन डेटा को बनाए रखने के लिए कार्य करता है जो मॉडल प्रक्रियाओं से कोड है। (मैं ईडीआईटी को देखता हूं): यदि वह डेटाबेस कुछ ऐसा है जो एप्लिकेशन को आउटलाइव करना चाहिए, तो डेटाबेस को बाहरी सेवा के रूप में देखें, किस मॉडल के साथ संवाद करना चाहिए, कम्प्यूटेशन के लिए डेटा प्राप्त करना चाहिए और कुछ को वापस भी भेजना चाहिए।

— इसके बाद

चरम स्थिति में, जब व्यापार तर्क डीबी अपने आप में है, तो आप बहुत पतली मॉडल ज्यादातर डीबी के लिए रिले, या यहाँ तक कि का कहना है कि डाटाबेस हो सकता है अपने मॉडल (लेकिन फिर, यह होना चाहिए सभी तर्क)।

— हर्बी

2

बहुत ही सरल और आदर्शवादी दृष्टिकोण रखना।

मॉडल को आमतौर पर डोमेन के मॉडल के रूप में देखा जाता है (मोटे तौर पर, व्यवसाय), डेटा के मॉडल के रूप में नहीं। ये समान दिख सकते हैं, लेकिन वे पूरी तरह से एक दूसरे से बंधे नहीं हैं।

व्यू एप्लीकेशन के अंतिम छोर का एक मॉडल होना चाहिए और नियंत्रक एक दृश्य से दूसरे तक प्रवाह का एक मॉडल होना चाहिए।

व्यवसाय तर्क पूरी तरह से मॉडल में समझाया जाना चाहिए, चाहे वह डेटाबेस या कोड में हो। यद्यपि कुछ व्यावसायिक तर्क विभिन्न कारणों से व्यू या कंट्रोलर में दोहराए जा सकते हैं, लेकिन यह संभव (और सुरक्षित) होना चाहिए कि वे दो घटकों को पूरी तरह से हटा दें और इसके स्थान पर एक अलग फ्रंट-एंड डाल दें।

— PDR
स्रोत

1

मेरी समझ में, एमवीसी आपके क्लाइंट एप्लिकेशन के वास्तुशिल्प पैटर्न का वर्णन है। विकिपीडिया में यहाँ चित्र बस यह दिखाता है:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

बेशक, जब आपके पास "संग्रहीत प्रक्रियाओं" में लागू किए गए एप्लिकेशन के कुछ हिस्सों होते हैं, तो वे डेटाबेस कोड मॉडल का हिस्सा भी हो सकते हैं, या नियंत्रक का भी हो सकता है (कोड क्या करता है इसके आधार पर)। लेकिन अगर ऐसा नहीं है, तो डेटाबेस स्पष्ट रूप से "एमवीसी के बाहर" है, जैसा आपने कहा था।

— डॉक्टर ब्राउन
स्रोत

1

But then, what is in the database -- is that not also the model?

नहीं ऐसा नहीं है। " मॉडल अनुप्रयोग डोमेन के व्यवहार और डेटा का प्रबंधन करता है"। अक्सर, मॉडल एक डेटाबेस में हाँ में हाँकता है, लेकिन किसी भी तरह से यह एक आवश्यकता नहीं है। मॉडल आपके एप्लिकेशन और डेटाबेस के बीच एक नई परत है। बैकएंड मॉक ऑब्जेक्ट्स, एक्सएमएल, या कुछ और हो सकता है जो डेटा की दृढ़ता का समर्थन करता है।

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

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

ये अलगाव कार्य को नियंत्रित करने के व्युत्क्रम की अनुमति देने के लिए महत्वपूर्ण हैं।

— P.Brian.Mackey
स्रोत

एक उत्कृष्ट और बहुत जानकारीपूर्ण उत्तर के लिए +1; हालाँकि, मैं सुझाव दूंगा कि अंतिम वाक्य स्पष्टता के योग्य है। आईओसी जरूरी नहीं है कि व्यापक रूप से जाना और समझा जाए, इसलिए यह थोड़ा भ्रम पैदा कर सकता है। वास्तव में आपके द्वारा इसका क्या अर्थ है, इसका एक उपयोगी विवरण शायद एक सेन एसई उत्तर के दायरे से परे है, लेकिन इसने मुझ पर छलांग लगाई।

— एडम क्रॉसलैंड

हालाँकि, यदि आप अपने व्यावसायिक तर्क को संग्रहीत प्रक्रियाओं में रखते हैं, तो हाँ, डेटाबेस मॉडल को शामिल करता है। (व्यक्तिगत रूप से, मैं उस दृष्टिकोण की सिफारिश नहीं करूंगा।)

— रॉय टिंकर

1

@ राय टिंकर - नहीं, इससे कोई फर्क नहीं पड़ता। मॉडल वैचारिक रूप से अलग है। ऐसी इकाइयाँ होंगी जो परत के भीतर डेटाबेस के साथ एकीकृत होती हैं। इन संस्थाओं को अन्य संस्थाओं से अलग रहना चाहिए जो मॉडल के भीतर मौजूद हैं जिनके अन्य रिश्ते हैं (उदाहरण के लिए एक नकली)। नियंत्रक को चाहिए कि वह मॉडल को इस तरह से कॉल करे कि उसे इस बात का ज्ञान न हो कि डेटा कैसे और कहां से आता है। बल्कि यह निर्धारण निर्भरता इंजेक्शन और IoC के साथ किया जाना चाहिए (मूल रूप से इसका इंटरफ़ेस जिसे अलग-अलग बैकेंड, मॉकिंग या डीबी से जोड़ा जा सकता है)।

— पी। ब्रायन। मैके 18

1

डेटाबेस मॉडल का कार्यान्वयन विवरण है। मॉडल एक पूर्ण डोमेन मॉडल होना चाहिए और डेटा और प्रक्रिया को संयोजित करना चाहिए। पृथक्करण अंतर चिंताओं के बीच होना चाहिए न कि एक प्रक्रिया और उस प्रक्रिया से संबंधित आंकड़ों के बीच।

इसे भी देखें: http://martinfowler.com/bliki/AnemicDomainModel.html

— पेरिस सिंक्लेयर
स्रोत

0

यह वास्तव में बहुत सरल है, "मॉडल" डेटा इंटरफ़ेस के लिए अमूर्तता का प्रतिनिधित्व करता है। इसीलिए:

डेटाबेस को मॉडल का हिस्सा माना जाता है , लेकिन मॉडल ही नहीं
मॉडल का डेटा डेटाबेस, फ़ाइलों, वेब-सेवाओं या यहां तक कि नकली हो सकता है।
MVC, HMVC या इसी तरह के ढांचे में मॉडल कक्षाएं प्रश्नों को संग्रहीत करना चाहिए ( "वसा मॉडल, पतला नियंत्रक" सिद्धांत [ 1 ] [ 2 ] [ 3 ])

और - मैं सही हूं- यही कारण है कि जब कोई एमवीसी संदर्भ के बाहर के मॉडल को संदर्भित करता है, तो किसी को सबसे अधिक डेटा (यानी स्कीमा ) की संरचना को संदर्भित करता है ।

— dukeofgaming
स्रोत

0

मुझे लगता है कि एम में कुछ तर्क हैं और डीबी में डेटा स्टोर करते हैं। कंट्रोलर इनवॉइस करता है कि कौन सा मॉड्यूल निष्पादित होगा और यह मॉड्यूल डीबी में लॉगिक्स और स्टोर डेटा को निष्पादित करेगा (मई स्थिर परत हो सकता है) और फिर यह मॉड्यूल वी पर वापस आ जाता है।

— मार्क xie
स्रोत

0

एमवीसी में एम (ओडेल) को एक ही स्थान पर व्यापार / डोमेन के मॉडल पर कब्जा करना चाहिए ।

यह आदर्श रूप में डोमेन के व्यावसायिक नियमों के साथ-साथ इसकी संरचना को भी शामिल करना चाहिए ।

C (कंट्रोलर) sholuld आदर्श रूप से केवल मॉडल की स्थिति में परिवर्तन आरंभ करने के लिए व्यावसायिक मॉडल की जानकारी को प्रस्तुतिकरण (उदाहरण के लिए देखें) और V (iew) से उपयोगकर्ता इनपुट कैप्चर करने के साथ ही चिंता करता है।

डेटाबेस लेयर केवल विशेष समय पर मॉडल की स्थिति की दृढ़ता के साथ (या बल्कि केवल सौदा करना चाहिए)।

ऐसे में यह कुछ ऐसा है जो नहीं है अंतर्गत आता है या तो करने के लिए मॉडल या नियंत्रक MVC पैटर्न का हिस्सा है, बल्कि यह एक पूरी तरह से अलग चिंता का विषय है जो (पारदर्शी रूप से मॉडल के लिए कोई परिवर्तन बने द्वारा परोक्ष लागू किया जा सकता मुखौटा के एक समारोह के रूप में है, उपलब्ध कराने के आपके मॉडल के साथ कंट्रोलर के साथ बातचीत) या जैसा कि यह मॉडल से म्यूटेशन समाप्त करने के बाद नियंत्रक द्वारा स्पष्ट रूप से नहीं कहा जाता है, की तुलना में अधिक बार किया जाता है।

— रोलैंड टेप्प
स्रोत

0

एक आदर्श दुनिया में मॉडल में केवल व्यावसायिक तर्क होना चाहिए, यह कुछ वास्तविक वस्तु जैसे कि एक सदन को मॉडल करता है। हालाँकि लगभग सभी परिस्थितियों में मॉडल को अपने डेटा को कुछ स्टोरेज के लिए बनाए रखने की आवश्यकता होती है।

मॉडल और संग्रहीत डेटा के बीच की बातचीत या तो एक अलग डेटा परत पर या सीधे मॉडल में हो सकती है, जो कि ORM (ऑब्जेक्ट रिलेशनल मैपर) का उपयोग करते समय होता है। दूसरे शब्दों में, या तो मॉडल डेटाबेस से सीधे जुड़ता है या इसका डेटा किसी अन्य "डेटा एक्सेस" ऑब्जेक्ट पर जाता है जो डेटाबेस से जुड़ता है।

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

यहाँ ActiveRecordएक लोकप्रिय ORM का उपयोग कर एक रूबी उदाहरण दिया गया है :

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Pricehousesतालिका में एक फ़ील्ड है जो स्वचालित रूप से पता लगाया जाता है ActiveRecordजिससे ऑब्जेक्ट में एक गेट्टर और सेटर जुड़ जाता है। जब saveमूल्य कहा जाता है तो मूल्य विशेषता डेटाबेस के लिए बनी रहती है।

मेरे दृष्टिकोण से डेटा लेयर होने की समर्थक यह है कि आपको एक ऐसा बिंदु मिलता है जिसमें आप मॉडल में पहुंचने से पहले डेटा में हेरफेर कर सकते हैं, मॉडल को इसकी चिंता कम होती है, इसकी जिम्मेदारियाँ कम होती हैं। उदाहरण के लिए, आपको किसी भी संगत डेटा स्रोत से डेटा को संयोजित करने की आवश्यकता नहीं हो सकती है, यह एक ऐसी चीज है जिसे ORM आसानी से नहीं संभाल सकता।

मुख्य चोर इसके प्रबंधन के लिए अमूर्त की एक और परत है, अगर आपको इसकी आवश्यकता नहीं है, तो परेशान न करें, इसे सरल रखें। कम चलने वाले हिस्से, गलत होने के लिए कम।

— क्रिस
स्रोत

-1

हाँ आप सही है।

(मॉडल व्यू कंट्रोलर)

उपयोगकर्ता इंटरफ़ेस (दृश्य) और प्रसंस्करण (नियंत्रक) से डेटा (मॉडल) को अलग करने वाले अनुप्रयोगों के निर्माण के लिए एक वास्तुकला ।

व्यवहार में, एमवीसी के विचार और नियंत्रक अक्सर एक ही वस्तु में संयुक्त होते हैं क्योंकि वे निकटता से संबंधित होते हैं। MSDN के अनुसार

नियंत्रक मॉडल और / या को सूचित करते हुए उपयोगकर्ता से माउस और कीबोर्ड इनपुट की व्याख्या करता है the view to change as appropriate.

इस आरेख की जाँच करें:

उदाहरण के लिए, नियंत्रक कोड डेटा के लिए एक अनुरोध को मान्य करता है और इसे एक दृश्य में वापस करने का कारण बनता है। दृश्य-नियंत्रक ऑब्जेक्ट केवल एक मॉडल से बंधा हुआ है; तथापि,a model can have many view-controller objects associated with it.

— निरंजन सिंह
स्रोत

4

In practice, MVC views and controllers are often combined into a single object because they are closely related.यदि आप ऐसा कर रहे हैं, तो आप इसे गलत कर रहे हैं ...

— yannis

आरेख कहाँ से है? और परिभाषा कहाँ से है? कृपया बिना सही एट्रिब्यूशन के इंटरनेट से पेस्ट सामान कॉपी न करें।

— यानिस

@ यानिस रिज़ोस - वह एमएस प्रलेखन उद्धृत कर रहा है। यह यहाँ से थोड़ा सा बाहर है, लेकिन वे कह रहे हैं कि गैर-वेब अनुप्रयोगों में अक्सर दृश्य / नियंत्रक का युग्मन होता है, लेकिन वेब अनुप्रयोगों में बहुत स्पष्ट अंतर होता है। यह संभवतः एक कारण है कि आप एमएस को अपने विंडोज़ ऐप (एमवीवीएम के बजाय एमवीसी) पर जोर नहीं दे रहे हैं, सिर्फ वेब-ऐप। msdn.microsoft.com/en-us/library/ff649643.aspx

— P.Brian.Mackey

1

@ P.Brian.Mackey मुझे संदेह था कि एमएस किसी तरह इसके पीछे था: P

— yannis

मैंने आपके उत्तर को संपादित किया है लिंक @ P.Brian.Mackey को शामिल करने के लिए। बाहरी स्रोतों को उद्धृत करना पूरी तरह से ठीक है, लेकिन आपको उन्हें लिंक शामिल करना होगा। इसके अलावा MVVM MVC के समान हो सकता है, लेकिन यह समान पैटर्न नहीं है। MVC में विचारों और नियंत्रकों को कभी भी एक ही वस्तु में नहीं मिलाया जाना चाहिए ...

— यानिस